۵ اصل کد نویسی که به شما در نوشتن کدهای بهتر کمک می‌کند

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

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

برای نوشتن کدهای خوب قطعا نیازمند به رعایت اصل‌هایی هستیم؛ چرا که بدون رعایت اصول مشخص، کد شما به هم‌ریخته و مبهم خواهد بود.

در زیر لیستی از مواردی را که باعث بهبود مهارت‌های کد نویسی شما می‌شود را مشاهده می‌کنید:

DRY (Don’t repeat yourself)

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

شما همیشه باید در هنگام برخورد به چنین مواردی بدانید که احتمالا می‌توانید کدهایتان را بهبود بخشید؛ زیرا باید کارهای تکراری را به حداقل رساند. (Don’t repeat yourself)

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

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

پس می‌توان گفت که DRY یک اصل مهم در کد نویسی استاندارد است. برای دستیابی به این مهارت نیاز است که منطق و کد خود را به بخش‌های قابل استفاده‌ی مجدد (reusable) تقسیم کنید و در هر کجا که به آن منطق نیاز داشتید،‌ تنها به فراخوانی آن بپردازید.

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

SRP (Single Responsibility Principle)

اصل مسئولیت واحد یا SRP یکی از اصول پنج‌گانه‌ی SOLID است که احتملا پیش از این نامش به گوش‌تان خورده است. این اصول پنج‌گانه برای کمک به نوشتن‌ کدهای تمیز و ساختارمند و قابل نگه‌داری طراحی شده‌اند.

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

حال ممکن است از خود بپرسید که منظور از مسئولیت چیست؟

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

با تمرکز بر این اصل نیز کلاس‌هایتان تبدیل به کلاس‌هایی قدرتمند می‌شوند که تنها یک وظیفه را در پروژه‌تان بر عهده دارند.

KISS (keep it simple, stupid)

Martin Fowler در این‌باره می‌گوید:

هر احمقی می‌تواند کدی بنویسد که ماشین آن را درک کند؛ یک برنامه‌نویس خوب کدی می‌نویسد که انسان‌ها قادر به درک آن باشند.

این جمله تمام مفهوم KISS را در خود جای داده‌ است. در واقع این اصل به سادگی برای ما قابل درک است اما پیاده‌سازی عملی آن دشوار است. اگر شما به یک کد را که به خوبی KISS را پیاده‌سازی کرده‌باشد بررسی کنید، این سوال برایتان پیش خواهد آمد که بقیه‌ی کدهای این پروژه کجاست؟!

کد ساده‌ی مد نظر در این اصل باید سرراست و آسان و بدون هیچ هوشمندی خاصی باشد؛ البته که نوشتن کدهای ساده و غیر پیچیده یکی از نشانه‌های مهم برنامه‌نویس با کیفیت است.

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

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

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

Open-closed

این اصل نیز همانند اصل یکتایی مسئولیت‌ها، عضوی از اصول SOLID است. این اصل بیان می‌کند که موجودیت‌های نرم‌افزاری باید امکان گسترده‌تر شدن را داشته باشند اما امکان تغییر داده شدن را نداشته باشند.

احتمالا با خود بگویید که این اصل کمی بیش‌ از اندازه انتزاعی به نظر می‌رسد. اما هدف از این اصل این است که کدی داشته باشیم که هر بار با تغییر در نیازمندی‌های پروژه، نیاز به ایجاد تغییر در آن نباشد.

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

حال سراغ گسترش دادن برویم. اغلب اوقات استفاده از وراثت به عنوان روش پیش‌فرض گسترش دادن، مناسب نیست و بهتر است تا جای ممکن از این مورد دوری کنید. به عنوان قاعده‌ای کلی می‌توان گفت که بهتر است composition را بر وراثت (inheritance) اولویت دهیم.

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

با رعایت اصل open-close شما می‌توانید بدون تغییر دادن کد زیربنایی و پایه‌‌تان، به گسترش پروژه بپردازید.

YAGNI (You Aren’t Gonna Need It)

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

اهمیت این اصل در آن است که شما نباید بیش از حد مورد نیاز کد نویسی کنید. شما نباید مفاهیم اضافی را که ممکن است در آینده نیازمندشان باشید، به پروژه‌تان اضافه کنید. شما نباید سادگی پروژه‌تان را فدای فول آپشن بودن آن کنید؛ تنها باید مواردی را که به آن‌ها نیاز دارید پیاده‌سازی کنید، نه مواردی که ممکن است در آینده به آن نیاز پیدا کنید.

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

جمع‌بندی

حال که مروری بر اصول مهم کد نویسی خوب و استاندارد داشتیم، وقت آن رسیده که تمام این موارد را در عمل نیز پیاده کنید.

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

منبع