Thread by @BashirSadjad

۱) وقتی ۱۱ سال پیش آمدم گوگل، برنامه‌ ۳-۴ سال کسب تجربه‌ی مهندسی خوب و بعد بازگشت به ایران بود. قسمت دوم برنامه متاسفانه عملی نشد ولی بخش اول چرا. شاید به‌اشتراک گذاشتن بعضی از این تجربه‌ها در فضای فارسی مفید باشد. یکی از مهم‌ترین این‌ها اهمیت «بازبینی کد» است و نقش #نرم‌ابزار //

۲) به‌خصوص وقتی سروکارم با گیت‌هاب است، ضعف ابزارها آشکار است. ولی اول چرا بازبینی کد (code review) مهم است. برای من لااقل این موارد مهم اند:
آ) خوانایی کلی کد و پرهیز از ساختارهای بد
ب) ساده‌سازی طراحی و پیاده‌سازی
پ) انتقال تجربه
ت) کشف خطا
ث) ارزیابی //
google.github.io/eng-practices/…

۳) در مورد آ یک ویژگی گوگل این است که تقریبا کد همه‌ی تیم‌ها در یک مخزن (repository) مرکزی است و شما همیشه از سر (HEAD) استفاده می‌کنید (می‌دانم کمی عجیب است ولی خیلی مشکلات ساخت و یک‌پارچگی را حل می‌کند). با این‌که چند ده‌هزار برنامه‌نویس مدام مشغول افزودن به این مخزن‌ اند، //

۴) ولی وقتی به کد تیم‌های مختلف نگاه می‌کنید انگار همه را یک تیم نوشته. این مهم است، چون مرز بین تیم‌ها را کم‌رنگ می‌کند و هم‌کاری بین‌تیمی را افزایش می‌دهد. برای این،‌ باید از یک سری قوائد (norms) و شیوه‌ها (style) استفاده کرد که قسمتی را #نرم‌ابزار به‌شکل خودکار انجام می‌دهد //

۵) و بقیه هم توسط بازبین کد اعمال می‌شود. خیلی از این شیوه‌ها به‌شکل عمومی هم منتشر شده، اینجا:
google.github.io/styleguide
مهندسی که به‌اندازه‌ی کافی در زبانی متبحر شود، درجه‌ی «خوانایی» (readability) می‌گیرد. هر تغییر کد، نیاز به تایید چنین کسی دارد (و یک صاحب زیرشاخه). //

۶) اهمیت مورد ب این است که خیلی وقت‌ها اولین روشی که برای پیاده‌سازی یک ایده به‌نظر می‌رسد، از نظر سادگی یا کارایی به‌ترین نیست و یک جفت چشم دیگر کلی به آدم کمک می‌کند. این البته رابطه‌ی تقریبا مستقیم با تجربه‌ی نویسنده کد دارد. این نمودار هم یک شاهد: //
sback.it/publications/i…

۷) از نظر من مورد پ شاید مهم‌ترین باشد. برای فهم یک سامانه، هیچ‌چیز جای خواندن کد آن را نمی‌گیرد. بازبینی کد، اعضای تیم را مجبور می‌کند که از کار هم سر در بیاورند و اصولا هیچ‌جایی وابسته به یک نفر نشود (تست اتوبوس). //
en.wikipedia.org/wiki/Bus_factor

۸) مورد ت بعضی وقت‌ها خودبه‌خود در یک بازبینی خوب اتفاق می‌افتد ولی به‌نظرم نباید هدف مهمی در بازبینی باشد. برای کشف و جلوگیری از خطا (bug) باید تست واحد، یک‌پارچگی و سربه‌سر نوشت (unit/integration/end-to-end test). #نرم‌ابزار برای این کار هم فراوان است (ولی فراتر از این رشته) //

۹) مورد ث شاید خیلی در ابتدا به‌نظر نرسد ولی هر سال وقتی زمان ارزیابی مهندسان می‌رسد، بخشی از به‌ترین ارزیاب‌های من معمولا کسانی‌ اند که کد من را به‌دقت خوانده‌اند. ارزیابی ما اصولا خیلی «هم‌کار محور» است که به‌نظرم به‌تر از «مدیر محور» است ولی صحبت از آن مجالی دیگر می‌طلبد. //

۱۰) اما در مورد #نرم‌ابزار برای بازبینی: گوگل سرمایه‌گذاری زیادی روی ابزارها کرده و برای بازبینی کد، ابزاری به‌اسم Critique وجود دارد که چند ابزار دیگر را در خودش یک‌پارچه کرده. توصیف ویژگی‌های این سامانه هم مفصل است و هم احتمالا بعضی‌هایش محرمانه. //
michaelagreiler.com/code-reviews-a…

۱۱) اگر با گیت‌هاب سروکار دارید، احتمالا ابزار بازبینی‌اش را دیده‌اید (که خوب نیست). به‌تازگی ابزاری پیدا کرده‌ام که بعضی از مفاهیم اصلی کریتیک را روی گیت‌هاب پیاده‌سازی کرده (یکی از نویسندگان اصلیش هم قبلا در گوگل بوده). اسم ابزار Reviewable است: //
reviewable.io

۱۲) به دو ویژگی شبیه کریتیک بسنده کنیم: یکی از مشکلات اصلی بازبینی کد گیت‌هاب، تغییر یک فایل در طول کامیت‌های مختلف است (مثلا بعد از پاسخ به هر دور بازبینی). با این ابزار خیلی راحت می‌توان نسخه‌های مختلف را مقایسه کرد (مثلا r1 و r2 در تصویر زیر، وقتی r3 نسخه‌ی آخر است). //

۱۳) نکته‌ی دیگر برجسته کردن نظرات (comments) و سادگی پیدا کردن آن‌هاست (مثل عدد ۱۵ در بالای تصویر قبل). هرکس که بازبینی مفصلی روی گیت‌هاب کرده باشد می‌داند که پیدا کردن رشته نظرات قبلی بعضی وقت‌ها چه مصیبتی‌ست. //

۱۴) توضیح: اگر بخواهید از این ابزار برای انتشار نظرات استفاده کنید، باید امکان نوشتن کد (public_repo) را به آن بدهید که توصیه نمی‌شود. من از این ابزار فقط برای دیدن تغییر فایل‌ها و پیدا کردن نظرات قبلی استفاده می‌کنم (که دسترسی کم‌تری می‌خواهد). //
docs.github.com/en/developers/…

۱۵) شما هم اگر ابزارهای خوب بازبینی کد برای گیت‌هاب می‌شناسید، لطفا در نظرات بنویسید و به من و دیگران گیت‌هابگران کمک کنید 😀

درضمن، بعضی‌ها برنامه‌نویسی جفتی (pair programming) را به‌عنوان جایگزین بازبینی استفاده می‌کنند. به‌نظرم ایده‌ی خوبی نیست ولی توضیحش باشد برای وقتی دیگر.