بازبینی ملایم
بازبینی ملایم (Lightweight Code Review)، این روزها در بین تیم‌های توسعه معمول‌تر است.
می‌توان بازبینی ملایم را مانند آنچه در ادامه آمده است، به چهار زیردسته مختلف تقسیم‌بندی کرد:
🔸 بازبینی فوری: به عنوان برنامه‌نویسی دو نفره هم شناخته می‌شود.
🔸 بازبینی هم‌زمان: به عنوان بازبینی کد over-the-shoulder نیز شناخته می‌شود.
🔸 بازبینی غیرهم‌زمان: به عنوان بازبینی کد tool-assisted نیز شناخته می‌شود.
🔸 بازبینی هر چند وقت یکبار: به عنوان بازبینی مبتنی بر ملاقات نیز شناخته می‌شود.
@JavaCupIR
بازبینی ملایم (Lightweight Code Review)، این روزها در بین تیم‌های توسعه معمول‌تر است.
می‌توان بازبینی ملایم را مانند آنچه در ادامه آمده است، به چهار زیردسته مختلف تقسیم‌بندی کرد:
🔸 بازبینی فوری: به عنوان برنامه‌نویسی دو نفره هم شناخته می‌شود.
🔸 بازبینی هم‌زمان: به عنوان بازبینی کد over-the-shoulder نیز شناخته می‌شود.
🔸 بازبینی غیرهم‌زمان: به عنوان بازبینی کد tool-assisted نیز شناخته می‌شود.
🔸 بازبینی هر چند وقت یکبار: به عنوان بازبینی مبتنی بر ملاقات نیز شناخته می‌شود.
@JavaCupIR
دسته اول از انواع بازبینی کد ملایم: بازبینی فوری
هنگامی که به صورت دونفره در حال برنامه‌نویسی هستید، در واقع دارید از این روش، یعنی بازبینی فوری استفاده می‌کنید. در حالی که یکی از توسعه‌دهندگان دارد دکمههای کیبورد را فشار می‌دهد و کد تولید می‌کند، توسعه‌دهنده دیگر، در حال بازبینی کد است. در واقع به صورت هم‌زمان به مشکلات بالقوه توجه می‌کند و ایده‌هایی برای بهبود کد می‌دهد.
در زمان انتخاب این روش، باید به دو نکته توجه کنید: 1- نوع مساله‌ای قرار است رویش کار کنید 2- سطح تخصص دو برنامه‌نویسی که قرار است با هم کار کنند.
این نوع بازبینی کد، برای زمانی که قصد دارید یک مساله پیچیده را حل کنید، مناسب است. زیرا زمانی که دو ذهن به صورت هم‌زمان در فرآیند یافتن راه‌حل برای یک مساله درگیر می‌شوند، احتمال پیدا کردن راه‌حل درست و مناسب، بیشتر می‌شود. همچنین، در این حالت، با بحث کردن بر روی سناریوهای ممکن مختلف، با احتمال بیشتری نقاط مرزی مساله را پوشش خواهید داد.
زمانی که با مساله‌ای مواجه هستید که منطقهای کاری پیچیده‌ای دارد، برنامه‌نویسی به صورت دونفره گزینه مناسبی است؛ زیرا کمک‌کننده خواهد بود اگر دو نفر بر روی تمام احتمالات و حالات ممکن فکر کنند و اطمینان حاصل کنند که همگی آن حالات به درستی در کد پیاده‌سازی شدهاند.
برخلاف مسائلی با منطقهای کاری پیچیده، ممکن است انجام کاری، نیاز به حل‌کردنِ مساله فنی پیچیده‌ای داشته باشد. به طور مثال، مجبور باشید از یک چارچوب جدید استفاده کنید و یا قسمتی از یک تکنولوژی‌ای که قبلا هیچ وقت با آن کار نکرده بودید را بفهمید. در این شرایط بهتر است خودتان به تنهایی بر روی مساله کار کنید. زیرا مطابق با سطح خودتان می‌توانید پیش بروید. لازم است مقدار زیادی در وب جست‌وجو کنید و مستندات زیادی بخوانید تا بفهمید این تکنولوژی جدید چطور کار می‌کند.
برنامه‌نویسی دونفره در این شرایط کمک‌کننده نیست. زیرا در حین یادگیری فردی، باعث کندی یکدیگر می‌شوید.
اگرچه، اگر جایی گیر کردید، مشورت و هم‌فکری با یک همکار، می‌تواند راه‌گشا باشد.
جنبه بااهمیت دیگری که در برنامه‌نویسی دونفره باید در نظر گرفته شود، هم‌سطح‌بودن دو برنامه‌نویس از نظر فنی و تخصصی است. تخصص دو برنامه‌نویسی که با هم به‌صورت دونفره کار می‌کنند، باید در یک سطح باشد؛ زیرا هر دو با سرعت یکسانی می‌توانند کار کنند.
روش برنامه‌نویسی دونفره با یک ارشد و یک تازه‌کار، خوب جواب نمیدهد. زیرا گر فرمان دست تازه‌کار باشد، احتمالا ارشد خسته شده و حوصله‌اش سر می‌رود. در این شرایط، پتانسیل ارشد هدر رفته و وقتش تلف می‌شود.
و اگر کیبورد زیر دست ارشد باشد، سرعت کار برای تازه‌کار زیاد است. ممکن است ارشد قادر نباشد سطح و پایه تازه‌کار را در نظر بگیرد و پس از چند دقیقه، تازه‌کار دیگر نتواند کار را دنبال کند. تنها در صورتی که ارشد سرعت خود را کم کند و با صبر و حوصله به تازه‌کار توضیح دهد که چرا این کار را انجام داده است، این روش جواب خواهد داد. البته در این صورت، دیگر خبری از برنامه‌نویسی دونفره نیست، درواقع یک جلسه تدریس است که ارشد به یک تازه‌کار یاد می‌دهد، مساله خاصی را چطور حل کند.
اما اگر هر دو برنامه‌نویس در یک سطح باشند، نتیجه شگفت‌انگیز خواهد بود. بزرگترین مزیت‌ش این است که دو برنامه‌نویس یکدیگر را هل می‌دهند و اگر یکی از آن‌ها تمرکز خود را از دست بدهد، دیگری وی را مجددا به مسیر برمی‌گرداند.
برای جمع‌بندی: زمانی که دو برنامه‌نویس با سطح مشابه از نظر فنی و تخصص با هم بر روی یک مساله کاری پیچیده کار کنند، برنامه‌نویسی دونفره بسیار مفید خواهد بود.
@JavaCupIR
هنگامی که به صورت دونفره در حال برنامه‌نویسی هستید، در واقع دارید از این روش، یعنی بازبینی فوری استفاده می‌کنید. در حالی که یکی از توسعه‌دهندگان دارد دکمههای کیبورد را فشار می‌دهد و کد تولید می‌کند، توسعه‌دهنده دیگر، در حال بازبینی کد است. در واقع به صورت هم‌زمان به مشکلات بالقوه توجه می‌کند و ایده‌هایی برای بهبود کد می‌دهد.
در زمان انتخاب این روش، باید به دو نکته توجه کنید: 1- نوع مساله‌ای قرار است رویش کار کنید 2- سطح تخصص دو برنامه‌نویسی که قرار است با هم کار کنند.
این نوع بازبینی کد، برای زمانی که قصد دارید یک مساله پیچیده را حل کنید، مناسب است. زیرا زمانی که دو ذهن به صورت هم‌زمان در فرآیند یافتن راه‌حل برای یک مساله درگیر می‌شوند، احتمال پیدا کردن راه‌حل درست و مناسب، بیشتر می‌شود. همچنین، در این حالت، با بحث کردن بر روی سناریوهای ممکن مختلف، با احتمال بیشتری نقاط مرزی مساله را پوشش خواهید داد.
زمانی که با مساله‌ای مواجه هستید که منطقهای کاری پیچیده‌ای دارد، برنامه‌نویسی به صورت دونفره گزینه مناسبی است؛ زیرا کمک‌کننده خواهد بود اگر دو نفر بر روی تمام احتمالات و حالات ممکن فکر کنند و اطمینان حاصل کنند که همگی آن حالات به درستی در کد پیاده‌سازی شدهاند.
برخلاف مسائلی با منطقهای کاری پیچیده، ممکن است انجام کاری، نیاز به حل‌کردنِ مساله فنی پیچیده‌ای داشته باشد. به طور مثال، مجبور باشید از یک چارچوب جدید استفاده کنید و یا قسمتی از یک تکنولوژی‌ای که قبلا هیچ وقت با آن کار نکرده بودید را بفهمید. در این شرایط بهتر است خودتان به تنهایی بر روی مساله کار کنید. زیرا مطابق با سطح خودتان می‌توانید پیش بروید. لازم است مقدار زیادی در وب جست‌وجو کنید و مستندات زیادی بخوانید تا بفهمید این تکنولوژی جدید چطور کار می‌کند.
برنامه‌نویسی دونفره در این شرایط کمک‌کننده نیست. زیرا در حین یادگیری فردی، باعث کندی یکدیگر می‌شوید.
اگرچه، اگر جایی گیر کردید، مشورت و هم‌فکری با یک همکار، می‌تواند راه‌گشا باشد.
جنبه بااهمیت دیگری که در برنامه‌نویسی دونفره باید در نظر گرفته شود، هم‌سطح‌بودن دو برنامه‌نویس از نظر فنی و تخصصی است. تخصص دو برنامه‌نویسی که با هم به‌صورت دونفره کار می‌کنند، باید در یک سطح باشد؛ زیرا هر دو با سرعت یکسانی می‌توانند کار کنند.
روش برنامه‌نویسی دونفره با یک ارشد و یک تازه‌کار، خوب جواب نمیدهد. زیرا گر فرمان دست تازه‌کار باشد، احتمالا ارشد خسته شده و حوصله‌اش سر می‌رود. در این شرایط، پتانسیل ارشد هدر رفته و وقتش تلف می‌شود.
و اگر کیبورد زیر دست ارشد باشد، سرعت کار برای تازه‌کار زیاد است. ممکن است ارشد قادر نباشد سطح و پایه تازه‌کار را در نظر بگیرد و پس از چند دقیقه، تازه‌کار دیگر نتواند کار را دنبال کند. تنها در صورتی که ارشد سرعت خود را کم کند و با صبر و حوصله به تازه‌کار توضیح دهد که چرا این کار را انجام داده است، این روش جواب خواهد داد. البته در این صورت، دیگر خبری از برنامه‌نویسی دونفره نیست، درواقع یک جلسه تدریس است که ارشد به یک تازه‌کار یاد می‌دهد، مساله خاصی را چطور حل کند.
اما اگر هر دو برنامه‌نویس در یک سطح باشند، نتیجه شگفت‌انگیز خواهد بود. بزرگترین مزیت‌ش این است که دو برنامه‌نویس یکدیگر را هل می‌دهند و اگر یکی از آن‌ها تمرکز خود را از دست بدهد، دیگری وی را مجددا به مسیر برمی‌گرداند.
برای جمع‌بندی: زمانی که دو برنامه‌نویس با سطح مشابه از نظر فنی و تخصص با هم بر روی یک مساله کاری پیچیده کار کنند، برنامه‌نویسی دونفره بسیار مفید خواهد بود.
@JavaCupIR
دسته دوم از انواع بازبینی کد ملایم: بازبینی هم‌زمان
روش دوم، بازبینی هم‌زمان است. در این روش، برنامه‌نویس، خودش کد می‌زند و از بازبینی‌کننده می‌خواهد که کدش را بازبینی کند. بنابراین، بازبینی‌کننده به پشت میز برنامه‌نویس می‌آید، هر دو به یک مانیتور نگاه می‌کنند و به بازبینی و بهبود کد می‌پردازند.
ضعف اطلاعات بازبینی‌کننده:
این روش بازبینی، زمانی که بازبینی‌کننده در مورد کار انجام‌شده اطلاعات لازم و کافی ندارد، مناسب است. این شرایط زمانی به وجود می‌آید که تیم، جلسات پالایش و جلسات برنامه‌ریزی sprint که در آن در خصوص کارهای آتی بحث و تبادل نظر می‌شود، نداشته باشد. نتیجه این می‌شود که معمولا تنها یک برنامه‌نویس (مسئول انجام کار) نیازمندی‌های کار را می‌داند. در این شرایط، بسیار مفید خواهد بود که قبل از شروع بازبینی، خلاصه‌ای از هدف کار انجام‌شده را ارایه بدهید.
حجم بالایی از بهبود کد انتظار می‌رود:
اگر با توجه به بی‌تجربگی برنامه‌نویس، انتظار حجم بالایی بهبود کد دارید، بازبینی هم‌زمان می‌تواند مناسب باشد. اگر یک ارشدِ باتجربه، کدِ یک برنامه‌نویس تازه‌کار را بازبینی کند، با اینکه بازبینی را با همدیگر انجام می‌دهند، سرعت بازبینی بالا می‌رود. بازبینی کد تا زمان تایید ارشد ادامه می‌یابد.
تغییر اجباری زمینه کاری:
بازبینی هم‌زمان، یک ایراد بزرگ دارد و آن هم تغییر اجباری زمینه کاری (context switching) است. این اتفاق نه تنها کار اصلی بازبینی‌کننده را بسیار مختل می‌کند، بلکه سرعت کل تیم را نیز کاهش می‌دهد.
@JavaCupIR
روش دوم، بازبینی هم‌زمان است. در این روش، برنامه‌نویس، خودش کد می‌زند و از بازبینی‌کننده می‌خواهد که کدش را بازبینی کند. بنابراین، بازبینی‌کننده به پشت میز برنامه‌نویس می‌آید، هر دو به یک مانیتور نگاه می‌کنند و به بازبینی و بهبود کد می‌پردازند.
ضعف اطلاعات بازبینی‌کننده:
این روش بازبینی، زمانی که بازبینی‌کننده در مورد کار انجام‌شده اطلاعات لازم و کافی ندارد، مناسب است. این شرایط زمانی به وجود می‌آید که تیم، جلسات پالایش و جلسات برنامه‌ریزی sprint که در آن در خصوص کارهای آتی بحث و تبادل نظر می‌شود، نداشته باشد. نتیجه این می‌شود که معمولا تنها یک برنامه‌نویس (مسئول انجام کار) نیازمندی‌های کار را می‌داند. در این شرایط، بسیار مفید خواهد بود که قبل از شروع بازبینی، خلاصه‌ای از هدف کار انجام‌شده را ارایه بدهید.
حجم بالایی از بهبود کد انتظار می‌رود:
اگر با توجه به بی‌تجربگی برنامه‌نویس، انتظار حجم بالایی بهبود کد دارید، بازبینی هم‌زمان می‌تواند مناسب باشد. اگر یک ارشدِ باتجربه، کدِ یک برنامه‌نویس تازه‌کار را بازبینی کند، با اینکه بازبینی را با همدیگر انجام می‌دهند، سرعت بازبینی بالا می‌رود. بازبینی کد تا زمان تایید ارشد ادامه می‌یابد.
تغییر اجباری زمینه کاری:
بازبینی هم‌زمان، یک ایراد بزرگ دارد و آن هم تغییر اجباری زمینه کاری (context switching) است. این اتفاق نه تنها کار اصلی بازبینی‌کننده را بسیار مختل می‌کند، بلکه سرعت کل تیم را نیز کاهش می‌دهد.
@JavaCupIR
دسته سوم از انواع بازبینی کد ملایم: بازبینی غیرهم‌زمان
در این روش، بر خلاف روش قبلی، کار بازبینی به صورت هم‌زمان و پشت یک صفحه نمایش انجام نمی‌شود. بلکه به صورت غیرهم‌زمان است. پس از آنکه برنامه‌نویس کدش را نوشت، کد را برای بازبینی ارسال می‌کند و سراغ کار بعدی‌اش می‌رود. هر زمان که بازبینی‌کننده وقت خالی داشت، مطابق با زمان‌بندی خودش و پشت میز خودش و بدون اینکه شخصا با کدنویس صحبتی بکند، کد را بازبینی کرده و با استفاده از ابزارهایی، برای کدنویس کامنت می‌گذارد. پس از پایان کار بازبینی، ابزار مورد استفاده، کدنویس را از وجود کامنت‌ها و کارهای مهمی که مجددا باید انجام دهد، مطلع می‌سازد. کدنویس هم طبق زمان‌بندی خود، مطابق با کامنت‌ها، کدش را تغییر می‌دهد. به محض اینکه این تغییرات آماده بازبینی شدند، چرخه بازبینی مجدد از سر گرفته می‌شود. کدنویس تا زمانی که هیچ کامنتی برای بهبود کدش دریافت نکند، کدش را تغییر می‌دهد. در نهایت، تغییرات تاییدشده و بر روی شاخه master ادغام می‌شوند.
همانطور که مشاهده می‌کنید، بازبینی هم‌زمان و غیرهم‌زمان، کاملا با یکدیگر متفاوتند.
بدون وابستگی مستقیم:
بزرگترین مزیت بازبینی غیرهم‌زمان، همین غیرهم‌زمان بودنش است. کدنویس، مستقیما به بازبینی‌کننده وابسته نیست و هر دو طرف می‌توانند کارشان را با زمان‌بندی دلخواهشان پیش ببرند.
تعداد زیاد چرخه‌های بازبینی:
عیبی که این روش دارد، این است که ممکن است تا زمانی که بازبینی در نهایت تایید شود، چند روز به طول بینجامد. زمانی که کدنویس کارش تمام می‌شود، معمولا چندساعتی طول می‌کشد تا بازبینی‌کننده کار بازبینی را شروع کند. اکثر اوقات، کدنویس، پیشنهادهای بازبینی‌کننده را روز بعد اعمال می‌کند. بنابراین، اولین چرخه بازبینی، حداقل یک روز طول می‌کشد. اگر کار بازبینی، چند چرخه این‌چنینی داشته باشد، در کل شاید حدود بیش از یک هفته زمان ببرد که این زمان، شامل کدنویسی و تست برنامه هم نیست.
اما گزینه‌هایی برای جلوگیری از طولانی شدن این زمان وجود دارد. برای مثال، می‌توان در تیم قانونی گذاشت که هر توسعه‌دهنده، اول صبح و ظهر بعد از ناهار، قبل از آنکه به سراغ هر کاری (task) برود، کارش را با بازبینی‌های در حال انتظار شروع کند.
از آنجایی که توسعه‌دهنده به هر حال پس از یک استراحت طولانی، از فضای کاریش خارج شده، با این قانون، باعث context switiching غیرعادی‌ای نخواهیم شد و در کنارش کارهای بازبینی، در یک زمان منطقی به ثمر می‌رسند.
با مقایسه مزایا و معایب این روش بازبینی، به نظر می‌رسد که بازبینی غیرهم‌زمان، باید روش پیش‌فرض بازبینی برای یک تیم توسعه حرفه‌ای باشد. اما قبل از این که دلیل این تصمیم را بگویم، بیایید به چهارمین روش بازبینی هم نگاهی بیندازیم.
@JavaCupIR
در این روش، بر خلاف روش قبلی، کار بازبینی به صورت هم‌زمان و پشت یک صفحه نمایش انجام نمی‌شود. بلکه به صورت غیرهم‌زمان است. پس از آنکه برنامه‌نویس کدش را نوشت، کد را برای بازبینی ارسال می‌کند و سراغ کار بعدی‌اش می‌رود. هر زمان که بازبینی‌کننده وقت خالی داشت، مطابق با زمان‌بندی خودش و پشت میز خودش و بدون اینکه شخصا با کدنویس صحبتی بکند، کد را بازبینی کرده و با استفاده از ابزارهایی، برای کدنویس کامنت می‌گذارد. پس از پایان کار بازبینی، ابزار مورد استفاده، کدنویس را از وجود کامنت‌ها و کارهای مهمی که مجددا باید انجام دهد، مطلع می‌سازد. کدنویس هم طبق زمان‌بندی خود، مطابق با کامنت‌ها، کدش را تغییر می‌دهد. به محض اینکه این تغییرات آماده بازبینی شدند، چرخه بازبینی مجدد از سر گرفته می‌شود. کدنویس تا زمانی که هیچ کامنتی برای بهبود کدش دریافت نکند، کدش را تغییر می‌دهد. در نهایت، تغییرات تاییدشده و بر روی شاخه master ادغام می‌شوند.
همانطور که مشاهده می‌کنید، بازبینی هم‌زمان و غیرهم‌زمان، کاملا با یکدیگر متفاوتند.
بدون وابستگی مستقیم:
بزرگترین مزیت بازبینی غیرهم‌زمان، همین غیرهم‌زمان بودنش است. کدنویس، مستقیما به بازبینی‌کننده وابسته نیست و هر دو طرف می‌توانند کارشان را با زمان‌بندی دلخواهشان پیش ببرند.
تعداد زیاد چرخه‌های بازبینی:
عیبی که این روش دارد، این است که ممکن است تا زمانی که بازبینی در نهایت تایید شود، چند روز به طول بینجامد. زمانی که کدنویس کارش تمام می‌شود، معمولا چندساعتی طول می‌کشد تا بازبینی‌کننده کار بازبینی را شروع کند. اکثر اوقات، کدنویس، پیشنهادهای بازبینی‌کننده را روز بعد اعمال می‌کند. بنابراین، اولین چرخه بازبینی، حداقل یک روز طول می‌کشد. اگر کار بازبینی، چند چرخه این‌چنینی داشته باشد، در کل شاید حدود بیش از یک هفته زمان ببرد که این زمان، شامل کدنویسی و تست برنامه هم نیست.
اما گزینه‌هایی برای جلوگیری از طولانی شدن این زمان وجود دارد. برای مثال، می‌توان در تیم قانونی گذاشت که هر توسعه‌دهنده، اول صبح و ظهر بعد از ناهار، قبل از آنکه به سراغ هر کاری (task) برود، کارش را با بازبینی‌های در حال انتظار شروع کند.
از آنجایی که توسعه‌دهنده به هر حال پس از یک استراحت طولانی، از فضای کاریش خارج شده، با این قانون، باعث context switiching غیرعادی‌ای نخواهیم شد و در کنارش کارهای بازبینی، در یک زمان منطقی به ثمر می‌رسند.
با مقایسه مزایا و معایب این روش بازبینی، به نظر می‌رسد که بازبینی غیرهم‌زمان، باید روش پیش‌فرض بازبینی برای یک تیم توسعه حرفه‌ای باشد. اما قبل از این که دلیل این تصمیم را بگویم، بیایید به چهارمین روش بازبینی هم نگاهی بیندازیم.
@JavaCupIR
دسته چهارم از انواع بازبینی کد ملایم:
بازبینی دوره‌ای (هر چند وقت یکبار)
روش دیگر این است که هر چند وقت یکبار (مثلا ماهی یکبار) همراه با کل تیم جلسه‌های بازبینی کد برگزار کنیم. به این صورت که در اتاق جلسات نشسته و یکی از توسعه‌دهنده‌ها، یک بخش دشوار از کدی که اخیرا نوشته را توضیح دهد.
سپس، سایر توسعه‌دهنده‌ها تلاش کنند مشکلات بالقوه آن کد را کشف کرده و یادداشت کنند و در نهایت پیشنهادهایی جهت بهبود کد بدهند.
بعید است که یک تیم توسعه به صورت دایمی از این روش برای بازبینی کد استفاده کند. تنها یک موقعیت خاص را می‌توان تصور کرد که این روش جواب دهد و آن هم زمانی است که هیچ یک از اعضای تیم، تجربه‌ای در بازبینی کد نداشته باشند. در این صورت، چندبار جمع کردن افراد در یک اتاق و انجام بازبینی با هم، ممکن است کمک کند تا افراد هدف و مقصود بازبینی کد را درک کنند.
به این ترتیب، برای یک بازه طولانی، استفاده از روش چهارم چندان مناسب نیست، زیرا کار کردن کل تیم بر روی یک تکه‌کد، خیلی کارآمد نیست.
@JavaCupIR
بازبینی دوره‌ای (هر چند وقت یکبار)
روش دیگر این است که هر چند وقت یکبار (مثلا ماهی یکبار) همراه با کل تیم جلسه‌های بازبینی کد برگزار کنیم. به این صورت که در اتاق جلسات نشسته و یکی از توسعه‌دهنده‌ها، یک بخش دشوار از کدی که اخیرا نوشته را توضیح دهد.
سپس، سایر توسعه‌دهنده‌ها تلاش کنند مشکلات بالقوه آن کد را کشف کرده و یادداشت کنند و در نهایت پیشنهادهایی جهت بهبود کد بدهند.
بعید است که یک تیم توسعه به صورت دایمی از این روش برای بازبینی کد استفاده کند. تنها یک موقعیت خاص را می‌توان تصور کرد که این روش جواب دهد و آن هم زمانی است که هیچ یک از اعضای تیم، تجربه‌ای در بازبینی کد نداشته باشند. در این صورت، چندبار جمع کردن افراد در یک اتاق و انجام بازبینی با هم، ممکن است کمک کند تا افراد هدف و مقصود بازبینی کد را درک کنند.
به این ترتیب، برای یک بازه طولانی، استفاده از روش چهارم چندان مناسب نیست، زیرا کار کردن کل تیم بر روی یک تکه‌کد، خیلی کارآمد نیست.
@JavaCupIR
از کدام روش بازبینی باید استفاده کنیم؟
پس از آشنایی با روش‌های مختلف، احتمالا دوست دارید بدانید که کدام روش بازبینی را باید انتخاب کنید.
با ما همراه باشید💪
@JavaCupIR
پس از آشنایی با روش‌های مختلف، احتمالا دوست دارید بدانید که کدام روش بازبینی را باید انتخاب کنید.
با ما همراه باشید💪
@JavaCupIR
انجمن جاواکاپ
بازبینی صوری بازبینی‌های صوری (Formal Code Review)، بر مبنای یک فرآیند صوری هستند. در حال حاضر، Fegan inspection محبوب‌ترین پیاده‌سازی از چنین فرآیندهایی است. در این پیاده‌سازی، با یک فرآیند بسیار ساختارمند که سعی در پیدا کردن نواقص و مشکلات کد دارد، روبرو…
🔸 در مورد روش رسمی صحبت کردیم؛ که واضح است خیلی روش محبوبی نیست و در عمل خیلی کم از آن استفاده می‌شود...
انجمن جاواکاپ
بازبینی ملایم بازبینی ملایم (Lightweight Code Review)، این روزها در بین تیم‌های توسعه معمول‌تر است. می‌توان بازبینی ملایم را مانند آنچه در ادامه آمده است، به چهار زیردسته مختلف تقسیم‌بندی کرد: 🔸 بازبینی فوری: به عنوان برنامه‌نویسی دو نفره هم شناخته می‌شود.…
🔸 سپس در مورد دسته بازبینی ملایم صحبت کردیم و 4 روش مختلف از این دسته را معرفی کردیم.
انجمن جاواکاپ
Photo
1⃣ روش یک، بازبینی فوری، با برنامه‌نویسی دونفره انجام می‌شود زمانی که دو توسعه‌دهنده با توانایی و تخصص یکسان بر روی یک مساله کاری پیچیده کار می‌کنند، مناسب است.
انجمن جاواکاپ
Photo
2⃣ روش دو، بازبینی هم‌زمان، زمانی که بازبینی‌کننده دانش کافی از هدف task ندارد و نیاز به توضیحات توسط کدنویس دارد، مناسب است. همچنین زمانی که به دلیل بی‌تجربگی کدنویس، انتظار بهبودهای زیادی می‌رود، این روش می‌تواند مناسب باشد.
اما اشکالش این است که باعث تغییر context اجباری می‌شود که برای بازبینی‌کننده اذیت‌کننده است و سرعت کل تیم را کم می‌کند.
اما اشکالش این است که باعث تغییر context اجباری می‌شود که برای بازبینی‌کننده اذیت‌کننده است و سرعت کل تیم را کم می‌کند.
انجمن جاواکاپ
Photo
3⃣ روش سه، بازبینی غیرهم‌زمان، از مشکل تغییر context اجباری جلوگیری می‌کند و برای اکثر مواقع معمول، مناسب است.
انجمن جاواکاپ
Photo
4⃣ روش چهار، بازبینی دوره‌ای، برای یک تیم حرفه‌ای، گزینه‌ای دایمی به حساب نمی‌آید و احتمالا تنها زمانی که می‌خواهید روند بازبینی را در تیم‌تان آغاز کنید، مناسب است.