خانه / Agile / قانون کانوی

قانون کانوی

قانون کانوی

در سال 1967آقای Melvin Conway مقاله ای رو با عنوان “How Do Committees Invent?” را به Harvard Business Review ارائه داد که بدلیل اینکه در اون مقاله نتوانست فرضیه خود را اثبات کند آن مقاله از طرف HBR رد شد. اما سال بعد مقاله را توسط مجله معروف IT آن زمان Datamation به چاپ رسانید. یکی از فرضیه های مهم آن مقاله جمله معروف زیر می باشد:

Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.

این مقاله و فرضیه های آن بعد ها به عنوان قانون کانوی معروف شد.

به عنوان متن از مقاله ای از سایت ویکی پدیا انتخاب شده است:

Conway’s law was not intended as a joke or a Zen koan, but as a valid sociological observation. It is a consequence of the fact that two software modules A and B cannot interface correctly with each other unless the designer and implementer of A communicates with the designer and implementer of B. Thus the interface structure of a software system necessarily will show a congruence with the social structure of the organization that produced it.

 

بسیار مهم است که توجه کنیم که این قانون نه تنها به نرم افزار که بر نوع طراحی دیگر نیز قابل تعمیم می باشد. ساختار ارتباطی که قانون کانوی مورد اشاره قرار می دهد در حقیقت دقیقا ساختار چارتی و رسمی سازمان نمی باشد, بلکه ارتباطات غیر رسمی درون سازمان است که بر جنبه های مختلفی تاثیر گذار است. همچنین توضیع جغرافیایی سازمان و غیر متمرکز بودن سازمان نیز بر این مساله تاثیر بسیار مهم و به سزایی خواهد داشت.

قانون کانوی به زبان ساده معرف این موضوع است که هر بخش سازمان که قسمت خاصی معماری مورد نیاز خورد را طراحی می کند. باید دارای Interface ای جهت برقراری ارتباط و تعامل با بخش های دیگر و سیستم های دیگرسازمان می باشد؛ و در نتیجه ارتباط و تعامل میان این Interface ها مورد نیاز می باشد, و در نتیجه تعاملی میان واحدهای سازمانی که مسئولیت ایجاد و توسعه این بخش ها را بر عهده دارند نیز مورد نیاز است و شکل می گیرد؛ و این خود باعث افزوده شدن dependency و complexity میان این سیستم ها خواهد شد.

 

از نقطه نظر قانون کانوی طراحی ماژولار محسوس و معقول است. با طراحی این چنینی می توان اطمینان داشت که تمام اعضای تیم A نیازمند ارتباط دائمی با اعضای تیم B نمی باشند. در عوض اعضایی که بر روی ماژول مشابه مشغول فعالیت هستند تلاش خود را هماهنگ می کند؛ و فقط هنگامی که Interface ای طراحی می شود(Published Interface) نیاز به همکاری و تعامل با اعضای تیم دیگر را خواهد داشت.

 

قانون کانوی بیان می کند که سازمان بزرگ نسبت های ارتباطی بسیار زیادی دارد. و ارتباطات در نهایت غیر ممکن و یا بسیار سخت خواهد شد. و نهایتا این می تواند منجر به این شود که معماری را به شدت تحت تاثیر قرار دهد و نهایت به شکست بینجامد. و اینکه ارتباطات بسیار زیاد و بیش از اندازه یک ریسک واقعی برای پروژه است.

 

قانون کانوی بخصوص از دیدگاه توسعه نرم افزار به عنوان محدودیت شناخته می شود. فرض کنید که یک پروژه بصورت ماژولار بصورت زیر طراحی شده است. تمامی توسعه دهنده هایی که بر روی UI کار می کنند به درون یک تیم جمع می شوند؛ توسعه دهنده هایی که Backend کار هستند در تیم Backend قرار می گیرند و توسعه دهنده هایی که متخصص لایه ی دیتابیس هستند در تیم Database قرار می گیرند. این توضیع تیمی این مزیت را دارد که هر سه تیم دارای متخصصینی در حوزه ی تکنولوژی خاص هستند می باشند. از آنجایی که اعضای تیم دارای مهارت مشابه هستند و در حوزه ی تخصصی خود کار می کنند می توانند همدگیر را راحت تر پشتیبانی کنند.

 

