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

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

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

بسیاری از افراد از روش Pair Programming یا #برنامه‌نویسی دونفره استفاده‌ می‌کنند که راهی عالی برای رسیدن به جواب سؤالات بالا از سوی کسانی به‌‌ جز خودِ شما است. در واقع، در این نوع برنامه‌نویسی، دو برنامه‌نویس در کنار یکدیگر می‌نشینند که یکی کد می‌زند و دیگری صرفاً نگاه می‌کند! برنامه‌نویسی که کدنویسی نمی‌کند، نقشی همچون یک ناظر دارد که تمامی کارهای برنامه‌نویس دیگر را رصد می‌کند و هر کجا که ببنید وی اشتباهی مرتکب می‌شود، به وی گوشزد می‌کند.

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

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

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

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

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

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

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

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

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