چه چیزی شما را به یک برنامه نویس خوب تبدیل می‌کند؟ اگر این سوال را از 10 نفر بپرسید، قطعا 10 پاسخ متفاوت خواهید گرفت. گرچه ممکن است پاسخ‌ها با کلمات مختلف بیان شوند، اما احتمالا یک معنی را می‌رسانند. از نظر من، یک برنامه نویس خوب کسی است که توانایی درک مسئله داشته باشد، بتواند یک راه حل مناسب پیدا کند، آن راه حل را به کاربر نهایی ارائه دهد و در نهایت برای رسیدن به این هدف نهایی تلاش کند.
چگونه می‌توان یک کد عظیم را با این همه مشارکت مدیریت کرد؟
انتظار می‌رود که هر یک از اعضای مشارکت کننده کدی تمیز، خوانا و قابل نگهداری بنویسد. اما چگونه این کار را انجام میدهید؟ مسلما از اصول کد نویسی خاصی پیروی می‌کنید. این اصول باعث راحتی کار شما و دیگران می‌شود.
ابزار مناسب جهت اجرای این اصول
ابزارهایی وجود دارد که پیروی از این اصول را آسان می‌کند و متأسفانه آنطور که باید مورد بحث قرار نمی‌گیرد. پیشنهاد من به شما این است که به دنبال آنها باشید. به عنوان مثال، توسعه دهندگان فرانت-اند از هاب‌های ابری مانند Bit.dev برای انتشار کامپوننت‌های مستقل استفاده می‌کنند.
چگونه این مورد در پیروی از اصول کمک می‌کند؟
- آزادی انتشار کامپوننت‌ها از هر پایگاه کد به معنای اشتراک و استفاده مجدد کد بیشتر است، مانند پیروی از اصل DRY. همچنین بدان معنی است که شما یک سیستم طراحی کامل با کامپوننت‌های رابط کاربری ایجاد نخواهید کرد که هرگز از آن استفاده نکنید. در عوض هر کامپوننت فقط در صورت لزوم ساخته و منتشر می‌شود، طبق اصل YAGNI.
- کامپوننت‌های سازنده به عنوان قطعه‌ای مستقل از کد که برای انتشار، استفاده مجدد و مشارکت (به عنوان کد مستقل) در نظر گرفته شده است، طبیعتا توجه هر یک از توسعه دهندگان را به اصل مسئولیت منفرد بیشتر جلب می‌کند.
بررسی کامپوننت‌های منتشر شده React
در اینجا چهار اصل کد نویسی وجود دارد که هر برنامه نویس باید از آنها پیروی کند.
مسئولیت منفرد
هنگامی که شروع به نوشتن کد می‌کنید، بعد از مدتی طولانی کد شما به هم ریخته می‌شود. کلاس‌ها و ماژول‌هایی خواهید داشت که چندین کار را انجام می‌دهند. این در نهایت به کلاس‌هایی با صدها و هزاران خط کد ختم می‌شود.
این اصل می‌گوید که هر کلاس یا ماژول در یک برنامه فقط باید وظیفه‌ای خاص داشته باشد. به عبارت دیگر، یک کلاس یا ماژول در یک برنامه فقط باید وظایف مربوط به یک تابع خاص را بر عهده بگیرد. این امر به شما کمک می‌کند تا ماژول‌های خود را با حداقل کد و تمیز نگه دارید.
کد تمیز بهتر از کد هوشمند است
هنگام نوشتن برنامه‌ها، این تمایل وجود دارد که شما با نحوه نوشتن کد می‌خواهید خود را باهوش نشان دهید. این کد هوشمندانه بیشتر شبیه یک معما است تا یک قطعه واقعی از کد قابل درک. همچنین خواننده باید بسیار باهوش باشد تا درک کند کد شما چه کاری انجام می‌دهد. نوشتن این نوع کد هرگز خوشایند نیست. هیچ کس واقعا اهمیت نمی‌دهد که کد شما تا چه اندازه هوشمند است، بلکه این تمیزی کد و درک آن است که برای همه مهم می‌باشد.
به عنوان مثال، برخی از افراد ترجیح می‌دهند از عملگرهای سه گانه استفاده کنند که به دنبال آن یک عبارت if-else خواهد آمد. این کاملا خوب است، زیرا عملگرهای سه گانه عملیات استاندارد برنامه نویسی هستند. آنچه خوشایند نیست این است که عبارات سه گانه را انباشته کنید.
let A = 10;
let B = 3;
let C = 25;
(A>B?A:B)// fine
(A>B?(A>C?A:C):(B>C?B:C))//not fine
if(A>B){
(A>C?A:C)
}else{
(B>C?B:C)
}//betterقانون دمتر
وقتی ماژول‌ها به یکدیگر وابسته شوند، کاملا جفت می‌شوند. یعنی این که یک کلاس وابستگی زیادی به سایر ماژول‌ها دارد. در نتیجه وابستگی کم انعطاف پذیری و قابلیت استفاده مجدد کد را کاهش می‌دهد.
قانون دمتر برای اولین بار توسط ایان هالند در سال 1987 ارائه شد. این اصل را می‌توان به صورت زیر خلاصه کرد:
- هر بخش فقط باید دانش محدودی در مورد بخش‌های دیگر داشته باشد؛ یعنی فقط بخش‌های نزدیک مربوط به بخش فعلی هستند.
- هر بخش فقط باید با دوستان خود صحبت کند و با غریبه‌ها ارتباط نداشته باشد.
این اصل به شما امکان می‌دهد تا کلاس‌ها و کدهایی مستقل داشته باشید که به دلیل کم شدن وابستگی‌ها اتصال آزادتری دارند. همچنین هر تغییر جدید که ایجاد می‌شود باید در دوستان نزدیک منعکس شود.
YAGNI (به آن نیاز نخواهید داشت - You Aren’t Gonna Need It)
ما همه تمایل داریم که از قبل برنامه ریزی کنیم و برای آینده آماده شویم. اما این در برنامه نویسی خیلی کاربرد ندارد. این اصل درمورد افرادی است که کدی را می‌نویسند که در آینده هرگز به آن نیازی نخواهند داشت، اما فکر می‌کنند چنین اتفاقی خواهد افتاد.
به عبارت دیگر، YAGNI ایده‌ای است که شما هرگز نباید برای عملکردی که ممکن است در آینده به آن نیاز داشته باشید کد نویسی کنید. به احتمال زیاد به آن نیازی نخواهید داشت و صرفا وقت خود را تلف خواهید کرد.
شما می‌توانید این را به عنوان یک کاربرد خاص از اصل KISS به عنوان پاسخی به کسانی که اصل DRY را جدی می‌گیرند، مشاهده کنید. برنامه نویسان بی تجربه معمولا با نوشتن انتزاعی‌ترین و عمومی‌ترین کد ممکن نهایت تلاش خود را می‌کنند تا از ساخت WET (Write Everything Twice) کد خود جلوگیری کنند. اما انتزاع بیش از حد در کد منجر به غیر قابل نگهداری شدن آن می‌شود.
راه حل این است که کد را فقط وقتی انتصاب می‌کنید که قبلا دیده باشید نیاز به انتزاع دارد. و اینکه اصل DRY را برای کدهایی که فکر می‌کنید ممکن است در آینده بارها و بارها بنویسید، اعمال نکنید.
به زبان ساده‌تر در حال زندگی کنید، نه در آینده.
جمع بندی
مارتین فاولر: "هر احمقی می‌تواند کدی بنویسد که کامپیوتر آن را درک کند. اما برنامه نویسان خوب کدی می‌نویسند که بشر بتواند آن را درک کند."
همانطور که در نقل قول آمده، نوشتن کد تمیز و قابل درک این روزها تقریبا یک نیاز است. شما نمی‌توانید یک شبه کد تمیز بنویسید. بلکه این کار به تمرین و تکرار نیاز دارد. شما باید به آرامی روش برخورد با مشکل را تغییر دهید و راه حل‌هایی را به روشی تمیز استخراج کنید. این تجربه یک شبه به دست نخواهد آمد، بلکه ماه‌ها زمان می‌برد و در طی چند پروژه به طول می‌انجامد.
از آنجا که برنامه نویسی یک کار گروهی است، موفقیت در پروژه تا حد زیادی به تیم شما بستگی دارد. از این رو بسیار ضروری است که افراد کدهایی را بنویسند که همکاران آنها بتوانند به راحتی آن را درک و نگهداری کنند. یک کدنویس افسانه‌ای به صورت انفرادی هرگز تیم را به جایی نمی‌رساند بلکه چندین برنامه نویس متوسط هستند که تیم را به اوج می‌برند.
امیدوارم این توضیحات برایتان مفید واقع شود. در صورت تمایل تجربیات خود را در مورد کد نویسی در بخش زیر به اشتراک بگزارید تا دیگران هم از آن بهره ببرند.
دیدگاه و پرسش
در حال دریافت نظرات از سرور، لطفا منتظر بمانید
در حال دریافت نظرات از سرور، لطفا منتظر بمانید