در این مقاله ، به طور خلاصه 13 استاندارد بررسی کد را بررسی خواهیم کرد که به طور چشمگیری به بهبود سلامت نرم افزار شما کمک می‌کند و توسعه دهندگان را خوشحال نگه می‌دارد.
مرور کد یا code review اصلا چیه؟
فرآیندی که در اون یک یا چند تا برنامه‌نویس، کد نوشته شده توسط برنامه‌نویس‌های دیگر رو review می‌کنند و حالا چرا ؟ به دلایل زیر:
این‌ها دلایلی بود برای اینکه چرا کد ریویو یکی از بخش‌های مهم توسعه نرم‌افزار است.
کد ریویو مثل دروازه‌بانی عمل می‌کنه که تصمیم می‌گیره، این بخش از کد به کد اصلی اضافه بشه و به محصول نهایی برسد یا خیر.
شرکت گوگل به برتری تکنولوژی خود مشهور است. برنامه‌نویسان گوگل استانداردهایی را تعریف کردند که نکات خوبی را در مورد کد ریویو بیان می کنه و بهتر است آن‌ها را هنگام کد ریویو بخاطر بسپارید:
هدف اولیه بررسی کد این است که مطمئن شویم سلامت کد پایه‌ی گوگل در طول زمان بهبود پیدا کرده است.
در ادامه با هم ۱۳ استاندارد کد ریویو رو می‌خونیم.
وقتی یک پول ریکوئست را می‌گیریم باید بررسی شود که سلامت کلی سیستم بهبود پیدا کرده است. ایده اصلی اینست که در نتیجه بهبودهای کوچک، سلامتی کد اصلی بعد از هر مرج بهبود پیدا کند.
در کد ریویو، مرج کردن کد رو به تأخیر نیاندازید. هنگام مرور کد، انتظار کد کامل یا پرفکت رو نداشته باشیم. اگر کد دریافتی سلامت کلی سیستم رو بهبود می‌بخشه آن را ادغام کنید.
"نکته کلیدی ای که در اینجا وجود داره اینه که چیزی به نام پرفکت کد وجود ندارد و همیشه کد بهتر در میان است"
اگر وسط یک تسک نیازمند به تمرکز نیستید، کد ریویو رو کمی پس از دریافت آن، انجام دهید. با این حال، یک روز کاری حداکثر زمانیه که می‌تونید به یک پول ریکوئست پاسخ دهید. پیش بینی میشه یک پول ریکوئست در طول یک روز چند دور کد ریویوی جزئی یا کلی شود.
در هنگام مرور کد سعی کنید مانند یک منتور با اشتراک‌گذاری دانش و تجربه در هرکجا که امکان دارد راهنمایی کنید.
همیشه بخاطر داشته باشید که راهنمای استایل، استانداردهای کدنویسی و چنین مستنداتی در مرور کد اقتدار مطلق را دارند. برای مثال، اگر بین استفاده از تب و اسپیس مانده بودید به استانداردهای کدنویسی رجوع کنید.
اگر از زبان جاوا استفاده می‌کنید، لینک زیر خلاصه‌ای از بهترین روش‌های برنامه‌نویسی جاوا در کمپانی‌های غول تکنولوژی است(اگر در ایران هستید برای مشاهده این مقاله احتمالا نیاز به تغییر آدرس IP دارید).
A short summary of Java coding best practices
وقتی کدِ یک برنامه نویس دیگه رو بررسی می‌کنید و سپس کامنتی در مورد کد به او ارائه می‌دید با توجه به کامنتی که دادید ممکنه واکنش‌های مختلفی دریافت کنید. طرف مقابل ممکن خیلی خوشحال و سپاسگزار شود یا ناراحت و تدافعی. شما باید این تعارضات رو بر اساس روش‌های توافق شده در استایل‌ها و استانداردهای کدنویسی حل کنید. همچنین راهنمایی و پیشنهادات برنامه نویسان دیگری که تجربه و دانش بیشتری بر روی محصول دارند دنبال کنید.
نموداری را می‌بینید که توسط خانم Alex Hill در مقاله‌ی هنرِ دریافت و ارسال بررسی کد، ترسیم شده است.
این نمودار دو تا محور داره: ارزشمند بودن کامنت و میزان تعارضات بر اساس کامنت‌هایی که فرد بررسی کننده کد ارائه می‌دهد. هنگامی که برنامه‌نویس کدی رو می نویسه و ریویو کننده، فیدبک و کامنتی به نویسنده کد می‌دهد، چون نویسنده به کدش حس مالکیت داره با توجه به میزان این حس مالکیت و نوع نظراتی که دریافت می‌کنه، ممکنه مقداری درگیری به وجود بیاد.
در قسمت بالا سمت چپ کامنت‌هایی رو می بینید که کم ارزش هستند و همچنین درگیری بالایی رو هم پیش میارن مثل کامنت در مورد تنظیمات دلخواه، استفاده از فضاهای خالی در کد و غیره که ارزش ندارند در کد ریویو بررسی شوند و می‌تونیم خیلی راحت یک استاندارد مشخص کنیم و به آن بچسبیم تا همه همان را رعایت کنند یا اینکه کلی ابزارهای اتوماتیک برای این کار وجود دارد و دیگر لازم نیست که یک انسان خودش رو درگیر این موارد کند. همانطور که گفته شد این موارد چون با حس مالکیت رابطه مستقیم دارند،باعث درگیری بالا میشن و به دلایلی که گفته شد کامنت‌های کم ارزشی هستند.
در بخش پایین نمودار شما نقص‌ها رو می‌بینید. نقص‌هایی مثل اشکال در رفتار تابع، باگ‌ها و یا تست‌های نوشته نشده. این موارد هیچ ارتباطی با مالکیت کد ندارند چرا که فرد هرگز از عمد این مشکلات را به وجود نمیاره. پس این نوع از کامنت‌ها حس تدافعی در نویسنده ایجاد نمی‌کنند.
در بخش بالایی نمودار مواردی ان که نسبتاً غیر قابل ارزیابی هستند اما شامل نظرات ارزشمندی مانند نظر در مورد خوانایی کد، استفاده از الگوهای طراحی، انتخاب نام‌های مناسب در این بخش قرار دارد. این نوع از نظرات نمی‌توانند توسط یک ابزار خودکار سازی ارائه شوند و حتما باید توسط یک انسان انجام شود، بازدهی بالایی دارند و همچنین نظر مستقیمی روی انتخاب‌های مالک کد می‌دهند. در واقع این نظرات خیلی ارزشمندند با اینکه ممکنه درگیری ای بین مالک کد و ریویو کننده ایجاد کنند. اگر ما سعی کنیم کامنت‌هایی که در دسته‌بندی‌های کم ارزش هستند رو ارائه ندیم و کامنتهامون از این دسته‌ی با ارزش باشه آنگاه می‌تونیم مشکلات کامنت‌های این دسته بندی رو مدیریت کنیم تا بتونیم همکاری رو بالا ببریم و مرور کد ارزشمندی داشته باشیم.
اگر کامنتی در کد ریویو می‌دین که خیلی جزئی یا اختیاری ست به روشنی بیان کنید و اجازه بدید که نویسنده‌‌ی کد تصمیم بگیره که به اون توجه کنه یا خیر.
به عنوان یک بررسی کننده، اگر که استانداردی برای استایل ها و کد نویسی ندارید، می‌تونید حداقل پیشنهاداتی ارائه کنید تا پایداری کد اصلی حفظ بشه.
اگر تغییرات پول ریکوست، شامل تغییرات ظاهری هم میشه پس سعی کنید علاوه بر کد ریویو حتماً دموی تغییرات ظاهری رو هم ببینید تا بررسی کنید آیا چیزی که مشاهده میشه همون چیزیه که انتظار میره یا خیر؟
باید حتما بررسی کنید که کد همراه با همه تست‌ها مثل یونیت تست، integration تست و غیره باشه مگر اینکه در شرایط خیلی خاص و اضطراری باشید.
شرایط خاص هم یعنی یک باگ یا رخنه امنیتی وجود داشته باشه که بخواد به سرعت حل بشه و تست می‌تونه بعداً اضافه بشه. در چنین موارد مطمئن شوید که تسکی براش ایجاد شده و یک نفر مسئولیت آن رو به عهده بگیره که بعد از اینکه شرایط بحرانی رد شد، تست‌ها رو اضافه کنه.
هیچ دلیل خوبی برای تست ننوشتن وجود ندارد! اگر محدودیت زمانی دارید و ممکن است برخی از اهداف به دمو یا ریلیز نرسند، راه حل آن فرار از تست‌نویسی نیست بلکه موارد قابل تحویل را کاهش دهید.
وقتی وسط یک تسک متمرکز هستید، وقفه ایجاد نکنین به این خاطر که زمان زیادی طول میکشه که به جایگاهی که بودید برگردید. هزینه وقفه انداختن در کار برنامه نویسی که فوکوس کرده خیلی بیشتر از منتظر ماندن یک برنامه‌نویس دیگه به خاطر کد ریویو است. کد ریویو رو بعد از یک استراحت کوتاه برنامه‌ریزی شده مثل ناهار یا قهوه و چیزهایی از این دست انجام بدید.
انتظار نمیره که کل فرایند بررسی کد و مرج کردن در یک روز اتفاق بیفتد. چیزی که مهمه اینه که به نویسنده کد خیلی سریع فیدبکی بدید. مثلاً ممکنه شما فرصت نکنید که کل کد ریویو رو انجام بدید اما می‌تونید با یک بررسی سریع به چند مورد اشاره کنید.
تمام خطوطی رو که برای کد ریویو به شما سپرده شده، بررسی کنید و هیچ فرضی در مورد کلاس‌ها و متدهای نوشته شده توسط یک انسان انجام ندهید و مطمئن بشید که دقیقا انچه کد انجام می‌دهد را فهمیده‌اید.
مطمئن شوید کدی که درحال بررسی آن هستید را می‌فهمید در غیر این صورت از نویسنده کد توضیح بخواهید.
اگر صلاحیت بررسی بخشی از کد را ندارید مطمئن شوید که برنامه‌نویسی که صلاحیت آن را دارد حتماً آن بخش را بررسی کند.
اغلب بررسی تغییرات با یک وسعت دید بیشتر خیلی کمک کننده است. مثلاً فرض کنید که یک فایل تغییر کرده و چهار (4) خط کد به آن اضافه شده. فقط آن چهار (4) خط کد را ریویو نکنید بلکه بررسی کل فایل را در نظر بگیرید و چک کنید چه چیزهایی به آن اضافه شده. آیا کیفیت کد موجود را کاهش داده یا باعث شده که توابع موجود نیاز به ریفکتور پیدا کند؟
اگر چنین تغییرات ساده‌ای در چارچوب کلاس یا متد بررسی نشود در طول زمان شاهد کلاسی خواهیم بود که غیر قابل نگهداری، پیچیده و غیرقابل تست است. کلاسی که همه کار انجام می دهد و گسترش و تغییر آن مشکل است. کلاسی که اصل تک مسئولیتی را نقض می‌کند.(مطمئنم همتون تجربه کار با چنین کلاسی رو داشتید)
به یاد داشته باشیم همانطور که پیشرفت‌های اندک در طول زمان جمع می‌شوند و منجر به تولید یک محصول عالی با کمترین نقص می‌شوند، به همین ترتیب هم، تخریب جزئی کد و بدهی‌های فنی با گذشت زمان منجر به محصولی می‌شوند که نگهداری و تغییر آن چالش برانگیز است.
اگر در حین کد ریویو مورد خوبی رو دیدید نویسنده کد را با اشتیاق صدا کنید و او را تشویق کنید. هدف کد ریویو فقط پیدا کردن اشتباهات نیست بلکه تشویق و راهنمایی توسعه‌دهندگان برای کار فوق‌العاده‌ای که انجام می دهند نیز هست.
بسیار حیاتی است که در هنگام بازبینی کد صریح، مودب و محترم باشید و در عین حال در رفتار با نویسنده روشنگر و رهنما باشید. هنگام مرور کد حتما نظرتان را درباره‌ی کد و نه توسعه‌دهنده بیان کنید.(لطفا شخصیت برنامه نویس را تخریب نکنید و صدای خود را بالا نبرید!)
در لینک زیر راهنمای گوگل در مورد چگونگی احترام گذاشتن در زمان مرور کد وجود دارد:
هرگاه نظری که در کد ریویو ارائه می‌دهید، روش دیگری را بیان می‌کند مهم است که دلیل خود را توضیح دهید و بر اساس دانش و تجربه خود مثالی بزنید تا توسعه‌دهنده درک کند، چگونه پیشنهاد شما به کیفیت کد او کمک خواهد کرد.
هنگام پیشنهاد اصلاح یا تغییر به نویسنده کد، تعادل درستی را پیدا کنید تا نویسنده را در اصلاح کدش راهنمایی کنید. به عنوان مثال من از روش راهنمایی، توضیح و ارائه برخی نکات و پیشنهادات استفاده می‌کنم و هرگز راه حل کامل را ارائه نمی دهم.
برای عمیق‌تر شدن در مبحث استانداردهای کد ریویو گوگل، لینک زیر را مطالعه کنید و همچنین من بیشتر برایتان خواهم نوشت.
هزینه ایجاد وقفه در کار برنامه نویسی که تمرکز کرده در مقایسه با اینکه یک توسعه دهنده منتظر بماند تا شما کد خود را در بازه زمانی مناسب مرور کنید ، بسیار زیاد است. برای اطلاعات بیشتر در این باره ، به لینک زیر مراجعه کنید:
هزینه ایجاد وقفه برای توسعه دهندگان
مقاله بسیار مفید خانم Alex Hill با نام هنر ارسال و دریافت کد ریویو را در اینجا بخوانید.
به عنوان برنامه‌نویسی که مدتی است در حال کد ریویو کد همکاران خود است و خودش هم همیشه تجربه ریویو شدن کدهایش را دارد توصیه می‌کنم حتما بررسی کد را امری جدی تلقی کنید. با بررسی کد به همکارانتان کمک می‌کنید از دانش و تجربه‌ی شما بهره‌مند شوند، کد خود را از نگاه شخص دیگری ببینند، ایده بگیرند و بسیار زیاد جلوی اشتباهات سهوی را خواهید گرفت.
لطفا نظرات و پیشنهاد خود را در مورد این مطلب با من در میان بگذارید.
