همه‌ی برنامه نویسان اصول اصلی برنامه نویسی را بلد هستند. اما قوانین دیگری نیز وجود دارد که حتی ممکن است بیشتر این اصول به کارتان بیاید. 

درحالی که اصولی که می‌دانید به شما یاد می‌دهند که چگونه با کدهای خود هوشمندانه برخورد کنید این اصول و قوانین به شما می‌آموزند که چگونه با کدهای خود عاقلانه‌تر برخورد کنید. بعضی از آن‌ها عجیب و بعضی از آن‌ها به نظر شبیه شوخی، اما همه‌ی آن‌ها به یک اندازه مهم و کاربردی هستند. 

1- اصل نفخ (The Bloat Principle)

این اصل آنقدر انواع مختلف دارد که نمی‌توان یکی از آن‌ها را به عنوان مورد اصلی انتخاب کرد. شاید اصلی‌ترین آن‌ها قانون انکشاف نرم‌افزار یا قانون  Zawinski است که به خاطر جیمی زاوینسکی نام گذاری شده است:

« هر برنامه می‌تواند آنقدر گسترش یابد که یک نامه را بخواند. برنامه‌هایی که این قابلیت را ندارند با آن‌هایی که دارند جایگزین می‌شوند.»

این اصل می‌گوید که باید به هر برنامه بتوان روز به روز قابلیت‌های جدید اضافه کرد و آن را پیچیده‌تر کرد. شاید شما این اصل را با نام feature creep  بشناسید: «شما باید بتوانید روز به روز قابلیت‌های بیشتری که حتی ربطی هم به هدف اصلی برنامه ندارد را به آن اضافه کنید.» feature creep می‎تواند باعث نفخ نرم‌افزاری شود. 

این موضوع را همچنین می‌توان به عملکرد نرم‌افزار نیز تعمیم داد: 

« نرم افزار آنقدر گسترش می‌یابد تا از همه‌ی منابع موجود استفاده کند.» 

در سال‌های 90 درایوهای سخت،  CPUها و RAM بسیار محدودتر از امروزه بودند و برنامه‌نویسان ناچار بودند همه‌ی تلاش خود را بکنند تا با وجود محدودیت‌ها قابلیت‌های بیشتری را به برنامه‌ی خود اضافه کنند. با این که امروزه ما درایوهای بزرگ‌تر، CPU و RAM سریع‌تری داریم باز هم با محدودیت‌ها درگیر هستیم. در طول زمان همه چیز دچار نفخ می‌شود و شما باید همیشه حواستان به این موضوع باشد. 

2- ذهنیت «بدتر بهتر است» (The “Worse Is Better” Mentality)

برای پاسخ به اصل نفخ، ریچارت گابریل در مقاله‌ای ذهنیت «بدتر بهتر است» را معرفی کرده است:

«نرم‌افزاری که محدود اما ساده است می‌تواند برای بازار و کاربر جذاب‌تر از نرم‌افزار پیچیده و دشوار باشد.»

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

اگر این مشکل را نادیده بگیرید با اصل پیتر روبه‌رو خواید شد:

« یک پروژه‌ی پیچیده زمانی آنقدر پیچیده خواهد شد که حتی درک آن برای توسعه دهندگانش نیز دشوار خواهد بود.»

این قانون از اصل پیتر گرفته شده که می‌گوید وقتی که کارمندان به خاطر شایستگی در پست کنونی و نه شایستگی در پست بعدی ارتقا شغلی می‌یابند در نهایت همه‌ی کارمندان یک شرکت بدون شایستگی به پست بعدی خود می‌رسند. اگر این اصل را به نرم افزار تعمیم دهید می‌بینید که نرم‌افزار شما در نهایت اگر بدتر باشد بهتر است. 

3- قانون ایگلسون (Eagleson’s Law) 

«اگر حدود شش ماه است که به کدهای خود نگاه نینداخته‌اید، احتمالاً تا این زمان یکی دیگر آن را نوشته است.»

این اصل را واقعاً باید با طلا نوشت. دراصل هیچ کس عالی نیست. شاید شما امروز فکر کنید که برنامه نویس بسیار نابغه‌ای هستید، اما همیشه چیزی هست که باید بیاموزید. همیشه به یاد داشته باشید که اگر به کدهایی که قبل‌ها نوشته‌اید نگاه بیندازید و خجالت بکشید به این معنی است که در حال پیشرفت هستید. 

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

4- اصل کمترین غافلگیری (Principle of Least Astonishment)

«اگر یک قابلیت خیلی غافلگیر کننده باشد بهتر است که آن قابلیت را دوباره طراحی کنید.»

این اصل که برای اولین بار در سال 1984 در مجله‌ی IBM Systems چاپ شد چالشی است که در دنیای امروز بیشتربا آن درگیر هستیم. 

