کمتر کثیف کد بزنیم

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

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

رهنمودها و راهکارهای مرسوم به ما می‌گویند که برای قطعه‌های کد خود کامنت‌هایی بگذاریم تا بعداً چیزهایی را به یادمان بیاورند، و این که تلاش کنیم از یک الگوی طراحی (مثل MVC که اینجا درباره‌اش نوشته‌ام) تبعیت کنیم، و این که نام‌های خوبی برای متغیرها و تابع‌ها انتخاب کنیم و چیزهایی کلی از این قبیل.

کامنت گذاشتن کار خوبی است، اما همیشه هم جالب و راهگشا نیست. قول معروفی است که می‌گوید «بکوش کامنت در متن کد تو باشد...»

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

واضح است که معیارهای شخصی (اگر اساساً وجود داشته باشند)، به درد کار تیمی نمی‌خورد. همه معتقدند که خودشان تمیز کد می‌نویسند و کار بقیه کثیف است و همه هم به یک میزان حق دارند و حق ندارند.

حضرت جفری وی، بنیان‌گذار لاراکستز، کتابی دارد با این عنوان:

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

در هر حال، دیدن یک‌جای این نکته‌ها برایم بسیار آموزنده بود و بد نیست خلاصه‌ای از آن‌ها را به اشتراک بگذارم، شاید به کار کس دیگری نیز بیاید.

جفری وی در این نکته‌ها،‌ علامت‌هایی را نشان می‌دهد که نشان از کدنویسی کثیف دارند.

یک دست و چند هندوانه

اصل تک‌وظیفگی را تقریباً همه می‌دانیم، اما خوب رعایت نمی‌کنیم.

جفری وی پیشنهاد می‌کند کاری را که کلاس یا متد یا تابع ما انجام می‌دهد، با زبان آدمیزاد، به صورت یک جمله برای خودمان بگوییم و اگر کلمهٔ «وَ» را زیاد از زبان خودمان شنیدیم، بدانیم که راه را اشتباه رفته‌ایم.

هر کلاس یا متد فقط باید یک کار را انجام دهد و بس.

شک در انتخاب نام

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

سازندگان همه‌کاره

متدهای Constructor در هر کلاس، فقط به این درد می‌خورند که وابستگی‌های (Dependencies) آن کلاس را فراهم کنند و بس. اگر داخل این متد کاری غیر از تزریق وابستگی‌ها انجام دادیم، بهتر است تا دیر نشده، کد را بازنویسی کنیم.

وی در ادامه خاطرنشان می‌سازد که دیگر شورش را هم درنیاوریم. اگر کلاس ما به بیشتر از مثلاً چهار وابستگی احتیاج داشت، زیاده‌خواهی می‌کند و باید به کلاس‌های کوچک‌تر خرد شود.

جفری وی برای این عدد «چهار»، به روایتی که از تیلور اوتول (خالق لاراول) نقل کرده، استناد می‌کند:

معمولاً کلاس‌هایی که بیش از چهار وابستگی دارند را دوباره طراحی می‌کنم.

و خودش می‌افزاید:

یکی از اصول ابتدایی برنامه‌نویسی شیءگرا آن است که میان تعداد پارامترهای یک کلاس یا یک متد، و میزان انعطاف‌پذیری (و در اینجا آزمون‌پذیری) آنها رابطه‌ای معکوس برقرار است. با حذف هر پارامتر یا نیازمندی، کد خود را اندکی بهتر کرده‌اید.

بلندتر، بدتر

اجازه ندهید متدها طولانی شوند. بهترین متدها آن‌هایی هستند که چند خط بیشتر ندارند. حتی اگر می‌شد که یک‌خطی باشند، چه بهتر!

پیمان چه می‌گوید؟

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

شرطی‌های بسیار

حضرت در ادامه می‌فرماید که از ifهای تو در تو بترسیم و در گامی محافظه‌کارانه‌تر، از به کار بردن ساختار switch به‌شدت پرهیز کنیم. او معتقد است این شرطی‌های تو در تو، برنامه‌نویسان را به اشتباه می‌اندازند و سر و کلهٔ باگ‌ها پیدا می‌شود.

در عوض پیشنهاد می‌کند اسلوب نگارش متدهای یک‌خطی و الگوهای چندریختی را جایگزین این همه اما و اگر کنیم.

باگ‌ها موجوداتی اجتماعی هستند!

جفری وی با اشاره به این که حشره‌ها و انگل‌ها دوست دارند با هم زندگی کنند و «باگ» هم در زبان انگلیسی به معنای «حشره» است، می‌گوید که اگر متوجه باگ در جایی از کد شدیم، یا باید منتظر بروز باگ‌های بعدی در حوالی همان نقطه بمانیم و یا دست به کار شویم و آن قطعه را به طور کامل ضدعفونی (=بازنویسی) کنیم.

البته برای نزدیکی فیزیکی باگ‌ها، استدلال غیرجانورشناسانه‌ای هم ارائه می‌کند که ترجمهٔ عین عبارت‌ چنین است:

دلیل وجود باگ‌ها آن است که شما نتوانسته‌اید کد خودتان را در وهله‌ی اول به‌درستی بشناسید. حتماً بیش از حد پیچیده بوده که چنین شده است! و کیست که نداند کد پیچیده، اغلب پیام‌آور کد ناپایدار هم هست.

و این یکی:

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

پانوشت ۱:

این حرف‌ها را قبلاً در توییتر نقل کرده بودم (اینجا) و سمانه هم در کانال تلگرامیِ خوب و پرمحتوایش (اینجا) یکجا کنار هم آورده بود و که از نشانی‌اش برای ارجاع به دوستانم استفاده می‌کردم.

پانوشت ۲:

نقل‌قول‌هایی که در متن می‌بینید، حاصل ترجمهٔ ویراست‌نشدهٔ خودم از کتاب جفری وی هستند که نیمه‌کاره رهایش کردم. داستان این است که برای ترجمهٔ فارسی کتاب با ارسال یک پیام به نویسنده اجازه گرفتم و بلافاصله شروع به کار کردم و پنج فصل (نزدیک سی درصد) هم پیش رفتم و باقی را گذاشتم برای هر زمان که اجازه داد. چون جوابی نگرفتم، کار را رها کردم و طبعاً در جایی هم منتشرش نمی‌کنم، اما استفاده به این شکل، قاعدتاً در محدودهٔ Fair-Use می‌گنجد و نیازی به کسب اجازه ندارد.