استراتژی‌هایی که باعث ایجاد سورس‌کدی ماندگار می‌شوند!

استراتژی‌هایی که باعث ایجاد سورس‌کدی ماندگار می‌شوند!

وقتی کد می‌زنید، اصول خاص بسیاری وجود‌ دارند که هدفشان ماندگار‌تر کردن سورس‌کد شما است که یکی از مهم‌ترین آن‌ها قانون DRY می‌باشد که مخفف واژگان Don`t Rpeat Yourself به معنی «عدم تکرار یک یا چند خط کد در مکان‌های مختلف سورس‌کد» است؛ علاوه بر این، اصول دیگری نیز وجود دارند که از آن جمله می‌توان به قانون Single Responsibility (هر کلاس فقط و فقط بایستی یک کار انجام دهد)، Law of Demeter (تا حد ممکن هر آبجکت از ساختار و ویژگی‌های هر چیز دیگری در سیستم ناآگاه باشد)، اصل Open/Closed (امکان توسعه دادن یک کلاس باید باید وجود داشته باشد اما باید جلوی تغییرات روی کلاس گرفته شود) و غیره. این‌ها اصول خوبی هستند که می‌توانید آن‌ها را دنبال‌ کنید و کدی حرفه‌ای بنویسید اما مشکل اصلی در ذهن داشتن هم‌زمان آن‌ها هنگام کدنویسی است که کار را کمی سخت می‌کند؛ علاوه بر این موارد، پیشنهاد ما این است که چند ایده‌ٔ گسترده‌تر را در حین کدنویسی مدنظر خود داشته‌ باشید که به‌نوعی کمک به خواناتر شدن سورس‌کد شما می‌شوند که در ادامه به توضیح آن‌ها خواهیم پرداخت. با سکان آکادمی همراه باشید.

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

بسیاری از افراد از روش Pair Programming (به‌معنی برنامه‌نویسی دوتایی) استفاده‌ می‌کنند که راهی عالی برای رسیدن به جواب سوالات بالا از سوی کسانی به‌‌جز خودِ شما است. در واقع در این نوع برنامه‌نویسی، ۲ برنامه‌نویس در کنار یکدیگر می‌نشینند که یکی کد می‌زد و دیگری صرفا نگاه می‌کند؛ برنامه‌نویسی که کدنویسی نمی‌کند نقشی همچون یک ناظر دارد که تمامی کارهای برنامه‌نویس دیگر را رصد می‌کند و هرکجا که ببنید وی اشتباهی مرتکب می‌شود، به وی گوشزد می‌کند.

مستندسازی
یکی از بهترین راه‌ها برای مطمئن شدن از این‌که کد شما قابل نگهداری و استفاده توسط شخص دیگری -و یا حتی خود شما- در آینده است، مستندسازی است؛ البته منظور این نیست که باید همه‌جا کامنت اضافه کنید، بلکه کامنت‌ها باید صرفا جاهایی نوشته شوند که سورس‌کد به اندازهٔ کافی گویا نیست.

نام‌گذاری مناسب
ترجیحا برای نام‌گذاری کلاس‌ها، فانکشن‌ها، متغیرها و غیره، از واژگانی کوتاه، مرتبط،‌ خوانا و قابل‌فهم استفاده کنید؛ به قول برنامه‌نویسی به نام Phil Karlton:

فقط ۲ چیز دشوار در علم کامپیوتر وجود داره: از بین بردن Cache و نام‌گذاری!

به تر و تمیز بودن کد اهمیت بدهید
آیا تا به حال به کدهای مبهم و گیج‌کننده که به اصطلاح «اسپاگتی» نامیده می‌شوند برخورده‌اید؟ یعنی کدهایی که یک کار مفید انجام می‌دهند اما با این‌ حال خودِ کد کاملا ناخوانا است؛ گرچه کامپلایرها در تجزیهٔ سورس‌کد خوب عمل‌ می‌کنند، اما این در حالی است که توسعه‌دهندگان برعکس هستند، یعنی تا کدی خوانا نباشد، به راحتی قادر به درک آن نخواهند بود!  

آنچه در کدنویسی باید همواره مد نظر داشته باشیم این است که اول سایر برنامه‌نویسان و توسعه‌دهندگان را مدنظر داشته‌ باشیم و وهلهٔ اول کد را طوری بنویسیم که توسط آن‌ها راحت تجزیه و تحلیل شود و در گام بعدی، به خوانده‌ شدن کد توسط کامپایلرها فکر کنیم؛ در یک کلام، واضح بودن کد را باید بر پیچیدگی ارجح قرار داده چراکه خوانایی به‌مراتب مهم‌تر از بهینه‌سازی‌های کوچک است. به گفته‌ٔ Brian Kernighan:

همه می‌دونن که در وهلهٔ اول دیباگینگ ۲ برابر سخت‌تر از نوشتن خود برنامه هست! بنابراین با توانایی‌ای که از خود انتظار دارین، ببینید پس از نوشتن یک برنامه، خودتون قادر به دیباگ کردنش هستین یا نه!

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

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

حال نوبت به نظرات شما می‌رسد؛ به نظر شما علاوه بر راه‌کارهای فوق، چه استراتژی‌های دیگری می‌توان اتخاذ نمود تا سورس‌کدی داشته باشیم که در آینده به سادگی قابل توسعه دادن‌ و دیباگ کردن -چه توسط خودمان و چه توسط سایر توسعه‌دهندگان- باشد؟ نظرات و دیدگاه‌های خود را با ما و سایر کاربران سکان آکادمی به اشتراک بگذارید.

منبع