چگونه بهتر code review کنیم

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

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

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

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

۱) به‌جای دستور دادن، پیشنهاد دهید

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

از mapping object استفاده کنید، فانکشن موجود را به فانکشن‌های کوچک‌تر تبدیل کنید، نام متغیر را تغییر دهید. این جملات، رویکرد فردی است که اعتقاد دارد همه باید به اقتدار او احترام بگذارند، همچنین این جملات در بازبینی کدهای افراد کم تجربه‌تر، شدت بیشتری پیدا می‌کند.

آیا به نحوه دریافت و خواندن نظری که در بخشی از کد نوشته‌اید، فکر کرده‌اید؟ به‌هر‌حال کسی که pull request را ایجاد کرده با توجه به نظر شما، کدها را تغییر می‌دهد اما ممکن است شما باعث تضعیف روحیه آن فرد شوید.

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

عبارت‌های مفیدی که می‌توانید از آنها استفاده کنید:

1. من فکر می‌کنم که بهتر است در این بخش از mapper استفاده شود.
2. این فانکشن طولانی شده است، شاید ارزش آن را داشته باشد که به فانکشن‌های کوچک‌تر تبدیل شود.
3. نظر شما درمورد پیشنهاد من برای تغییر نام این متغیر چیست؟

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

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

۲) استدلال‌های خود را بنویسید

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

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

عبارت‌های مفیدی که می‌توانید از آنها استفاده کنید:

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

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

مهم‌تر از همه، با توضیح چیستی‌ها و چرایی‌های موجود، توسعه‌دهندگان در pull requestهای بعد می‌دانند که باید چگونه کدهایشان را بازبینی کرده و اشکال‌ها را رفع کنند. این باعث می‌شود که آنها مجددا همان اشتباه را تکرار نکنند زیرا عواقب آن اشتباه را کاملا درک کرده‌اند و قطعا همه اینها به نفع کل تیم است.

۳) نظرهای مفید و مثبت بنویسید

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

عبارت‌های مفیدی که می‌توانید از آنها استفاده کنید:

1. “عالی بود”، این یک روش خوب و کوتاه برای شرایط‌های این شکلی است.
2. بسیار خوب است که شما کدها را به کامپوننت‌های مجزا تبدیل کرده‌اید زیرا هنگام کار بر روی ویژگی‌های جدید مفید خواهند بود.
3. ترفند خوبی است، من نمی‌دانستم که این امکان وجود دارد.

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

این توصیه فقط برای برنامه‌نویسان باتجربه‌ای نیست که کد همکاران خود را بازبینی می‌کنند و می‌خواهند انگیزه‌ دیگر توسعه‌دهندگان را بالا ببرند. هنگامی که pull request فردی باتجربه‌تر را بازبینی می‌کنید، می‌توانید نظر مثبتی بنویسید تا او مطلع شود که کدهایش تاثیر مثبت و مفیدی بر شما داشته است.

۴) نسبت به اشتباه‌های موجود در کد، کینه توز نباشید

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

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

عبارت‌هایی که نباید در بازبینی کدها استفاده کنید:

1. دوباره یک اشتباه تکراری را مرتکب شده‌اید ?.
2. آیا شما این کدها را تست کرده‌اید؟ فکر کنم کار نمی‌کند.
3. آیا می‌توانید کمی بیشتر تلاش کنید تا نام‌های بهتری برای متدها قرار دهید؟

اگر کسی مرتبا یک اشتباه را در کد یا بازبینی کد مرتکب شود، چه می‌شود؟ بهترین روش بازبینی کد آن است که بتوانید با آن مشکل‌های موجود در کد را پیدا کنید اما قطعا pull requestها جایی برای حل مشکل‌هایی مثل نداشتن سابقه کار، تازه وارد بودن در یک پروژه، عدم ارتباط در تیم و … نیستند.

خیلی بهتر است که به آن شخص نزدیک شده و رودررو صحبت کنید، در آخر می‌توانید موارد را به مدیر پروژه اطلاع دهید. سعی کنید بدون احساسات منفی نظرهای حرفه‌ای خود را نسبت به کدهای پروژه بنویسید. این درمورد خراب کردن روز کسی نیست. به یاد داشته باشید که بازبینی کدها مربوط به خود کد است، نه یک انسان که آنها را نوشته است.

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

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

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

۵) از اظهار نظر نترسید

یکی از بدترین حالت‌ها در هنگام بازبینی کد زمانی است که pull requestها بدون هیچ‌گونه نظری تایید می‌شوند، اما به‌هرحال اشکالی در کد شما پیدا می‌شود. ممکن است فکر کنید در بازبینی کد کوتاهی شده و تمام pull requestها را یک باره تایید کرده‌اند.

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

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

درپایان واقعا مهم نیست که چه اتفاقی افتاده است زیرا همه‌ی دلایل ذکر شده نادرست بوده و به‌طور بالقوه‌ای برای کل پروژه در طولانی مدت، مضر است. بازبینی کد، کار یک نفر نیست بلکه تلاش جمعی و همکاری نویسنده کد با فردی که برای بازبینی کد مسئول شده را طلب می‌کند تا به بالاترین کیفیت کد برسید.

مهم است که ارتباط برقرار کنید و توضیح دهید که چرا بعضی چیزها باید به این روش انجام شوند. شاید در خوب یا بد بودن آن دچار شک شده باشید، به همین منظور می‌توانید نظر نویسنده کد را بپرسید.

عبارت‌های مفیدی که می‌توانید در بازبینی کدها استفاده کنید:

1. درک این قسمت از کد برای من مشکل است. می‌توانید عملکرد آن را برای من توضیح دهید؟
2. آیا دلیلی برای نوشتن این منطق از ابتدا وجود دارد؟ شاید یک کتابخانه آماده و مطمئن وجود داشته باشد که این منطق را پیاده‌سازی کرده باشد.
3. آیا مطمئن هستید که مشتری ما چنین عملکردی را درخواست کرده؟ تا آنجا که به یاد دارم، آنها درمورد چیز دیگری صحبت می‌کردند.

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

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

بازبینی کد برای داشتن کدهای با کیفیت‌تر

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

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

منبع: https://tsh.io/blog/code-review-best-practices