معرفی ۱۸ استراتژی راهبردی در زمینهٔ اصول برنامه‌نویسی صحیح

معرفی ۱۸ استراتژی راهبردی در زمینهٔ اصول برنامه‌نویسی صحیح

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

1. پیروی از قانون DRY
اصطلاح DRY مخفف واژگان Don`t Repeat Yourself است؛ یکی از اساسی‌ترین اصول برنامه‌نویسی این است که تکرار را از کارمان حذف کنیم. هر زمان که احساس کردید در حال انجام کاری تکراری هستید، بهتر است دست به دامان فانکشن‌ها و یا کلاس‌ها شوید!

2. اصل انتزاع
Abstraction Principle (اصل انتزاع) که به‌نوعی مرتبط با اصل DRY است،‌ قانونی است که به‌منظور جلوگیری از هرگونه تکرار در کدنویسی ابداع شده است؛ براساس این اصل، قابلیت‌های کلیدی یک نرم‌افزار می‌بایست فقط و فقط یک‌بار در سورس‌کد نوشته شوند و هر زمان که دیدیم کارهای نسبتاً یکسانی در قالب فانکشن‌های متفاوتی انجام می‌شوند، می‌بایست از این اصل استفاده نموده و یک فانکشن به‌اصطلاح Abstract بنویسم که بسته به پارامتر‌های ورودی‌اش، می‌تواند کارهای متفاوت مدنظرمان را انجام دهد.

3. اصل KISS
ساده نوشتن و ساده نگاه داشتن کدها باید همواره یکی از اهدف اصلی‌مان باشد؛ کدی که ساده‌ باشد، هم نوشتنش راحت‌تر است و هم اصلاح کردنش. درعین‌حال، چنین کدی قطعا باگ‌های کمتری هم خواهد داشت (برای آشنایی بیشتر با قانون KISS،‌ به مقالهٔ اصطلاح KISS به چه معنا است و در برنامه‌نویسی چگونه نمود عینی پیدا می‌کند؟ مراجعه نمایید).

4. از ایجاد YAGNI خودداری کنید 
YAGNI مخفف واژگان You Aren`t Going to Need It است؛ به‌طور خلاصه، این قانون حاکی از آن است که تازمانی‌که به فیچری احتیاج پیدا نکرده‌اید، شروع به کدنویسی آن نکنید.

5. ساده‌ترین روش ممکن را در پیش بگیرید
زمانی که شروع به کدزنی می‌کنید، قطعاً هدفی در سر دارید؛ بهترین روش برای رسیدن به هدفتان، ساده‌ترین راه است. فکر کنید که از چه راهی با دردسر کمتری به آنچه در سر دارید رسیده و همان راه را درپیش گیرید.

6. فسفرهای مغزی سایرین را تلف نکنید
Don’t Make Me Think درواقع نام کتابی است که توسط استیو کراگ در خصوص کاربردپذیری وب نوشته است که به‌نوعی به برنامه‌نویسی هم مربوط می‌شود. نکتهٔ جالب توجه این است که کد باید به‌راحتی خوانده شده و برای سایر دولوپرها قابل‌فهم باشد. اگر کدی زده‌اید که فهمش نیاز به تلاش زیادی داشته باشد، قطعاً باید آن‌را در اولین فرصت ریفکتور کرده و به ساده‌ترین و درعین‌حال قابل‌فهم‌ترین حالت ممکن بنویسید.

7. اصل Open/Closed
برپایهٔ این اصل، کلاس‌ها، ماژول‌ها و فانکشن‌های یک نرم‌افزار باید برای توسعه یافتن به‌اصطلاح Open (باز) گذاشته شوند اما وقتی‌که پای تغییر و ریفکتورینگ به‌میان می‌آید، می‌بایست به‌اصطلاح Closed (بسته) باشند. به‌عبارت دیگر، کلاس‌هایی ننویسید که سایر دولوپرها بتوانند دست به تغییر ساختار آن‌ها بزنند بلکه آن‌ها را فقط قابل Extend (اکستند به‌معنی توسعه) یافتن بنویسید.

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

9. سورپرایز کردن ممنوع!
با نگاه کردن به چنین عنوانی، به‌طور حتم اولین چیزی که به‌ ذهن می‌رسد این است که رابط کاربری (UI) نرم‌افزار نباید آنقدر افتضاح باشد که باعث حیرت کاربر شود؛ اما این پایان ماجرا نیست و درواقع هیچ‌کس نباید از نگاه کردن به کدهایی که ما زده‌ایم هم حیرت کند.

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

10. قانون Single Responsibility
هر کدام از فانکشن‌ها یا کلاس‌هایی که نوشته می‌شود باید فقط و فقط مسئول یک کار به‌خصوص باشد و بس.

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

12. یکپارچگی را به حداکثر برسانید
کدهایی که فانکشنالیتی یکسانی دارند می‌بایست در یک کامپوننت و کنار یکدیگر قرار داده شوند که چنین چیزی اصطلاحاً Cohesion نامیده می‌شود.

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

14. قانون Demeter
Law of Demeter که به‌اختصار LoD گفته می‌شود، در برنامه‌نویسی شیٔ‌گرایی بدین معنا است که هر آبجکت باید از ساختار و ویژگی‌های سایر آبجکت‌ها، کلاس‌ها، فانکشن‌ها و ... در سیستم ناآگاه بوده و میزان وابستگی در بخش‌های مختلف نرم‌افزار می‌بایست به‌صورت حداقلی باشد.

15. فکر اپتیمایز کردن پیش از موقع را از سرتان بیرون کنید
تحت هیچ عنوان دست به بهینه‌سازی نزنید مگر این‌که کدهایتان به‌سرعتی که انتظار دارید کار نکنند؛ به گفتهٔ Donald Knuth -دانشمند علوم کامپیوتری و ریاضیدان در دانشگاه استنفورد- بهبود بی‌موقع درواقع کار شیطان است و باعث خرابکاری‌های بعدی خواهد شد!

16. استفاده از کدهای قبلی‌تان را فراموش نکنید
استفاده کردن از کدهایی که قبلاً زده‌اید نه‌تنها اطمینان شما را از درست کار کردن کد بیشتر می‌کند، بلکه باعث صرفه‌جویی در زمان گرانبهای شما نیز می‌شود.

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

18. از تغییر استقبال کنید
Embrace Change (تغییر را در آغوش بگیرید) بخشی از نام کتابی نوشتهٔ Kent Beck است و این مفهوم درواقع یکی مفاهیم اصلی متودولوژی Agile (اجایل به‌معنی چابک) درنظر گرفته می‌شود؛ آنچه از این اصل برداشت می‌شود این است که یک دولوپر باید آغوش خود را به روی تغییرات باز نگاه دارد و خود نیز کدهایی بزند که به‌راحتی قابل ریفکتور شدن باشند.

کلام آخر
به‌نظر می‌رسد که اگر دولوپری این ۱۸ آیتم را در حرفهٔ خود رعایت کند، کدهایی که می‌نویسد بهینه، قابل‌فهم، مستقل و از همه مهم‌تر حرفه‌ای خواهند بود. شما به‌عنوان یک دولوپر -فارغ از زبانی که با آن کد می‌زنید- کدام‌یک از موارد فوق را در حین کدنویسی رعایت می‌کنید و آیا رعایت موارد فوق‌الذکر کمکی به بهبود کدهای شما کرده‌ است؟ نظرات، دیدگاه‌ها و تجربیات خود را در این خصوص با ما و سایر کاربران سکان آکادمی به اشتراک بگذارید.

منبع


فرنوش فهیم