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

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

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

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

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

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

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

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

@JavaCupIR

دسته چهارم از انواع بازبینی کد ملایم:
بازبینی دوره‌ای (هر چند وقت یکبار)

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

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

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

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

@JavaCupIR

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

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

با ما همراه باشید💪

@JavaCupIR

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

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

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

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

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

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

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

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

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

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

I DEMAND TRIAL BY COMBAT!🙈

@JavaCupIR

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

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

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

در نهایت، ۲۰ ابزاری که بیش از سایرین در توییت‌ها نام برده شدند، در لیست 《۲۰ ابزار برتر توسعه برای سال ۲۰۱۹》 قرار گرفتند.

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

#Top20DevToolsFor2019

@JavaCupIR

#Linux
برای اولین بار به این لیست راه یافته

@JavaCupIR