ده قاعده کلی برنامه نویسی که هر برنامه نویس باید بداند (بخش اول)
هر کسی می تواند کدنویسی کند. اما آیا آن کد خوب نوشته شده است؟ اینجاست که نکته های زیادی نهفته است.
همه ما داستان های ترسناکی در مورد کدنویسی اسپاگتی شنیده ایم. ساختارهای بسیار زیادِ تکرار و تصمیم گیریِ if-else و برنامه ای که کلِ آن تنها با عوض کردن یک متغیر، تغییر می کند، توابعی که بنظر مبهم می آیند و به همین ترتیب. این طرز کد زدن زمانیست که می خواهید هر چه سریعتر محصولی تولید کنید در حالی که تنها یک ترم تجربه برنامه نویسی داشته اید و آنهم خودتان و به طور پراکنده یاد گرفته اید. وقت خود را صرف نوشتن کدهایی که کار کنند نکنید. سعی کنید کدهایی بنویسید که قابلیت حفظ و نگهداری داشته باشند- نه تنها توسط خودتان، بلکه توسط هر کسی که ممکن است در آینده روی نرم افزار کار کند. برای رسیدن به این هدف، در اینجا چندد قاعده کلی مطرح شده است که به شما کمک می کند تا کدهای تمییزتری بنویسید.
۱- قاعده ساده نوشتنِ کد
قاعده”ساده نوشتنِ کد” تقریبا در تمام زندگی استفاده می شود، اما بخصوص در پروژه های متوسط تا بزرگ مورد نیاز است. از همان ابتدا که شروع به تعریف حوزه ی ساخت برنامه می کنید، این فرآیند آغاز می شود. فقط صرف اینکه عاشق بازی های رایانه ای باشید به این معنی نیست که می توانید نسخه بعدیِ بازی Warcraft و GTA را طراحی کنید! زمانی که تصورکنید به اندازه کافی کدهای ساده نوشته اید، یک قدم به ساده نویسی کدها نزدیک شده اید. ساده سازی می تواند بی نهایت ادامه داشته باشد لذا از ساده سازی های کوچک شروع کنید. اما حتی بعد از شروع کدنویسی، همچنان ساده نویسی را رعایت کنید. کدهای پیچیده مدت زمان بیشتری برای طراحی و نوشتن نیاز دارند و لذا احتمال اینکه باگ و خطا داشته باشند، بیشتر است و اینکه بخواهید بعدا کدها را اصلاح کنید، سخت تر خواهد بود. به گفته ی Antoine de Saint-Exupery:” تکامل قابل دستیابی است، نه زمانی که چیزی برای افزودن نداشته باشیم، بلکه زمانی که چیزی برای دور انداختن نداشته باشیم.”
۲- قاعده عدم تکرار
قاعده” عدم تکرار” برای نوشتنِ کدهای ساده و قابل اصلاح حیاتی است. زمانی که کد می نویسید، قصد اجتناب از کپی شدنِ داده و منطق را دارید. اگر متوجه شدید که تکه کدی بارها و بارها تکرار شده است، این قاعده را نقض کرده اید. عکس قاعده عدم تکرار، قاعده “همه چیز را دو بار بنویس” است. یکی از بهترین راه های تشخیص این قاعده، پرسیدنِ سوال ِ اگر بخواهم به طریقی بخشی از برنامه را تغییر دهم، چند حوزه نیاز به اصلاح دارد؟ فرض کنید که در حال کدنویسیِ اپلیکیشن دایرکتوری پادکست هستید. در صفحه جست و جو، کدی برای دریافت جزییات پادکست دارید. در صفحه پادکست کدهایی برای واکشیِ جزییات پادکست دارید. در صفحه علاقه مندی ها، همان کدهای واکشی را دارید. سعی کنید تمام این اطلاعات را درون یک تابع به شکل abstract (کلاس یا تابع بدون بدنه) تعریف کنید تا زمانی که در آینده قصد ویرایش آن را داشتید، بتوانید همه این کارها را در یک نقطه انجام دهید.
۳- قاعده باز / بسته
چه اشیایی در جاوا تعریف کنید یا ماژول هایی در پایتون، باید کدها را طوری بنویسید که قابلیت تعمیم و گسترش داشته اما غیر قابل اصلاح و تغییر باشند. این قانون برای تمام انواعِ پروژه ها اعمال می شود اما اهمیت آن هنگام انتشار یک کتابخانه یا فریمورک که دیگران از آن استفاده می کنند، دو چندان است. برای مثال فرض کنید در حال نوشتن و نگهداریِ فریمورک GUI (واسط گرافیکی کاربر) هستید، می توانید به همان شکل آن را منتشر کنید و البته انتظار داشته باشید تا کاربران نهایی کدهای منتشرشده شما را اصلاح و کامل کنند. اما چهار ماه بعد که بروزرسانی سنگینی منتشر می کنید، چه اتفاقی می افتد؟ آنها چگونه همه ضمایم و افزودنی های شما را بدون اینکه تمام زحمت ها و کدهایشان را به باد دهند، پیاده سازی کنند. در عوض، کدهایی را منتشر کنید که جلوی اصلاح مستقیم را بگیرد و تشویق به تعمیم و گسترشِ همان برنامه نوشته شده، کند. این موضوع رفتار هسته را از رفتار اصلاح شده جدا می سازد. مزایای این کار، اول پایداری عالی (کاربران نمی توانند تصادفا رفتار هسته را بشکنند) و دوم قابلیت حفظ و نگهداری عالی تر است. (کاربران تنها نگران کدهای تعمیم داده شده هستند). قاعده باز / بسته کلید ساخت یک API (Application Programming Interface) خوب است.
قسمت دوم این مقاله را از لینک زیر بخوانید:
ده قاعده کلی برنامه نویسی که هر برنامه نویس باید بداند (بخش دوم)
