بازنگری کد یا Code Review چرا و چگونه؟ 1391/03/29

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

چرا بازنگری کد یا code review؟

• تحویل محصولی با ایراد کمتر به مشتری؛ یعنی ایرادای محصول خیلی سریع و در همون مرحله توسعه خودشون رو نشون بدن.
• بازنگری کد باعث به اشتراک گذاری دانش بین افراد تیم می‌شه. یادتون نره حتا اگه شما بهترین کونک‌فو کار باشین همیشه حرکتی هست که بتونید از یکی دیگه یاد بگیرید. برای مثال تو صنعت ما کوچکترین چیزی که می‌شه یاد گرفت یه کلید میانبر هستش.
• چون شما می‌دونین که کد شما قرار هست توسط یه هم‌تیمی که بهش از لحاظ حرفه‌ای احترام می‌ذارین بررسی بشه به صورت خودکار کُد بهتری می‌نوسین.
• پس از گذشت چند ماه از ایده وجود مرحله بازنگری کُد تو نارمند، تیم ما داره خیلی بهتر و تمیز‌تر برنامه‌نویسی می‌کنه. واقعا کم پیش میاد که روشی تو صنعت نرم‌افزار انتخاب کنی و اینقدر سریع و خوب جواب بده.
• به گفته یکی از توسعه دهنده‌های سابق گوگل یکی از بزرگترین دلایل کیفیت بالای کد تو گوگل وجود بازنگری کد هستش.
• همونطور که جف آتوود اشاره می‌کنه سالهاست که طرفدارای روش‌های اجایل، مخصوصا xp، ما رو به برنامه‌نویسی دونفره یا pair programming ترغیب کردن در حالی که به نظر من بازنگری کد، ما رو بیشتر به هدفمون نزدیک می‌کنه.

وقتی داریم کُد یکی دیگه رو بازنگری می کنیم دنبال چی باشیم؟

همونطور که می‌دونین تو تیم های مختلف این آیتم ها می‌تونن کم و زیاد بشن ولی در کل پس از مدتی تمرین یه چک لیستی مخصوص اون تیم آماده میشه و تو بازنگری های بعدی از اون استفاده می‌شه. کم کم این چک لیست تکمیل تر می‌شه. بعد مدتی این چک لیست تبدیل می‌شه به مدرکی در مورد بهتر شدن کیفیت کد. چون تیم داره همه‌ی اون موارد رو رعایت می‌کنه و این خیلی عالیه :) 
اما وقتی داریم کد دیکران رو بازنگری می کنیم دنبال چی باشیم؟

• دنبال باگ‌های منطقی باشین که نویسنده‌ی کد اونها رو ندیده
• به دنبال ایراد‌های مسخره باشین که ممکنه برای بهترین برنامه نویس‌ها هم پیش بیاد: مثلا اشتباه املایی در اسم کلاس TribByAirplane به جای TripByAirplane
• شما به عنوان یه توسعه دهنده‌ی حرفه‌ای باید بدونین کد خوب چی هستش. حتما کتاب clean code رو بخونین و به دنبال کد‌های زشت‌ای باشین که می‌تونن refactor شن تا خوانایی کد بهتر شه.
• به هنگام خوندن کد اگه این سوال برای بازنگر پیش بیاد که «این قسمت از کد دقیقا داره چیکار می کنه؟» نویسنده دو راه پیش رو داره که اولی بهتر از دومی هستش: یکی اینکه کُدش رو تمیزتر کنه یا اینکه برای اون قسمت از کدش توضیحات بنویسه.
• در حین بازنگری کد هم نویسنده کد و هم کسی که داره بازنگری رو انجام می‌ده فرصت دارن که از هم دیگه یاد بگیرن. مثلن ممکن هستش که بازنگر از نویسنده بپرسه «صب کن صب کن! با کدوم کلید میانبر این کار رو انجام دادی؟»

چند نکته در مورد بازنگری کد

• جلسه بازنگری کد نباید بیشتر از ۱۵ تا ۲۰ دقیقه طول بکشه چون هر دو نفر رو کلافه می‌کنه. به همون خاطر سعی کنید کدهاتون رو تیکه‌تیکه و پی‌در‌پی با یه همکار بازنگری کنین و کارتون رو انباشته نکنین.
• نویسنده کد بایستی لیستی از مواردی که با کمک همکارش به اون‌ها رسیدن که باید بازنگری بشن رو بنویسه و در اولین فرصت به سراغ کدش بره و اونها رو تصحیح کنه یا اینکه اگه اون موارد خیلی ریز باشن تو همون جلسه‌ی چند دقیقه ایِ بازنگریِ کد، اون موارد رو اعمال کنه.
• بازنگری از راه دور از هیچی بهتر هستش. ولی به نظر من مقداری یادگیری وقتی دو نفر همکار کنار هم، روبروی یه مانیتور نشستن و کدها رو بررسی می‌کنن خیلی خیلی بیشتر هستش.

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

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

خوب حالا باید از کجا شروع کرد؟

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

البته ما تو نارمند روش دیکتاتوری مهربون رو انتخاب کردیم. یعنی هر تیکه از کدی که نوشته میشه چه کد سرورساید باشه چه کد مربوط به html و js و css بایستی توسط یه نارمندی دیگه بررسی بشه.

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