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

به تازگی یکی از دوستان سحابی‌، مقاله‌ای که مورد Code Review، در InfoQ منتشر کرد که باعث شد منی که چند ساله از برنامه‌نویسی فاصله گرفتم، پی به عمق این مبحث ببرم.

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

گویا کد ریویو در سحاب خیلی جدیه. تو کد رویو چه جنبه‌هایی رو بررسی می‌کنین؟

ما تو اکثر تیم‌هامون، رویه‌ی کد رویو داریم که انرژی و توان زیادی بهش اختصاص میدیم. این ریویو به جنبه‌های ذیل می پردازه:

• تطابق با نیازمندی‌ها
• مطابقت با کد استایل
• انطباق با طراحی و فرضیات قبلی
• هماهنگی با معماری محصول
• ساده و خوانا بودن
• نامگذاری های مناسب
• جداسازی و روشن بودن مسئولیت هر کلاس
• نبود کدهای ریداندنت
• استفاده از تکنولوژی‌ها و طراحی‌های آشنا و استفاده شده توسط تیم تا حد امکان
• یونیت تست‌هایی که باید همراه هر کدی باشه و ریسک‌هاش رو پوشش بده
• اسکریپت‌های مربوط به دیپلوی و حتی migration در صورت نیاز
• ستفاده صحیح از الگوها و پرهیز از over design و انعطاف‌ها از اون جنس هایی که هزینش نقده اما استفاده‌ش با اما و اگر و نسیه‌س
• مسائل مربوط به پرفورمنس در بخش های کریتیکال و مسیرهاس باتلنک
• مسائل امنیتی
• نیازهای مربوط به ha و scalable بودن

بنابراین، این فهرست خیلی متنوعه. هر چیزی که یک دولوپر حرفه ای تو طراحی و کد زدن باید در نظر بگیره؛ ریویوئر هم در مرحله ریویو در نظر می گیره.

واقعا ارزش داره که همچین کد ریویویی داشته باشید؟ به هزینه‌اش می‌ارزه؟

باید ببینیم چه فوایدی داره. یکی از فواید مهمش نشر دانشه. هم دانش در مورد پروژه و تاریخچه‌ش و هم دانش طراحی و برنامه‌نویسی و انواع مسائل فنی. ضمناً این کار سرعت on-boarding افراد تازه وارد به تیم رو هم زیاد می کنه. یه نفر جدید با توضیحات کوتاهی در مورد change list خودش وارد کار میشه. دلیلش هم اینه که ریویوئر کمکش می‌کنه و سوالاتش رو جواب می‌ده و نتیجه‌ی کار فرد تازه وارد رو به دقت بازبینی می‌کنه. بعلاوه اینکه کیفیت کار خروجی، واقعاً افزایش پیدا می‌کنه و technical debt کمتری داریم. در جریان بحث‌هایی که شکل می‌گیره، گاهی به راه حل‌های سومی می‌رسیم که از ابتدا نه تو ذهن دولوپر بوده نه ریویوئر. این در واقع نتیجه سنتز ایده‌هاست و شاید دلیل اصلی این اتفاقات، فرهنگ حاکمیه که در اون، رویوئر باید برای کامنت هاش استدلال داشته باشه. اینطور نیست که بگیم چون یکی سینیوره، کامنت‌هاش استدلال نمی خواد. حتی جونیورها تشویق می‌شن که اگه دلیل کامنتی رو نمی‌دونن علتش رو بپرسن. به این ترتیب هر دو طرف رشد بیشتری می‌کنن. شما به عنوان یک سینیور، وقتی مجبور شی فقط به شهودت اکتفا نکنی و دلیل بیاری؛ مجبور می‌شی بیشتر مطالعه و فکر کنی و دقیق‌تر شی. از اون طرف هم وقتی یه تازه کار روحیه کنجکاو و پرسشگر خودش رو حفظ می‌کنه با سرعت بیشتری پیشرفت می کنه.

آیا همه‌ی دولوپرها از چنین دسیپلینی استقبال می‌کنن و می‌تونن باهاش کنار بیان؟

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