به زبان ساده شما وقتی جهت توسعه و طراحی یک محصول از چند تیم بصورت مجزا استفاده می کنید باعث می شود که در حداقل شرایط شما طراحی برای محصول خود داشته باشید که به تعداد تیم ها دارای لایه های مجزا خواهد بود.

اولین مشکل هنگامی است که با سناریوهایی مواجهید که نیاز است که تغییرات در تمامی لایه ها(در شکل بالا تمامی سه لایه) اعمال شود. UI نیازمند این می باشد که feature جدید را رندر کند, Backend نیازمند این می باشد که logic را پیاده سازی کند و دیتابیس نیازمند این می باشد که ساختار مورد نظر درون دیتابیس اعمال کند. و این اتفاقات می تواند منجر به موارد زیر باشد:

  1. افرادی که درخواست پیاده سازی feature را دارند مجبورند که با همه ی تیم ها صحبت کنند.
  2. تیم ها نیاز دارند که کارهاشون رو با هم هماهنگ کنند و interfaceهای جدیدی را ایجاد کنند.
  3. هنگامی که تیم ها درون اسپرینت کار می کنند؛ این وابستگی ها می تواند منجر به تاخیر شود.

به سخن ساده این رویکرد منجر می شود که وابستگی بسیار زیادی ایجاد کند و سربار ارتباطی و هماهنگی بالایی را ایجاد می کند. در نتیجه سازمانهایی که هدفشون پیاده سازی ویژگی های جدید با سرعت بالا می باشد با این رویکر به مشکل برخورد خواهند کرد.

هر چند که به نظر می رسه که قانون کانوی در سطح کلان و در سطح شرکت وجود دارد, این قانون همچنین در سطوح پایین نیز دیده می شود.این قانون اغلب بصورت زیر نیز گاهی بیان می شود:

“If you have four developers writing a compiler you will get a four pass compiler”

 

“If you have three developers writing a UI you will get three ways of doing everything (mouse click, menu item, short-cut key)

 

به عنوان مثالی دیگر فرض کنید که تیمی شامل یک متخصص دیتابیس یک توسعه دهنده Java Script/CSS؛ و یک توسعه دهنده #C می باشد. اینها در نهایت یک سیستم با سه لایه ایجاد می کند شامل: یک دیتابیس با پروسیجرها؛ یک لایه میانی جهت پیاده سازی بیزینس و لایه UI, آنهم صرفنظر از اینکه این طراحی مناسب و بهترین باشد یا نه.

این داستان شبیه به فیلم های کارتون بچه ها هست که قهرمانان سعی در کمک رسانی و نجات بقیه افراد دارند: سوپرمن میگه: من می تونم از قدرت خارق العاده خودم جهت کنار زدن سخره های یخی استفاده کنم. مامور آتش نشان اما می گه: من می تونم از نیروی آتش جهت ذوب کردن یخ ها استفاده کنم. مرد حفاری کننده می گه: من می تونم از دستانم جهت ایجاد حفره و ساخت تونل استفاده کنم.

برای تیم های نرم افزاری این می تواند منجر به یک معماری ضعیف, با طراحی های پیچیده و ایجاد ماژول هایی که بر اساس رقابت و چشم و هم چشمی ایجاد شده, شود.

معمولا در آغاز و اوایل ایجاد یک تیم که معمولا کمترین اطلاعاتی در دسترس می باشد, تصمیمات معماری گرفته می شود, حتی اگر شما دست به قلم نبرده و هیچ طرح و نقشه ای هم نکشیده باشید. فقط کافی است که که تیم رو بدون 3 نفر با 4 نفر تشکیل دهید تا ببینید که به چه اندازه این تصمیم بر طراحی ای که انتخاب می شود تاثیر می گذارد, به این دلیل که کار الان نیاز دارد که برای چهار نفر شناخته شود.