این موضوع به بحث حساس نوآوری و آشنایی برمی‌گردد: اگر یک نرم‌افزار زیادی با نرم‌افزارهای مشابه‌اش متفاوت است و مطابق انتظارات کاربر نیست از آن استقبال نخواهند کرد. بهتر است که در حدی برای خاص کردن نرم‌افزارتان تلاش کنید که چشمگیر باشد اما نه آنقدر که فضا برای کاربر غریبه باشد. 

5- اصل حشره شناسی سایبری (Law of Cybernetic Entomology)

«همیشه یک باگ وجود دارد.»

به این قانون حشره شناسی سایبری لوبارسکی (Lubarsky) می‌گویند. هنوز مشخص نیست که آقای لوبارسکی چه کسی است. اما اصل آن درمورد همه‌ی توسعه‌دهندگان صدق می‌کند: هرچه هم که کد شما بی نقص باشد، هرچه هم که آن را ویرایش کنید، هنوز هم یک باگ وجود دارد. 

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

6- قانون کرنیگان (Kernighan’s Law)

« رفع باگ دو برابر کدنویسی دشوارتر است. در نتیجه اگر کد خود را تا حد ممکن پیچیده بنویسید هیچ گاه برای رفع باگ آن به اندازه‌ی کافی باهوش نخواهید بود.» 

برایان کرنیگان، که در نوشتن کتاب مقدس زبان برنامه نویسی C نقش دارد او به خاطر این قانون بسیار مشهور است. منظور کرنیگان این است: کد خوب بنویسید، کد قابل خواندن بنویسید، کد ساده بنویسید اما کد هوشمندانه ننویسید. 

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

البته این قانون فقط درمورد رفع باگ نیست. رابرت، سی، مارتین در این مورد می‌گوید :«زمانی که ما برای خواندن کد صرف می‌کنیم ده برابر زمانی است که آن را می‌نویسیم. ما همیشه برای نوشتن کد تازه باید نگاهی به کدهای قبلی خود بکنید. در نتیجه تلاش برای ساده کردن خواندن آن این است که آن را ساده‌تر بنویسیم.»

7- رفع باگ به روش اردک پلاستیکی (Rubber Duck Debugging)

این مورد بیشتر یک تکنیک است تا یک اصل اما بسیار کاربردی است. 

اولین بار این اصل در کتاب The Pragmatic Programmer منتشر شد. رفع باگ به روش اردک پلاستیکی روشی است که در آن شما باگ نرم‌افزار خود را خط به خط برای یک شیء بی‌جان توضیح می‌دهید. 

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

به همین دلیل اردک پلاستیکی می‌تواند هدیه‌ی مناسبی برای یک برنامه نویس باشد.

8- قانون نود-نود (The Ninety-Ninety Rule)

« نود درصد کد برابر با نود درصد از زمان توسعه است. ده درصد دیگر کد برابر با نود درصد زمان توسعه است.»

این ضرب المثل که تام کارگیل (Tom Cargill) آن را ساخته به شما می‌گوید که چرا برنامه نویسی می‌تواند خسته کننده باشد: هرچه هم که فکر کنید برنامه‌ی شما درحال تمام شدن است باز هم به زمان بیشتری نیاز دارید. وقتی فکر می‌کنید برنامه‌ی شما تمام شده تازه به نیمه‌ی راه رسیده‌اید. 

9- قانون پارکینسون (Parkinson’s Law)

« شما تا زمانی که وقتتان تمام شود کارتان طول خواهد کشید.» 

این اصل که توسط سیریل نورتکوت پارکینسون ( Cyril Northcote Parkinson) بیان شده یک اصل کلی‌تر است که قانون نود-نود را دربر می‌گیرد: زمانی که برای نوشتن یک پروژه نیاز دارید برابر کل زمانی است که دارید. برای توسعه نرم‎افزار سریع تمام کردن آن یک افسانه است. 

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

10- قانون بروک (Brook’s Law)

«اضافه کردن نیروی انسانی بیشتر برای نوشتن یک پروژه سرعت آن را پایین می‌آورد.» 

به یاد داشته باشید که اگر برای ارسال یک پروژه دیرتان شد ( که البته همه‌ی برنامه نویسان برای نوشتن کد خود به زمان بیشتری نیاز دارند.) اضافه کردن یک برنامه نویس دیگر فقط سرعت شما را پایین می‌آورد. 

چرا که اضافه کردن یک برنامه نویس جدید نه تنها سرعت شما را بالا نمی‌آورد بلکه کدهایی که نوشته‌اید را نیز به چالش می‌کشد. این کار به مدیریت بسیار بیشتری نیاز دارد تا همه با کدها موافق باشند و در نتیجه زمان شما را بیشتر می‌گیرد..»

یک برنامه نویس حرفه‌ای شوید

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