آشنایی با روش‌های مختلف بازبینی کد

از آن جایی که کد هیچ کس بی‌نقص نیست، لازم است با روش‌های مختلف بازبینی کد (#code_review) آشنایی داشته باشید و با استفاده از آن‌ها، کدهای خود و هم‌تیمی‌هایتان را در معرض بازبینی قرار دهید.

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

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

هدف ما این است که در انتها، قدرت تشخیص اینکه در چه زمانی، از چه روشی باید استفاده کنید را به دست آورید.

در بالاترین در سطح، انواع بازبینی کد را می‌توان به دو دسته  1-بازبینی صوری (Formal) و 2-بازبینی ملایم (Lightweight) دسته‌بندی کرد.

بازبینی صوری

بازبینی‌های صوری (Formal Code Review)، بر مبنای یک فرآیند صوری هستند. در حال حاضر، Fegan inspection محبوب‌ترین پیاده‌سازی از چنین فرآیندهایی است.

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

همچنین برای پیدا کردن نواقص specificationها و طراحی‌ها هم مورد استفاده قرار می‌گیرد. فرآیند Fegan inspection شامل شش مرحله است: برنامه‌ریزی، مرور اجمالی، آماده‌سازی، جلسه بازرسی، بازنگری و پیگیری.

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

چنین رویکرد ساختارمندی، چندان مورد استفاده قرار نمی‌گیرد و احتمالا به دلیل سربار زیادی که دارد، تیم‌های زیادی از آن استفاده نمی‌کنند.

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

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

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

در ادامه، به معرفی انواع روش‌های بازبینی ملایم می‌پردازیم.

بازبینی ملایم

بازبینی ملایم، این روزها در بین تیم‌های توسعه معمول‌تر است.

می‌توان بازبینی ملایم را مانند آنچه در ادامه آمده است، به چهار زیردسته مختلف تقسیم‌بندی کرد:

• بازبینی فوری، به عنوان برنامه‌نویسی دو نفره هم شناخته می‌شود.
• بازبینی هم‌زمان، به عنوان بازبینی کد over-the-shoulder نیز شناخته می‌شود.
• بازبینی غیرهم‌زمان، به عنوان بازبینی کد tool-assisted نیز شناخته می‌شود.
• بازبینی هر چند وقت یکبار، به عنوان بازبینی مبتنی بر ملاقات نیز شناخته می‌شود.

 1: بازبینی فوری

هنگامی که به صورت دونفره در حال برنامه‌نویسی هستید، در واقع دارید از این روش، یعنی بازبینی فوری استفاده می‎کنید. در حالی که یکی از توسعه‌دهندگان دارد دکمه‎های کیبورد را فشار می‌دهد و کد تولید می‌کند، توسعه‌دهنده دیگر، در حال بازبینی کد است. در واقع به صورت هم‌زمان به مشکلات بالقوه توجه می‌کند و ایده‌هایی برای بهبود کد می‌دهد.
در زمان انتخاب این روش، باید به دو نکته توجه کنید: 1- نوع مساله‎ای قرار است رویش کار کنید 2- سطح تخصص دو برنامه‎نویسی که قرار است با هم کار کنند.

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

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

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

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

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

2: بازبینی هم‌زمان

روش دوم، بازبینی هم‌زمان است. در این روش، برنامه‌نویس، خودش کد می‌زند و از بازبینی‌کننده می‌خواهد که کدش را بازبینی کند. بنابراین، بازبینی‌کننده به پشت میز برنامه‌نویس می‌آید هر دو به یک مانیتور نگاه می‌کنند و به بازبینی و بهبود کد می‌پردازند.

ضعف اطلاعات بازبینی‌کننده

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

حجم بالایی از بهبود کد انتظار می‌رود.

اگر با توجه به بی‌تجربگی برنامه‌نویس، انتظار حجم بالایی بهبود کد دارید، بازبینی هم‌زمان می‌تواند مناسب باشد. اگر یک ارشدِ باتجربه، کدِ یک برنامه‌نویس تازه‌کار را بازبینی کند، با اینکه بازبینی را با همدیگر انجام می‌دهند، سرعت بازبینی بالا می‌رود. بازبینی کد تا زمان تایید ارشد ادامه می‌یابد.

تغییر اجباری زمینه کاری

بازبینی هم‌زمان، یک ایراد بزرگ دارد و آن هم تغییر اجباری زمینه کاری (context switching) است. این اتفاق نه تنها کار اصلی بازبینی‌کننده را بسیار مختل می‌کند، بلکه سرعت کل تیم را نیز کاهش می‌دهد.

3: بازبینی غیرهم‌زمان

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

همانطور که مشاهده می‌کنید، بازبینی هم‌زمان و غیرهم‌زمان، کاملا با یکدیگر متفاوتند.

بدون وابستگی مستقیم

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

مشکل تعداد زیاد چرخه‌های بازبینی

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

اما گزینه‌هایی برای جلوگیری از طولانی شدن این زمان وجود دارد. برای مثال، در تیم ما، می‌توان قانون گذاشت که هر توسعه‌دهنده‌ای، صبح و بعد از ناهار، قبل از آن‌که به سراغ هر taskای برود، کارش را با بازبینی‌های در حال انتظار شروع کند.

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

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

4: بازبینی دوره‌ای (هر چند وقت یکبار)

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

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

به این ترتیب، برای یک بازه طولانی، استفاده از روش چهارم چندان مناسب نیست، زیرا کار کردن کل تیم بر روی یک تکه‌کد، خیلی کارآمد نیست.

از کدام روش بازبینی باید استفاده کنم؟

خب، حالا احتمالا دوست دارید بدانید که کدام روش بازبینی را باید انتخاب کنید.

در مورد روش رسمی صحبت کردیم؛ که واضح است خیلی روش محبوبی نیست و در عمل خیلی کم از آن استفاده می‌شود…

سپس در مورد دسته بازبینی ملایم  صحبت کردیم و 4 روش مختلف از این دسته را معرفی کردیم.

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

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

اما اشکالش این است که باعث تغییر context اجباری می‌شود که برای بازبینی‌کننده اذیت‌کننده است و سرعت کل تیم را کم می‌کند.

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

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

استفاده از روش بازبینی غیرهم‌زمان، به صورت پیش‌فرض

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

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

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

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

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

منبع

.

.

.