جهت اجتناب از این پدیده بهتر است که در ابتدای کار تیم تا جایی که ممکن است کوچک نگه داشته باشد.

معکوس قانون کانوی

از زمانی که کانوی این قانون رو ارائه داده سیستم های بسیار زیادی طراحی و توسعه داده شده اند. بسیاری از این سیستم ها را اصطلاحا “Legacy Systems” می گویند. در برخی موارد این سیستم ها ساختار خاصی را برای افرادی که در سیستم مسئولیت پشتیبانی و نگه داری سیستم را به عهده دارند, و حتی در سطح بالاتر بر سطح سازمان می گذارند.

به عنوان مثال, سیستم سه لایه (طراحی معمول و متدوال سنتی) شامل لایه های database و business و GUI رو در نظر بگیرید. مدتی بعد توسعه دهنده های اصلی چنین سیستمی شرکت رو ترک می کنند, حداقل تاثیری که این تصمیم و ترک توسعه دهنده ها بر شرکت خواهد گذاشت, این است که چنین سیستمی که دارای پیچیدگی در هر سه لایه می باشد؛ نیازمند متخصصی در هر سه لایه می باشد, دیتابیس پر است از طراحی های توابع و store procedureها پیچیده و trigger ها و محدودیت های دیتابیسی که فقط یک متخصص دیتابیس می تواند آنرا درک کند. GUI مملو شده است از کدهای جاوا اسکریپت و CSS و HTM که هر کسی قادر به درک آن نمی باشد. و لایه بیزینس هم اونقدرها ساده نیست که توسط هر کسی قادر به درک باشه.

چنین موقعیتی باعث میشه که سازمان انتخاب دیگه ای نداشته باشه؛ جز اینکه سه متخصص رو استخدام کنه. در این شرایط قانون کانوی به شیوه ی عکس عمل می کنه و چنین سیستمی بر روی ساختار سازمانی تاثیر خواهد گذاشت.

مجددا تاکید می شود که این موارد نه تنها در سطح خرد که در سطح کلان نیز بر سازمان تاثیر خواهد گذاشت. تمامی سازمانها بر اساس سیستم هایی که دارند محدود و مجبور می شوند.

هر دو قانون کانوی و کانوی معکوس شده با هم به عنوان The Homorphic Force شناخته می شوند.

نکته ی مهم اینکه؛ این فشار و اجبار به عنوان عاملی جهت نگه داشتن و حفظ ساختار فعلی سیستم؛ حتی اگر سیستم از تکنولوژی ای به تکنولوژی دیگر یا جتی پلت فرم دیگر منتقل شود؛ عمل می کند.

نهایتا باید به این نکته تاکید داشت که بهنگام درک و طراحی معماری سیستم به قانون کانوی و تاثیرات آن هم در سطح ریز و پایین سازمان و هم در سطح کلان سازمان توجه داشت؛ و اینکه تا چه اندازه عدم توجه به این قانون مهم می تواند بر طراحی بد معماری تاثیر بگذارد؛ و به عکس یک ساختار خوب سازمانی می تواند منجر به یک طراحی خوب و بهتری شود.

درباره ی masoud@admin

همچنین ببینید

مایکروسرویس ها و ادامه چرخه ی تسلسل اجایل

مایکروسرویس ها و ادامه چرخه ی تسلسل اجایل هرچند تفکر و ایده ی ورای Microservices …

The Five Dysfunctions Of The Team

#TheFiveDysfunctionsOfTheTeam #Team #People_Ware_Concern ✍✍✍✍✍✍✍✍✍✍✍   When you start an activity(work,startup,project and so on) with any …

پاسخ دهید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *

در تلگرام هم همراه شما هستم

اگر علاقمند به معماری نرم افزار و مبحث محبوب مایکروسرویس هستید؛ در کانال با ما همراه باشید. اطلاعات مفید زیادی در این کانال انتظار شما را می کشند. فقط کافیست دکمه ی پیوستن را بفشارید.

پیوستن بستن