#مقاله
«قرارداد برابری اشیا» (Object Equality Contract) بیان می‌کند، زمانی که دو شی با هم برابرند، کد درهم‌سازی (hash code) آن دو شی هم باید با هم برابر باشد.
این قرارداد، برای تمام اشیای جاوایی مورد استفاده در مجموعه‌های مبتنی بر درهم‌سازی (مانند HashMap و HashSet) صدق می‌کند و هدف اصلی آن، بهینه‌سازی کارایی هنگام کار با این مجموعه‌ها است.
احتمالا شنیده‌اید که توصیه می‌شود زمانی که متد ()equals را برای کلاس خود پیاده‌سازی می‌کنید، باید متد ()hashCode را هم پیاده‌سازی کنید.
این کار، یک رویکرد عملی برای پایبندی به «قرارداد برابری اشیا» است. اگر می‌خواهید بدانید که چرا پایبندی به این قرارداد مهم است، مطالعه این مقاله را از دست ندهید.
https://goo.gl/3jaJf1
@JavaCupIR
«قرارداد برابری اشیا» (Object Equality Contract) بیان می‌کند، زمانی که دو شی با هم برابرند، کد درهم‌سازی (hash code) آن دو شی هم باید با هم برابر باشد.
این قرارداد، برای تمام اشیای جاوایی مورد استفاده در مجموعه‌های مبتنی بر درهم‌سازی (مانند HashMap و HashSet) صدق می‌کند و هدف اصلی آن، بهینه‌سازی کارایی هنگام کار با این مجموعه‌ها است.
احتمالا شنیده‌اید که توصیه می‌شود زمانی که متد ()equals را برای کلاس خود پیاده‌سازی می‌کنید، باید متد ()hashCode را هم پیاده‌سازی کنید.
این کار، یک رویکرد عملی برای پایبندی به «قرارداد برابری اشیا» است. اگر می‌خواهید بدانید که چرا پایبندی به این قرارداد مهم است، مطالعه این مقاله را از دست ندهید.
https://goo.gl/3jaJf1
@JavaCupIR
#جاواویژن
فیلم سخنرانی‌های همایش جاواویژن ۹۷ منتشر شد.
http://javacup.ir/java-vision-97-lectures/
@JavaCupIR
فیلم سخنرانی‌های همایش جاواویژن ۹۷ منتشر شد.
http://javacup.ir/java-vision-97-lectures/
@JavaCupIR
#مقاله
حتما نام #Lombok به گوشتان خورده است. Lombok ابزاری است که اخیرا توسط توسعه‌دهندگان جاوا به میزان زیادی استفاده می‌شود و کسانی که از این ابزار استفاده می‌کنند، پس از مدتی، کد زدن بدون Lombok را نمی‌توانند تصور کنند.
جاوا زبان فوق‌العاده‌ای است، اما گاهی اوقات مجبور می‌شوید برای کارهای معمول خود یا سازگاری با برخی چارچوب‌ها، مجموعه‌کدهایی تکراری را به کدهای خود اضافه کنید.
این مجموعه‌کدها، معمولا ارزشی برای منطق برنامه شما ایجاد نمی‌کنند اما به هر حال ناگزیر به ایجاد آن‌ها هستید و این‌جا، جایی است که Lombok کار شما را راحت می‌کند.
از جمله مجموعه‌کدهای تکراری، می‌توان به setterها و getterها، constructorهای متعدد، متدهای equals و hashCode، تولید خودکار کدهای برخی الگوهای طراحی و … اشاره کرد.
ممکن است تصور کنید همه این کارها امروزه توسط IDEهای مدرن انجام می‌شوند، اما عجله نکنید! Lombok فراتر از این حرف‌هاست.
برای آشنایی با Lombok، مطالعه این مقاله را به شما توصیه می‌کنیم:
http://javacup.ir/introduction-to-lombok/
@JavaCupIR
حتما نام #Lombok به گوشتان خورده است. Lombok ابزاری است که اخیرا توسط توسعه‌دهندگان جاوا به میزان زیادی استفاده می‌شود و کسانی که از این ابزار استفاده می‌کنند، پس از مدتی، کد زدن بدون Lombok را نمی‌توانند تصور کنند.
جاوا زبان فوق‌العاده‌ای است، اما گاهی اوقات مجبور می‌شوید برای کارهای معمول خود یا سازگاری با برخی چارچوب‌ها، مجموعه‌کدهایی تکراری را به کدهای خود اضافه کنید.
این مجموعه‌کدها، معمولا ارزشی برای منطق برنامه شما ایجاد نمی‌کنند اما به هر حال ناگزیر به ایجاد آن‌ها هستید و این‌جا، جایی است که Lombok کار شما را راحت می‌کند.
از جمله مجموعه‌کدهای تکراری، می‌توان به setterها و getterها، constructorهای متعدد، متدهای equals و hashCode، تولید خودکار کدهای برخی الگوهای طراحی و … اشاره کرد.
ممکن است تصور کنید همه این کارها امروزه توسط IDEهای مدرن انجام می‌شوند، اما عجله نکنید! Lombok فراتر از این حرف‌هاست.
برای آشنایی با Lombok، مطالعه این مقاله را به شما توصیه می‌کنیم:
http://javacup.ir/introduction-to-lombok/
@JavaCupIR
از آن جایی که کد هیچ کس بی‌نقص نیست، لازم است با روش‌های مختلف بازبینی کد (#code_review) آشنایی داشته باشید و با استفاده از آن‌ها، کدهای خود و هم‌تیمی‌هایتان را در معرض بازبینی قرار دهید.
هر توسعه‌دهنده حرفه‌ای نرم‌افزار، می‌داند که بازبینی کد باید حتما بخشی جدی و مهم از یک فرآیند توسعه باشد. اما چیزی که بیشتر توسعه‌دهندگان نمی‌دانند، این است که روش‌های مختلفی برای بازبینی کد وجود دارد و هر روش، بسته به ساختار تیم پروژه، می‌تواند مزایا و معایب به خصوصی داشته باشد.
در ادامه، روش‌های مختلف بازبینی کد را با هم مرور می‌کنیم و توضیح می‌دهیم که هر روش دقیقا به چه صورت عمل می‌کند.
هدف ما این است که در انتها، قدرت تشخیص اینکه در چه زمانی، از چه روشی باید استفاده کنید را به دست آورید.
در بالاترین در سطح، انواع بازبینی کد را می‌توان به دو دسته
۱-بازبینی صوری (Formal) و
۲-بازبینی ملایم (Lightweight)
دسته‌بندی کرد.
با ما همراه باشید.
@JavaCupIR
هر توسعه‌دهنده حرفه‌ای نرم‌افزار، می‌داند که بازبینی کد باید حتما بخشی جدی و مهم از یک فرآیند توسعه باشد. اما چیزی که بیشتر توسعه‌دهندگان نمی‌دانند، این است که روش‌های مختلفی برای بازبینی کد وجود دارد و هر روش، بسته به ساختار تیم پروژه، می‌تواند مزایا و معایب به خصوصی داشته باشد.
در ادامه، روش‌های مختلف بازبینی کد را با هم مرور می‌کنیم و توضیح می‌دهیم که هر روش دقیقا به چه صورت عمل می‌کند.
هدف ما این است که در انتها، قدرت تشخیص اینکه در چه زمانی، از چه روشی باید استفاده کنید را به دست آورید.
در بالاترین در سطح، انواع بازبینی کد را می‌توان به دو دسته
۱-بازبینی صوری (Formal) و
۲-بازبینی ملایم (Lightweight)
دسته‌بندی کرد.
با ما همراه باشید.
@JavaCupIR
بازبینی صوری
بازبینی‌های صوری (Formal Code Review)، بر مبنای یک فرآیند صوری هستند. در حال حاضر، Fegan inspection محبوب‌ترین پیاده‌سازی از چنین فرآیندهایی است.
در این پیاده‌سازی، با یک فرآیند بسیار ساختارمند که سعی در پیدا کردن نواقص و مشکلات کد دارد، روبرو هستیم.
همچنین برای پیدا کردن نواقص specificationها و طراحی‌ها هم مورد استفاده قرار می‌گیرد.
فرآیند Fegan inspection شامل شش مرحله است: برنامه‌ریزی، مرور اجمالی، آماده‌سازی، جلسه بازرسی، بازنگری و پیگیری.
ایده اصلی این است که نیازمندی‌های خروجی را برای هر مرحله به صورت از پیش تعیین‌شده تعریف کنیم و هنگام اجرای فرآیند، خروجی هر مرحله را بازبینی کرده و آن را با نتیجه مطلوب مقایسه کنیم. سپس تصمیم بگیریم که به مرحله بعدی برویم یا همچنان باید بر روی مرحله فعلی کار کنیم.
چنین رویکرد ساختارمندی، چندان مورد استفاده قرار نمی‌گیرد و احتمالا به دلیل سربار زیادی که دارد، تیم‌های زیادی از آن استفاده نمی‌کنند.
به هر حال، اگر باید نرم‌افزاری را توسعه دهید که در صورت وجود نقص و مشکل، هزینه جانی داشته باشد، در این صورت استفاده از چنین رویکرد ساختارمندی برای پیدا کردن نواقص و مشکلات، معنادار و مفید خواهد بود.
برای مثال، اگر در حال توسعه نرم‌افزاری برای نیروگاه هسته‌ای هستید، احتمالا باید از چنین روشی استفاده کنید تا تضمین شود که هیچ باگی در کد تحویل‌داده‌شده وجود ندارد.
اما اکثر ما، توسعه‌دهندگانی هستیم که بر روی چنین نرم‌افزارهای حیاتی‌ای کار نمی‌کنیم و بنابراین، به جای روش صوری، از یک روش ملایم‌تر برای بازبینی کد استفاده می‌کنیم.
در مطالب بعدی، به معرفی انواع روش‌های بازبینی ملایم می‌پردازیم.
@JavaCupIR
بازبینی‌های صوری (Formal Code Review)، بر مبنای یک فرآیند صوری هستند. در حال حاضر، Fegan inspection محبوب‌ترین پیاده‌سازی از چنین فرآیندهایی است.
در این پیاده‌سازی، با یک فرآیند بسیار ساختارمند که سعی در پیدا کردن نواقص و مشکلات کد دارد، روبرو هستیم.
همچنین برای پیدا کردن نواقص specificationها و طراحی‌ها هم مورد استفاده قرار می‌گیرد.
فرآیند Fegan inspection شامل شش مرحله است: برنامه‌ریزی، مرور اجمالی، آماده‌سازی، جلسه بازرسی، بازنگری و پیگیری.
ایده اصلی این است که نیازمندی‌های خروجی را برای هر مرحله به صورت از پیش تعیین‌شده تعریف کنیم و هنگام اجرای فرآیند، خروجی هر مرحله را بازبینی کرده و آن را با نتیجه مطلوب مقایسه کنیم. سپس تصمیم بگیریم که به مرحله بعدی برویم یا همچنان باید بر روی مرحله فعلی کار کنیم.
چنین رویکرد ساختارمندی، چندان مورد استفاده قرار نمی‌گیرد و احتمالا به دلیل سربار زیادی که دارد، تیم‌های زیادی از آن استفاده نمی‌کنند.
به هر حال، اگر باید نرم‌افزاری را توسعه دهید که در صورت وجود نقص و مشکل، هزینه جانی داشته باشد، در این صورت استفاده از چنین رویکرد ساختارمندی برای پیدا کردن نواقص و مشکلات، معنادار و مفید خواهد بود.
برای مثال، اگر در حال توسعه نرم‌افزاری برای نیروگاه هسته‌ای هستید، احتمالا باید از چنین روشی استفاده کنید تا تضمین شود که هیچ باگی در کد تحویل‌داده‌شده وجود ندارد.
اما اکثر ما، توسعه‌دهندگانی هستیم که بر روی چنین نرم‌افزارهای حیاتی‌ای کار نمی‌کنیم و بنابراین، به جای روش صوری، از یک روش ملایم‌تر برای بازبینی کد استفاده می‌کنیم.
در مطالب بعدی، به معرفی انواع روش‌های بازبینی ملایم می‌پردازیم.
@JavaCupIR
بازبینی ملایم
بازبینی ملایم (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