وقتی کد می‌زنید، اصول بسیاری وجود دارند که هدفشان ماندگار‌تر کردن و بهبود قابلیت نگهداری سورس کد شما است. یکی از مهم‌ترین این اصول، قانون DRY می‌باشد که مخفف واژگان Don`t Rpeat Yourself به معنی «عدم تکرار یک یا چند خط کد در مکان‌های مختلف سورس‌کد» است. علاوه بر این، اصول دیگری نیز وجود دارند که برخی از آنها عبارتند از:
- قانون Single Responsibility : هر کلاس فقط و فقط باید یک کار انجام دهد)،
- Law of Demeter : تا حد ممکن هر آبجکت از ساختار و ویژگی‌های هر چیز دیگری در سیستم ناآگاه باشد)،
- اصل Open/Closed :امکان توسعه دادن یک کلاس باید وجود داشته باشد اما باید جلوی ایجاد تغییرات روی کلاس گرفته شود)
با پیروی از این اصول، می‌توانید کدهایی حرفه‌ای و تمیز بنویسید که قابلیت نگهداری بالایی داشته باشند. اما مشکل اصلی به خاطر سپردن و رعایت هم‌زمان این اصول هنگام کدنویسی است که کار را کمی سخت می‌کند. به همین دلیل، پیشنهاد می‌کنیم در کنار آنها، چند ایده‌‌ی کلی‌تر را نیز هنگام کدنویسی مدنظر قرار دهید؛ ایده‌هایی که نه تنها می‌توانند به خواناتر شدن کد شما کمک کنند بلکه در ماندگاری و افزایش قابلیت نگهداری کد هم بسیار تاثیرگذار هستند. در ادامه، این موارد را توضیح خواهیم داد.
از دید یک توسعه‌دهنده دیگر به کدهایتان نگاه کنید
در حالی که کد می‌زنید، سعی کنید دائماً آن را از دید یک توسعه دهنده جدید فرضی که به پروژه پیوسته است بررسی کنید. خواندن کد را برای اولین بار تصور کنید؛ آیا جریان کلی را می‌فهمید؟ آیا طوری کد زده‌اید که با بقیهٔ پروژه سازگار باشد؟ اگر قرار بود بدون دانستن اسم فلان چیز به دنبال آن بگردید، آیا می‌توانستید به سرعت آن را پیدا کنید؟
استفاده از روش برنامه نویسی دو نفره
بسیاری از افراد از روش Pair Programming یا #برنامه‌نویسی دونفره استفاده می‌کنند که راهی عالی برای رسیدن به جواب سؤالات بالا از سوی کسانی به جز خود شما است. در واقع، در این نوع برنامه‌نویسی، دو برنامه‌نویس در کنار یکدیگر می‌نشینند که یکی کد می‌زند و دیگری صرفاً نگاه می‌کند! برنامه‌نویسی که کدنویسی نمی‌کند، نقشی همچون یک ناظر دارد که تمامی کارهای برنامه‌نویس دیگر را رصد می‌کند و هر کجا که ببنید وی اشتباهی مرتکب می‌شود، به وی گوشزد می‌کند.
مستندسازی کنید
یکی از بهترین راه‌ها برای مطمئن شدن از اینکه کد شما قابل نگهداری و قابل استفاده توسط شخص دیگری (و یا حتی خود شما) در آینده است، مستندسازی است؛ البته منظور این نیست که باید همه جا کامنت اضافه کنید، بلکه کامنت‌ها باید صرفاً جاهایی نوشته شوند که سورس‌کد به اندازهٔ کافی گویا نیست.
چگونه مستندسازی سورس‌کد باعث افزایش قابلیت نگهداری آن می‌شود؟
مستندسازی سورس کد با توضیح دادن هدف، منطق و نحوه‌ی عملکرد بخش‌های مختلف برنامه، به‌طور مستقیم باعث افزایش خوانایی و بنابراین نگهداری کد می‌شود.
وقتی توسعه‌دهنده‌ای با کدی مواجه می‌شود که قبلاً توسط شخص دیگری یا حتی خودش در گذشته نوشته شده، توضیحات دقیق و به‌موقع در قالب کامنت‌ها، فایل‌های README یا مستندات API کمک می‌کند سریع‌تر منطق پشت کد را درک کند، بدون اینکه نیاز باشد خط‌به‌خط آن را تحلیل کند. این مستندسازی به‌ویژه در پروژه‌های تیمی، هنگام دیباگ یا توسعه‌ی بیشتر کد، از بروز سردرگمی جلوگیری کرده و بهره‌وری را بالا می‌برد. برای آشنایی با چگونگی مستندسازی نرم افزار و انواع آن، به مقاله‌ای با همین نام در سکان آکادمی مراجعه کنید.
نام‌گذاری مناسب داشته باشید
ترجیحاً برای نام‌گذاری کلاس‌ها، فانکشن‌ها، متغیرها و غیره، از واژگان و ساختارهایی کاملاً کوتاه، مرتبط، خوانا و قابل‌فهم استفاده کنید.
به قول برنامه‌نویسی به نام Phil Karlton:
فقط دو چیز دشوار در علم کامپیوتر وجود داره: از بین بردن کَش و نام‌گذاری بخش‌های مختلف سورس کد!
به تر و تمیز بودن کد اهمیت بدهید
آیا تا به حال به کدهای مبهم و گیج‌کننده که به اصطلاح «اسپاگتی» نامیده می‌شوند، برخورده‌اید؟ یعنی کدهایی که یک کار را به خوبی انجام می‌دهند اما با این حال، خودِ کد کاملاً ناخوانا است! گرچه کامپلایرها در تجزیه‌ی سورس‌کد خوب عمل می‌کنند، اما این در حالی است که توسعه‌دهندگان برعکس هستند؛ یعنی تا کدی خوانا نباشد، به راحتی قادر به درک آن نخواهند بود!
آنچه در کدنویسی باید همواره مد نظر داشته باشیم این است که اول سایر برنامه‌نویسان و توسعه‌دهندگان را مد نظر داشته باشیم و در وهله‌ی اول طوری کد بزنیم که توسط ایشان به راحتی تجزیه و تحلیل شود و در گام بعدی، به اجرا شدن کد توسط کامپایلر فکر کنیم. در یک کلام، واضح بودن کد را باید بر پیچیدگی ارجح دانست زیرا خوانایی به مراتب مهم‌تر از بهینه‌سازی‌های کوچک است.
به گفته‌ٔ Brian Kernighan:
همه می‌دونن که در وهلهٔ اول دیباگینگ دو برابر سخت‌تر از نوشتن خود برنامه هست! بنابراین با توانایی‌ای که از خود انتظار دارین، ببینید پس از نوشتن یک برنامه، خودتون قادر به دیباگ کردنش هستین یا نه!
آینده‌نگری داشته باشید
چند چیز وجود دارد که ضربات مهلکی به سورس‌کد شما می‌زند. گرچه ممکن است اشتباهاتی از این دست در کوتاه مدت دردسری برایمان ایجاد نکنند، اما این در حالی است که در دراز مدت بهای سنگینی باید بابت آنها پرداخت کرد! به طور مثال، می‌شود به استفاده از کامپوننتی که برای یک کار خاص توسعه داده شده است در جایی نامناسب اشاره کرد. شاید در کوتاه مدت این قضیه مشکلی برایمان به وجود نیاورد، اما فرض کنیم که در آینده قصد ریفکتور کردن و یا اضافه کردن یک قابلیت جدید به آن کامپوننت را داشته باشیم و آنجا است که حسابی به دردسر خواهیم افتاد.
در همین راستا، در کدنویسی هرگز آسایش، سهولت و لذت آنی را به ثبات، یکپارچکی و ساختاریافتگی همیشگی ترجیح ندهید و در حین توسعهٔ پروژه، کمی هم آینده‌نگری داشته باشید.
حال نوبت به نظرات شما می‌رسد. به نظر شما علاوه بر راه‌کارهای فوق، چه استراتژی‌های دیگری می‌توان اتخاذ نمود تا سورس‌کدی داشته باشیم که قابلیت نگهداری بالایی داشته باشد و در آینده به سادگی قابل توسعه دادن و دیباگ کردن باشد (چه توسط خودمان و چه توسط سایر توسعه‌دهندگان)؟
نظرات و دیدگاه‌های خود را با سایر کاربران سکان آکادمی به اشتراک بگذارید.