فرهنگ بازنگری کد

اواخر سال گذشته که شماره‌اش (به روایتی) ۱۳۹۶ بود، با ورود میثم، از مجموعهٔ شرکت‌های «زیر ده نفر» بیرون آمدیم و برای نخستین بار ده نفری شدیم. (در ابتدای همان سال، با ورود اولین همکار غیرِ شریک، سه نفره شده بودیم و در این مدت کوتاه، دو خداحافظی هم داشتیم.)

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

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

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

آنچه که بین این چهار نقطه و چهارنقطهٔ بعد می‌بینید، ترجمه‌ای آزاد است، با کمی خلاصه‌سازی از متن اصلی.

برای همه

• قبول کنید که بسیاری از تصمیم‌های برنامه‌نویسی، تابع نظرات شخصی افراد هستند. راه‌کارهای خود را سبک‌سنگین نمایید ولی برای رسیدن به نتیجهٔ مشترک زیاد معطل نکنید.
• به جای دستور دادن، سؤال کنید. («حالا اگه اسم این متغیر رو بذاریم فلان چی؟»)
• برای شفاف شدن موضوع، سؤال کنید. («این تیکه رو نمی‌فهمم. چه جوریه؟»)
• از ضمایر ملکی در ارتباط با متن برنامه استفاده نکنید. («کد من»، «کد تو»...)
• از عبارت‌هایی که ممکن است شامل برداشت شخصی شوند («احمقانه»، «مسخره»...) پرهیز کنید [هرچند که واقعاً منظوری نداشته باشید]. در نظر بگیرید که همه آدم‌های خوب و جذاب و باهوشی هستند و قصد بدی ندارند.
• صریح باشید و از یاد نبرید که مردم در فضای آنلاین، همیشه متوجه منظور کناییِ شما نمی‌شوند.
• فروتن باشید. («مطمئن نیستم، بذار یه سرچی بکنم.»)
• اغراق نکنید. («همیشه»، «هرگز»، «هیچ»...)
• در طعنه زدن احتیاط کنید. همه‌چیز عمومی‌ست. ممکن است رفتاری که بین شما و همکارهای قدیمی شما عادی شده، برای غریبه‌ها و تازه‌واردها مؤدبانه به نظر نرسد.
• حرف‌هایتان را، وقتی «متوجه نشدم»‌ها و «به نظر من»ها زیاد می‌شود، دو نفری [در چت‌های خصوصی] دنبال کنید و دستِ آخر، نتیجه را یک‌کاسه کنید و در یک کامنت خلاصه نمایید.
• کامنت خود را، وقتی با شخص خاصی صحبت می‌کنید، همیشه با منشن به او شروع کنید. با این کار در صورت روشن بودن اعلان‌هایش حتماً پیام شما را می‌بیند و بقیه هم متوجه می‌شوند که لازم نیست بخوانند و جواب بدهند.

وقتی کد شما بررسی می‌شود

توجه کنید که بررسی کد فرآیندی است که ممکن است چندین بار تکرار شود و چه بسا بررسی‌کنندگان متوجه نکته‌ای شوند که در بررسی اول متوجه آن نشده باشند.

• اولین بررسی‌کنندهٔ کد شما، خود شما هستید. قبل از آن که چیزی را از بالا بفرستید، یک بار تمام تغییرات را مرور کنید و ببینید که آیا همه چیز در جای خودش هست؟ آیا چیزهای بی‌ربطی هم این وسط وجود دارند؟ کدهای خطایابی را حذف کرده‌اید؟
• سپاسگزار پیشنهادهای بررسی‌کنندهٔ کدهای خود باشید. («دمت گرم. ردیفش می‌کنم.»)
• به خودتان نگیرید. آن‌ها کد شما را بررسی کرده‌اند، نه خودِ شما را.
• توضیح دهید که چرا این کار را کرده‌اید. («این جوری نوشتم که فلان طور بشود»، «اگر اسم این تابع را عوض کنم درست می‌شود؟»)
• تغییرات بی‌ربط و تمیزسازی‌های کد خود را در برنچ‌های دیگری انجام دهید.
• سعی کنید از چشم بررسی‌کننده به موضوع نگاه کنید.
• سعی کنید به تک‌تک کامنت‌ها پاسخ دهید.
• کامیت‌های مربوط به بازخوردهای اولیهٔ خود را جدا ارسال کنید. بررسی‌کننده‌ها باید بتوانند نتیجهٔ نظرات خود را به صورت جداگانه ببینند.

وقتی کد دیگران را بررسی می‌کنید

قبل از هر چیز بدانید که این تغییرات در پی چه هستند (مشکلی را برطرف می‌کنند؟ تجربه‌ٔ کاربری را بهتر می‌کنند؟ کدی را بهینه‌سازی می‌کنند؟).

سپس:

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

در پایان

همهٔ آنچه ترجمه کردم، به کار شرکت کوچک ما نمی‌آید و این در حالی‌ست که همهٔ آنچه در متن اصلی آمده بود را هم ترجمه نکردم.

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

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