اصول برنامه‌نویسی درست ارتباط تنگاتنگی با شیوه‌های درست طراحی و مهندسی نرم‌افزار دارا است و آنچه در ادامه آورده‌ایم، در واقع چکیده‌ای از قوانینی است که می‌توانند به یک دولوپر کمک کنند تا به شکل بهتر و مؤثرتری دست به کدنویسی زده و کدهایی بزند که نه تنها بهینه‌تر هستند، بلکه در عین حال از خطاهای کمتری نیز برخوردارند.
پیروی از قانون DRY
اصطلاح DRY مخفف واژگان Don`t Repeat Yourself می‌باشد که به منزلهٔ یکی از اساسی‌ترین اصول برنامه‌نویسی است بدین صورت که تکرار را از کارمان حذف کنیم. به عبارت دیگر، هر زمان که احساس کردید در حال انجام کاری تکراری هستید، بهتر است دست به دامان فانکشن‌ها و یا کلاس‌ها شوید.
اصل انتزاع
Abstraction Principle، که به نوعی مرتبط با DRY است، قانونی می‌باشد که به منظور جلوگیری از هرگونه تکرار در کدنویسی ابداع شده است به طوری که بر اساس این اصل، قابلیت‌های کلیدی یک نرم‌افزار می‌بایست فقط و فقط یک‌بار در سورس‌کد نوشته شوند و هر زمان که دیدیم کارهای نسبتاً یکسانی در قالب فانکشن‌های متفاوتی انجام می‌شوند، می‌بایست از این اصل استفاده نموده و یک فانکشن به اصطلاح Abstract بنویسم که بسته به پارامتر‌های ورودی‌اش، می‌تواند کارهای متفاوت مد نظرمان را انجام دهد.
اصل KISS
ساده نوشتن و ساده نگاه داشتن کدها باید همواره یکی از اهداف اصلی‌مان باشد. کدی که ساده باشد، هم نوشتنش راحت‌تر است و هم اصلاح کردنش و در عین حال، پروسهٔ دیباگینگ چنین کدی قطعاً راحت‌تر هم خواهد بود (برای آشنایی بیشتر با قانون KISS، به مقالهٔ KISS: رویکردی که کمک می‌کند به دولوپر بهتری مبدل گردیم! مراجعه نمایید.)
ساده‌ترین روش ممکن را در پیش بگیرید
این اصل به نوعی مرتبط با قانون KISS است بدین صورت که وقتی شروع به کدزنی می‌کنید، قطعاً هدفی در سر دارید که بهترین روش برای رسیدن به هدفتان، ساده‌ترین راه است. به عبارت دیگر، فکر کنید که از چه راهی با دردسر کمتری به آنچه در سر دارید خواهید رسید و همان راه را در پیش گیرید.
از ایجاد YAGNI خودداری کنید
YAGNI مخفف واژگان You Aren`t Going to Need It است که به طور خلاصه، این قانون حاکی از آن است که وقتی به فیچری احتیاج پیدا نکرده‌اید، شروع به کدنویسی آن نکنید.
فسفرهای مغزی سایرین را تلف نکنید
Don’t Make Me Think نام کتابی است که توسط Steve Krug در خصوص کاربردپذیری وب نوشته است که به نوعی به برنامه‌نویسی هم مربوط می‌شود. نکتهٔ جالب توجه این است که کد باید به راحتی خوانده شده و برای سایر دولوپرها قابل‌فهم باشد؛ پس اگر کدی زده‌اید که فهمش نیاز به تلاش زیادی داشته باشد، قطعاً باید آن را در اولین فرصت ریفکتور کرده و به ساده‌ترین و در عین حال قابل‌فهم‌ترین حالت ممکن بنویسید.
اصل Open/Closed
بر پایهٔ این اصل چیزهایی همچون کلاس‌ها، ماژول‌ها و فانکشن‌های یک نرم‌افزار باید برای توسعه یافتن به اصطلاح Open (باز) گذاشته شوند اما وقتی‌که پای تغییر و ریفکتورینگ به میان می‌آید، می‌بایست به اصطلاح Closed (بسته) باشند. به عبارت دیگر، کلاس‌هایی ننویسید که سایر دولوپرها بتوانند دست به تغییر ساختار آن‌ها بزنند بلکه آن‌ها را فقط قابل Extend (توسعه) یافتن بنویسید چرا که در غیر این صورت، در آینده باید انتظار نتایج دور از انتظاری را در اپلیکیشن خود داشته باشید.
کمی هم به فکر دولوپر نگهدارنده سورس‌کد باشید
هر کدی که ارزش نوشتن داشته باشد، بی‌ترید ارزش به قول معروف «تَر و خشک کردن» در آینده را نیز دارد، خواه توسط خودِ شما و خواه توسط دولوپری دیگر. اگر در آینده قرار باشد باری دیگر به کدهایی که نوشته‌اید برگردید، چیزی بیش از یک دولوپر غریبه از آن به یاد نخواهید آورد! بنابراین به قول John Woods:
همیشه طوری کد بزنید که گویی فردی که پس از شما قراره اون پروژه رو نگهداری کنه، یک دیوانهٔ عصبیه که می‌دونه شما کجا زندگی می‌کنید!
سورپرایز کردن ممنوع
با نگاه کردن به چنین عنوانی، به طور حتم اولین چیزی که به ذهن می‌رسد این است که رابط کاربری (UI) نرم‌افزار نباید آن‌قدر افتضاح باشد که باعث حیرت کاربر شود اما این پایان ماجرا نیست و در واقع هیچ‌کس نباید از نگاه کردن به کدهایی که ما زده‌ایم حیرت‌زده شود و این بدان معنا است که باید اصول رایج در کدنویسی را رعایت کرده، کامنت‌ها و کدهای مرتبط با آن‌ها می‌بایست سازگاری داشته باشند، نامگذاری‌ها باید اصولی باشند و در کل، خروجی کد باید کاملاً منطقی بوده و باعث حیرت دولوپرهای دیگر نشود!
قانون Single Responsibility
هر کدام از فانکشن‌ها یا کلاس‌هایی که نوشته می‌شود باید فقط و فقط مسئول یک تَسک به‌خصوص باشد.
وابستگی کدها را به حداقل برسانید
هر قسمت از کد شما باید مستقل از سایر کلاس‌ها و فانکشن‌ها باشد و این در حالی است که هرچقدر وابستگی کدها به یکدیگر کمتر باشد، سورس‌کد تمیزتری خواهید داشت که هم قابل‌فهم‌تر بوده و هم نگهداری‌اش آسان‌تر است.
یکپارچگی را به حداکثر برسانید
کدهایی که عملکرد یکسانی دارند می‌بایست در قالب یک کامپوننت (ماژول) و کنار یکدیگر قرار داده شوند که چنین چیزی اصطلاحاً Cohesion در کدنویسی نامیده می‌شود.
به حداقل رساندن ارتباط فرانت‌اند از بک‌اند
گاهی‌اوقات در فرانت‌اند پروژه نیازمند اِعمال یکسری تغییرات هستیم اما در عین حال این تغییرات نباید منجر به ایجاد تداخل در بخش بک‌اند پروژه شود. به عبارت دیگر، بک‌اند ما پس از اِعمال تغییرات سایر بخش‌های پروژه، می‌بایست در امان باشد.
رعایت قانون LoD
Law of Demeter که به اختصار LoD گفته می‌شود، در برنامه‌نویسی شییٔ‌گرایی (OOP) بدین معنا است که هر آبجکت باید از ساختار و ویژگی‌های سایر آبجکت‌ها، کلاس‌ها، فانکشن‌ها و ... در سیستم ناآگاه بوده و میزان وابستگی در بخش‌های مختلف نرم‌افزار می‌بایست به صورت حداقلی باشد.
فکر اُپتیمایز کردن پیش از موقع را از سرتان بیرون کنید
تحت هیچ عنوان دست به بهینه‌سازی نزنید مگر اینکه کدهایتان با پرفورمنسی که انتظار دارید کار نمی‌کنند. به گفتهٔ Donald Knuth که یک دانشمند علوم کامپیوتری و ریاضیدان در دانشگاه استنفورد است:
بهبود بی‌موقع در واقع کار شیطونه و باعث خرابکاری‌های بعدی می‌شه!
استفاده از کدهای قبلی‌تان را فراموش نکنید
استفاده کردن از کدهایی که قبلاً زده‌اید نه تنها اطمینان شما را از درست کار کردن کد بیشتر می‌کند، بلکه باعث صرفه‌جویی در زمان گرانبهای شما نیز می‌شود.
جداسازی ماژول‌های مهم
بخش‌های مختلف نرم‌افزار شما باید در قالب ماژول‌های متفاوتی قرار داده شوند و این ماژول‌ها باید به گونه‌ای کدنویسی شوند که دارای حداقل میزان کدهای مشابه با سایر ماژول‌ها باشند. در عین حال، میزان وابستگی ماژول‌ها نیز باید به صورت حداقلی باشد تا اگر روزی خواستید تا از یکی از ماژول‌های پروژه‌ای در محصول بعدی خود استفاده کنید، مجبور به رصد کردن وابستگی‌ها نشوید.
از تغییر استقبال کنید
Embrace Change (تغییر را در آغوش بگیرید) عنوان کتابی نوشتهٔ Kent Beck است و این مفهوم در واقع یکی از مفاهیم اصلی متودولوژی Agile (چابک) در نظر گرفته می‌شود. آنچه از این اصل برداشت می‌شود این است که یک دولوپر باید آغوش خود را به روی تغییرات باز نگاه دارد و خود نیز کدهایی بزند که به راحتی قابل ریفکتور شدن باشند.
روی هم رفته، به نظر می‌رسد که اگر دولوپری این ترفندها را در حرفهٔ خود رعایت کند، کدهایی که می‌نویسد بهینه، قابل‌فهم، مستقل و از همه مهم‌تر حرفه‌ای خواهند بود.
حال نوبت به نظرات شما می‌رسد. به عنوان یک دولوپر، فارغ از زبانی که با آن کد می‌زنید، کدام‌یک از موارد فوق را در حین کدنویسی رعایت می‌کنید و آیا رعایت آیتم‌های فوق‌الذکر کمکی به بهبود کدهای شما کرده‌‌اند؟ نظرات، دیدگاه‌ها و تجربیات خود را در این خصوص با سایر کاربران سکان آکادمی به اشتراک بگذارید.