توسعه نرم‌افزار مثل هر حوزه تخصصی دیگه‌ای یک سری قوانین و اصول خودش رو داره. لیست زیر مجموعه‌ای از نقل قول‌ها و قوانینی هست که معمولا برنامه‌نویس‌ها، معماران نرم‌افزار و مدیران خیلی از اونها استفاده میکنن.
خیلی از قوانین عمومی هستن و مختص به توسعه نرم‌افزار نیستن ولی تلاش کردم تا ارتباط و نحوه مقابله با اونها رو در زمینه کار تخصصی خودم پیدا کنم. اطلاع داشتن از این قوانین دید خوبی به افراد میده تا در حد امکان در کارهای تخصصی خودشون بتونن از بروز اونها جلوگیری کنند و در صورت بروز آمادگی مقابله با اونها رو داشته باشند.
یکی از معروف‌ترین قوانین هست که فقط هم مختص توسعه نرم‌افزار نیست:
هر چیزی که ممکنه خراب بشه، حتما خراب میشه
استفاده از ورژن کنترل، متدلوژی TDD و توسعه نرم‌افزار به روش تدافعی و غیره همه روش‌هایی برای جلوگیری از این قانون هستند
این قانون درباره مدیریت زمان و برنامه‌ریزی برای انجام کارهاست که میگه:
هر کار به اندازه زمانی که برای آن تخصیص داده شده طول می‌کشد
استفاده از ابزارهای مدیریت پروژه آنلاین، جلسات فردی و تیمی منظم، داشتن اهداف مشخص، زمانبندی دقیق برای انجام کارها و جلوگیری از multi-tasking همه از مواردی هستن که به جلوگیری از قانون پارکینسون کمک میکنه.
آقای Fred Brooks نویسنده کتاب معروف The Mythical Man-Month این قانون رو در کتابش مطرح میکنه:
اضافه کردن نیروی انسانی به یک پروژه نرم‌افزاری با تاخیر، تاخیر اون رو بیشتر میکنه
با اضافه شدن افراد جدید به پروژه مدت زمانی طول میکشه تا افراد بتونن با پروژه آشنایی پیدا کنند و موثر باشند. همچنین با اضافه شدن افراد پیچیدگی ارتباطات هم بیشتر میشه و در نتیجه باعث میشه کارها کندتر پیش بره.
بازبینی کدها، اصلاح معماری و استفاده از متدلوژی‌های توسعه نرم‌افزار مناسب تیم قطعا نتیجه بهتری نسبت به اضافه کردن نیروی انسانی به پروژه نرم‌افزاری در حال تاخیر داره.
از این قانون مجدد در کتاب The Mythical Man-Month و متدلوژی XP صحبت شده:
انجام کار همیشه بیشتر از چیزی که فکر میکنید طول میکشه، حتی وقتی قانون هافستدر رو در نظر بگیرید
این قانون درباره پیچیدگی تخمین زمان مورد نیاز برای کارهاست که خصوصا در توسعه نرم‌افزار زیاد با اون سر و کار داریم. نوع قانون دلالت بر خود هست و این پیچیدگی که خود قانون از خودش استفاده میکنه، بازتابی از پیچیدگی تخمین زمان تحویل کار هست. تخمین زمان یک مهارت کلیدی در توسعه نرم‌افزار هست که با استفاده از دانش قبلی انجام کار مشابه، کمک گرفتن از افراد با تجربه و تقسیم کار به چند مرحله به تخمین دقیق‌تر ما کمک میکنه.
قانون کانوی درباره ساختار سازمانی هست و به طور خلاصه میگه هر بخشی از نرم‌افزار نشان دهنده ساختار سازمانی هست که اون رو تولید کرده. به طور دقیق:
هر سازمانی که سیستمی را طراحی می‌کند، ساختار طرح خروجی یک کپی از ساختار ارتباط درون سازمان خواهد بود
در بسیاری از شرکت‌ها افراد بر اساس توانایی‌ها در تیم‌های مختلف Frontend, Backend, DevOps و غیره قرار می‌گیرن. روش بهتر این هست که مثل طراحی میکروسرویس افراد که روی یک محصول یا سرویس کار می‌کنند در یک تیم قرار بگیرند تا ارتباط و خروجی بهتری داشته باشند.
برای مقابله با این قانون محل استقرار افراد درون تیم‌ها باید حول محور هدف و خروجی باشه تا دستیابی به اون هدف راحت‌تر بشه و پیچیدگی ارتباطات درون تیم‌ها کمتر بشه.
جان پاستل یکی از تاثیرگذارترین افراد در شکل‌گیری اینترنت، TCP و DNS این قانون رو مطرح میکنه که:
در ارسال‌ها محافظه‌کار باشید، ولی در دریافت روشن‌فکر باشید
این قانون رو در طراحی‌های اولیه پروتکل TCP مطرح کرده و همین باعث قدرتمند بودن این پروتکل شده. مصداق این قانون در پیاده‌سازی زبان‌های برنامه‌نویسی ویژگی ارث بری و Polymorphism هست که در ورودی بتونیم با generic ها تایپ‌های مختلفی بگیریم ولی در خروجی محدودیت داشته باشیم.
اصل پارتو که به نام‌های قانون ۸۰-۲۰ و قانون افراد اندک اساسی هم معروف هست میگه:
۸۰ درصد رخدادها از ۲۰ درصد دلایل به وجود می‌آیند
ارتباط این اصل با حوزه کاری توسعه نرم‌افزار به این شکله که معمولا ۸۰ درصد باگ‌های نرم‌افزار مربوط به ۲۰ درصد پروژه هستند که با استفاده از ابزارهای Linter و Static Analysis به صورت اتوماتیک میتونیم این مشکلات رو راحت‌تر پیدا کنیم.
همچنین میشه گفت ۸۰ درصد کارها در یک سازمان توسط ۲۰ درصد افراد انجام میشه و مشخص کردن این که چه افرادی بیشترین کار رو انجام میدن کار سختی هست ولی به لطف ابزارهای آنلاین contribution های افراد و کیفیت انجام کارها راحت‌تر پیگیری میشه.
اصل پیتر یک مفهوم مدیریتی است که میگه انتخاب یک نامزد برای موقعیت جدید بر اساس عملکرد موفقیت آمیز فرد در نقش فعلی‌اش صورت میگیره نه بر اساس سنجش توانایی‌ها برای موقعیت جدید. به همین دلیل با مدیرانی در سازمان‌ها مواجه میشیم که شایستگی جایگاه خودشون رو ندارن. به طور دقیق:
کارکنان تا آنجا که موفقیت‌آمیز عمل کنند ارتقا می‌یابند و فقط هنگام رسیدن به «مرز بی‌کفایتی» متوقف می‌شوند و در همان سمت باقی می‌مانند
اصل پیتر حالت خاصی از «پدیده همه‌جانبگی» (ubiquitous observation) است: هر آنچه (درست) کار می‌کند در حالتی پیشرفته‌تر و چالش‌برانگیزتر به کار گرفته خواهد شد تا آنجا که دیگر کارایی از خود نشان ندهد.
اثر دانینگ–کروگر یک خطای ذهنی و روانشانسی هست که میگه افراد کم‌تجربه توانایی خودشون رو خیلی بیشتر از چیزی که واقعا هست می‌دونن و توهم خود بزرگ‌بینی دارن و افراد حرفه‌ای این اشتباه رو می‌کنند که چون انجام کاری برای خودشون ساده هست پس برای بقیه هم همینطوره، که اشتباهه. این اثر بر اساس تحقیق دو روانشناس انجام شده و میگه:
تخمین نادرست فرد بی‌لیاقت، از اشتباه در ارزیابی خود ناشی می‌شود؛ درحالی‌که تخمین نادرست افراد بسیار بالیاقت، از اشتباه در ارزیابی دیگران نشئت می‌گیرد
به شخصه در خیلی از محیط‌ها با این مساله روبرو شدم که افراد کم‌تجربه به دلیل دید محدودی که نسبت به کارها دارن دید درستی از خودشون ندارن. یکی از بهترین کارهایی که برای مقابله با این اثر میشه انجام داد اینه که همیشه در حال یادگیری باشیم تا به خودمون مغرور نشیم و از دیگران فیدبک صادقانه درباره کارمون بگیریم. البته خیلی از وقت‌ها افراد شاید مستقیم نتونن مشکلات رو بهتون بگن و میشه ازشون در قالب سوال پرسید که مثلا به نظر اونها یک برنامه‌نویس یا مدیر خوب چه ویژگی‌هایی داره و اینطوری خودمون رو با اون معیارها مقایسه کنیم.
لینوس توروالدز خالق کرنل لینوکس این قانون رو میگه:
هرچه چشم‌ها بیشتر باشند باگ‌ها کم عمق‌ترند
این جمله به نقل از لینوس توروالدز در کتاب «کلیسا و بازار» نوشته اریک ریموند گفته شده که تفاوت بین دو روش توسعه نرم‌افزار رو توضیح میده. روش کلیسا که میگه کد توسعه داده شده در بین release ها عمومی نیست و با هر release کد به صورت متن باز منتشر میشه که نمونه‌های این نرم‌افزارها GCC, Emacs هستن. روش بازار روشی هست که هسته لینوکس در دسترس عموم و در بستر اینترنت توسعه داده میشه و شروع کننده اون رو لینوس توروالدز میدونه.
طرفداران متن باز بودن نرم‌افزرها اعتقاد دارن وقتی کد در دسترس عموم باشه با دقت و کیفیت بهتری توسعه نرم‌افزار انجام میشه و باگ‌های کمتری خواهد داشت.
نخستین بار آقای مور از بنیان‌گذاران اینتل این قاعده رو بیان میکنه که:
تعداد ترانزیستورهای روی یک تراشه با مساحت ثابت هر ۲ سال ، به طور تقریبی دو برابر می‌شود
نسخه‌های دیگه‌ای از این قاده مطرح شده که سرعت پردازش کامپیوترها هر ۲ سال تقریبا دو برابر میشه. یا هزینه واحدهای کامپیوتری هر ۲ سال تقریبا دو برابر میشه.
اطلاع داشتن از چنین قواعدی باعث میشه در طراحی و توسعه نرم‌افزارها دید بهتری از آینده داشته باشیم و پیش‌بینی های دقیق‌تری داشته باشیم. از نمونه‌های عدم آینده‌نگری در نرم‌افزارها میشه به مشکل سال ۲۰۳۸ اشاره کرد که در این سال timestamp روی سیستم‌های ۳۲ بیتی overflow میشه یا مشکل Y2K که تقویم‌های کامپیوترها بعد از سال ۱۹۹۹ و شروع سال ۲۰۰۰ به مشکل خوردن.
این قانون رو آقای نیکولاس ویرث خالق زبان برنامه‌نویسی پاسکال میگه:
سرعت کند شدن نرم‌افزار بیشتر از افزایش سرعت سخت‌افزار هست
نسخه‌های دیگه‌ای از این قانون وجود داره مثل چیزی که بیل گیتس میگه که هر ۱۸ ماه به طور میانگین سرعت نرم‌افزارها نصف میشه تاثیر قانون مور رو خنثی میکنه.
این قانون یک شوخی درباره زمانبندی توسعه نرم‌افزار هست که معمولا تحویل محصول در تیم‌ها با تاخیر انجام میشه و عدم قطعیت همیشه در نرم‌افزار هست. این قانون میگه:
۹۰ درصد کد در ۱۰ درصد زمان توسعه داده میشه. ۱۰ درصد مابقی کد ۹۰ درصد زمان رو میگیره.
این مجموع ۱۸۰ درصدی یک شوخی هست که همیشه توسعه نرم افزار بیشتر از چیزی که فکر می‌کنیم زمان میبره.
این قانون درباره بهینه‌سازی کد هست که میگه:
بهینه‌سازی قبل از موعد عامل همه بدی‌هاست
روش استاندارد توسعه کد این هست که شما کد رو در وضعیتی که فکر میکنید خوبه توسعه میدین و بعد از پیدا شدن مشکلات سرعت، به دنبال رفع اونها برید. بهینه کردن قبل از موعد فقط باعث پیچیده و کند شدن توسعه میشه.
یک بار دنبال مقاله پارتیشن کردن دیتابیس Postgres بودم که اولش گفته بود اگر نمیدونین پارتیشن کردن دیتابیس چیه حتمن به اون نیازی ندارید!
قانون نورویگ یکی از قوانین بدبینانه هست که میگه:
هر تکنولوژی که به درصد نفوذ بیشتر از ۵۰ درصدی میرسه، هرگز دیگر افزایش ۲ برابری نخواهد داشت (در هیچ بازه زمانی)
طبیعیه که مثلا استفاده کنندگان از تلفن هوشمند وقتی از ۱ میلیون به ۲ میلیون در کشور میرسه افزایش دوبرابری بوده ولی وقت مثلا ۳۰ میلیون استفاده کننده در کشور داریم هرگز افزایش ۲ برابری یعنی ۶۰ میلیون مشترک نخواهیم داشت.
