برنامه نویسی 672 بازدید

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

ابزارهای مناسب برای پیاده‌سازی اصول

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

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

ساخت کامپوننت‌ها به صورت بخش‌های مستقل کد به منظور انتشار، استفاده مجدد و مشارکت تیمی به طور طبیعی کمک می‌کند که هر توسعه‌دهنده‌ای از اصل «مسئولیت منفرد» (Single Responsibility) آگاه شود.

اصل مسئولیت منفرد

زمانی که شروع به کدنویسی می‌کنید، در طی دوره‌های زمانی بلندمدت کد شلوغ می‌شود. اغلب در کد خود کلاس‌ها یا ماژول‌هایی داریم که چندین کارکرد را اجرا می‌کنند. این وضعیت در نهایت منجر به ایجاد کلاس‌هایی می‌شود که از صدها یا هزاران خط کد تشکیل یافته‌اند.

اصل «مسئولیت منفرد» (Single Responsibility) بیان می‌کند که هر کلاس یا ماژول در برنامه باید کارکرد خاصی داشته باشد. به بیان دیگر یک کلاس یا ماژول در برنامه باید تنها مسئول وظایفی در رابط به با یک کارکرد خاص باشد. این وضعیت به کوچک و تمیز ماندن ماژول‌ها کمک می‌کند.

اصول کدنویسی

کد تمیز بهتر از کد هوشمندانه است

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

برای نمونه برخی افراد ترجیح می‌دهند از «عملیات سه‌تایی» (Ternary Operations) به جای گزاره‌های سنتی 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

قانون دیمیتر

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

«قانون دیمیتر» (Law of Demeter) ابتدا در سال 1987 از سوی «یان هلند» (Ian Holland) در «دانشگاه نورث‌استرن»‌ (Northeastern) معرفی شد. این اصل را می‌توان به صورت زیر خلاصه کرد:

  • هر واحد باید تنها دانش اندکی در مورد واحدهای دیگر داشته باشد و این واحدها صرفاً شامل واحدهای کاملاً مرتبط به واحد کنونی باشند.
  • هر واحد باید تنها با دوستان خود صحبت کند و صحبتی با بیگانگان نداشته باشد.
  • تنها با دوستان بلافصل خود صحبت کنید.

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

اصل YAGNI

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

به بیان دیگر YAGNI این ایده را مطرح می‌کند که هرگز نباید کدی را برای کارکردی که ممکن است در آینده نیاز داشته باشید بنویسید. این‌ها تغییرهایی هستند که شما به آن‌ها نیاز نخواهید داشت و زمان خود را به هدر می‌دهید.

کلمه YAGNI اختصاری برای جمله «شما به آن نیاز نخواهید داشت» (You Aren’t Gonna Need It) است و حالت خاصی از اصل KISS به عنوان پاسخی به افرادی که اصل DRY را بسیار جدی می‌گیرند محسوب می‌شود. برنامه‌نویسان کم‌تجربه اغلب تلاش می‌کنند با نوشتن کدهای با بیشترین حد از تجرید و ژنریک، از کدهای WET (کد با تکرار بالا) ‌اجتناب کنند. اما نمی‌دانند که تجرید بیش از حد هم اغلب به پدید آمدن کد حجیمی منتهی می‌شود که نگهداری آن ناممکن است.

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

به بیان ساده: در زمان حال و نه در آینده، زندگی کنید.

سخن پایانی

هر فردی می‌تواند کدی بنویسید که کامپیوتر درک کند. برنامه‌نویس خوب کدی می‌نویسد که انسان‌ها آن را درک کنند.

-مارتین فاولر

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

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

اگر این مطلب برای شما مفید بوده است، آموزش‌های زیر نیز به شما پیشنهاد می‌شوند:

==

بر اساس رای 1 نفر
آیا این مطلب برای شما مفید بود؟
اگر بازخوردی درباره این مطلب دارید یا پرسشی دارید که بدون پاسخ مانده است، آن را از طریق بخش نظرات مطرح کنید.

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

نظر شما چیست؟

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *