Ex Snapp! Senior Software Engineer
فوق لیسانس هوش مصنوعی از دانشگاه تهران
اشتراک محتوا در مورد مهندسی نرم افزار، ایجنت های هوش مصنوعی
https://gocasts.ir
پروفایل
https://www.linkedin.com/in/gohossein
ارتباط
@lifography
Ai for Software
@aicasts_ir
Post #623
5.02K
تو جلسات code review به چه چیزایی گیر بدیم؟
اینی که میگم صرفا تجربه شخصی من هست و لزوما همه نکاتش درست نیست و همه جا جواب نده!
من سعی میکنم فضای ذهنی تیم رو برای code review به گونه ای آماده کنم که به صورت incremental نحوه ریویو کد تغییر کنه.
مثلا تو جلسه اول یا جلسات اولیه خوبه که به جزیی ترین نکات کد گیر داده بشه و کلا merge requestها کوچیک باشن که بشه سختگیرانه تر ریویو کرد.
هر چقدر که جلسات کد ریویو جلوتر میره سعی میکنم بیشتر روی ساختار کد از نظر معماری و نکات طراحی و چالش های پیاده سازی خاص سخت گیری کنم و دیگه به جزییات کدهای تیپیکال کمتر توجه کنم. چرا؟ چون انتظار دارم بصورت تدریجی هر چقدر که جلو میریم افراد تیم با باید و نبایدهای ریویو بیشتر آشنا شده باشن و نکات معمولی رو رعایت کنن.
استفاده از ابزارهای lint در ci هم میتونه کمک کنه که یه سری سختگیری های ریویو توسط ci انجام بشه و تمرکز reviewer روی همون چالش های اصلی کد باقی بمونه.
همچنین داشتن unit test و end to end test هم میتونه کمک کنه که از نظر لاجیک بیزینسی و functionality صحت سنجی خودکاری در سطح ci رخ بده و در جلسه ریویو کمتر لازم باشه به این نکات توجه بشه.
البته این به این معنی نیست که هیچ وقت دیگه هیچ تیکه کد خاصی ریویو نمیشه بصورت دقیق، ولی سعی میشه صرفا کدهایی که چالش پیاده سازی خاصی دارن و از حالت روتین خارج هستند مورد توجه قرار بگیره.
داشتن جلسات solution design و ساختار کد یکپارچه هم کمک میکنه چالش های ریویو کد کمتر بشه چون یکنواختی کد خودش یعنی رعایت کردن اصول مد نظر تیم توسط برنامه نویس.
کلا ریویو کردن کد به عوامل خیلی متنوعی بستگی داره و از جنس بیزینس و کد گرفته تا معماری و ساختار تیم و خیلی چیزای دیگه میتونن تاثیر بذارن روی نحوه برگزاریش و نمیشه یه سری practice خاص رو روی همه پروژه ها اعمال کرد.
ولی خواستم بگم نکته مهم اینه که اگه تلاش بشه بصورت تدریجی کیفیت جلسات ریویو متفاوت و متنوع بشه احتمالا خروجی بهتری میده و از یه کار روتین و یکنواخت خارج میشه.
@gocasts
اینی که میگم صرفا تجربه شخصی من هست و لزوما همه نکاتش درست نیست و همه جا جواب نده!
من سعی میکنم فضای ذهنی تیم رو برای code review به گونه ای آماده کنم که به صورت incremental نحوه ریویو کد تغییر کنه.
مثلا تو جلسه اول یا جلسات اولیه خوبه که به جزیی ترین نکات کد گیر داده بشه و کلا merge requestها کوچیک باشن که بشه سختگیرانه تر ریویو کرد.
هر چقدر که جلسات کد ریویو جلوتر میره سعی میکنم بیشتر روی ساختار کد از نظر معماری و نکات طراحی و چالش های پیاده سازی خاص سخت گیری کنم و دیگه به جزییات کدهای تیپیکال کمتر توجه کنم. چرا؟ چون انتظار دارم بصورت تدریجی هر چقدر که جلو میریم افراد تیم با باید و نبایدهای ریویو بیشتر آشنا شده باشن و نکات معمولی رو رعایت کنن.
استفاده از ابزارهای lint در ci هم میتونه کمک کنه که یه سری سختگیری های ریویو توسط ci انجام بشه و تمرکز reviewer روی همون چالش های اصلی کد باقی بمونه.
همچنین داشتن unit test و end to end test هم میتونه کمک کنه که از نظر لاجیک بیزینسی و functionality صحت سنجی خودکاری در سطح ci رخ بده و در جلسه ریویو کمتر لازم باشه به این نکات توجه بشه.
البته این به این معنی نیست که هیچ وقت دیگه هیچ تیکه کد خاصی ریویو نمیشه بصورت دقیق، ولی سعی میشه صرفا کدهایی که چالش پیاده سازی خاصی دارن و از حالت روتین خارج هستند مورد توجه قرار بگیره.
داشتن جلسات solution design و ساختار کد یکپارچه هم کمک میکنه چالش های ریویو کد کمتر بشه چون یکنواختی کد خودش یعنی رعایت کردن اصول مد نظر تیم توسط برنامه نویس.
کلا ریویو کردن کد به عوامل خیلی متنوعی بستگی داره و از جنس بیزینس و کد گرفته تا معماری و ساختار تیم و خیلی چیزای دیگه میتونن تاثیر بذارن روی نحوه برگزاریش و نمیشه یه سری practice خاص رو روی همه پروژه ها اعمال کرد.
ولی خواستم بگم نکته مهم اینه که اگه تلاش بشه بصورت تدریجی کیفیت جلسات ریویو متفاوت و متنوع بشه احتمالا خروجی بهتری میده و از یه کار روتین و یکنواخت خارج میشه.
@gocasts
- 👍 42
- ❤ 6
