تقریباً هر توسعه‌دهنده نرم‌افزاری از بررسی کند کد شکایت می‌کند، اما گاهی اوقات، درک علت آنها دشوار است. ممکن است گاهی اوقات به این دلیل باشد که صاحبان حق شناسایی نشده اند، اما بسیاری اوقات ممکن است به دلیل عدم ارتباط باشد. در این مقاله از آنوفل، آنچه می‌تواند باعث کند شدن مرور کدها شود را بررسی می‌کنیم و با تکنیک‌هایی برای بهبود آنها آشنا می‌شویم.
زمان بررسی کد
کل زمان بررسی کد را می توان به عنوان زمان بین ارسال درخواست بازبینی و دریافت تأییدیه از همه بازبینان مورد نیاز تعریف کرد. این فرآیند می تواند به سرعت در اکثر شرکت هایی که بررسی کدهای بین تیمی رایج است، گلوگاه ایجاد کند.
برای درک اینکه چه چیزی باعث ایجاد تنگناها می شود، در اینجا چند سؤال وجود دارد که ارزش پرسیدن دارد:
آیا ما برای هر تغییر بازبین های زیادی داریم؟
آیا ما دستورالعمل های بازبینی بیش از حد سختگیرانه ای داریم؟
آیا تغییرات کد آنقدر بزرگ است که قابل بررسی نیست؟
آیا تکرارهای رفت و برگشتی زیاد است؟
آیا بازبینی کنندگان زمان زیادی را برای ارائه بازخورد صرف می کنند؟
آیا صاحبان برای اجرای بازخورد زمان زیادی صرف می کنند؟
آیا داوران اغلب خارج از دفتر هستند یا در مناطق زمانی مختلف هستند؟
هنگام بررسی این سوالات و پاسخ های مربوطه، واضح است که بسیاری از چالش های بررسی کد اجتماعی یا فرهنگی هستند.
جنبه های اجتماعی
مشوق ها
در یک محیط مهندسی معمولی، هیچ انگیزه ای برای اولویت بندی بررسی کد وجود ندارد. یک استثنا در این مورد ممکن است این باشد که بازبین مسئول عرضه به موقع یک محصول یا ویژگی مرتبط با بازبینی کد نیز باشد.
در مواردی که هیچ انگیزه‌ای وجود ندارد، منطقی است که یک توسعه‌دهنده پایان کار خود را بر بررسی تغییرات دیگران اولویت دهد.
سوالی که ارزش پرسیدن دارد: آیا راهی برای محاسبه تلاش‌های بازبینی کد در چرخه عملکرد وجود دارد؟
سبک های Review
Code reviews ذاتا ذهنی است. هر توسعه‌دهنده‌ای که براساس تجربیات و ترجیحات خود شکل می‌گیرد، به طور متفاوتی به بررسی‌ها می‌پردازد. برخی ممکن است بر جزئیات دقیق سینتکس و سبک تمرکز کنند، در حالی که برخی دیگر تصمیمات معماری و کارایی کد را در اولویت قرار می دهند. اگرچه این تغییرات دیدگاه جامعی را برای پایگاه کد به ارمغان می آورند، اما می توانند روند بررسی را نیز کند کنند.
سوالی که ارزش پرسیدن دارد: آیا دستورالعمل های بررسی کد به خوبی تعریف شده و مستند شده است؟
مالکیت
در حالی که مالکیت به خوبی تعریف شده برای حفظ کیفیت و مسئولیت پذیری ضروری است، می تواند موانعی را نیز در روند بررسی ایجاد کند. اگر مالکیت خیلی دقیق باشد، مجموعه کوچکی از توسعه‌دهندگان که مجموعه‌ای از بررسی‌ها را دریافت می‌کنند ممکن است تنگنا ایجاد کنند. شناسایی بازبین مناسب برای ارائه بازخورد خوب ممکن است دشوار باشد، اگر نیاز به خشن تر بودن باشد.
سوالی که ارزش پرسیدن دارد: چند دایرکتوری یا مخزن سه یا کمتر بازبین دارند؟
چه چیزی را باید بهبود بخشید
دانستن اینکه چه چیزی را باید بهبود بخشید مهمتر از یادگیری چگونگی بهبود است. برخلاف عملکرد سیستم CI/CD، عملکرد بررسی کد به افراد بستگی دارد، نه ماشین‌ها. بنابراین، به‌جای نگاه کردن به «زمان بررسی کد» به‌عنوان یک کل، تقسیم آن به بخش‌های متمایز که در آن می‌توانید بهبود ببخشید، با در نظر گرفتن جنبه‌های اجتماعی و فرهنگی فرآیند، می‌تواند به شما در بهینه‌سازی زمان بازبینی کد کمک کند.
پیچیدگی کد
اندازه گیری پیچیدگی کد می تواند چالش برانگیز باشد. معیار علمی تر پیچیدگی سیکلوماتیکی است که توسط توماس جی مک کیب در سال 1976 معرفی شد. این معیار تعداد مسیرهای مستقل خطی را از طریق کد منبع برنامه اندازه گیری می کند. با این حال، از نقطه نظر بازبینی کد، مهم‌ترین چیزی که باید در نظر گرفت این است که آیا کد به راحتی قابل درک است یا «قابلیت بررسی» آن.
برای ساده‌تر شدن، می‌توانیم از چند پروکسی برای تعریف پیچیدگی کد استفاده کنیم:
خطوط تغییر: داشتن خطوط کد کمتر برای بازبینی مستقیماً با سهولت بازبینی ارتباط دارد.
تعداد مراجع: یعنی تعداد مکان هایی که از متد ها یا سرویس ها که در حال تغییر هستند استفاده می کنیم.
مهندسی بیش از حد: آیا سعی می کنید کد را بیش از حد عمومی کنید یا برای یک سناریوی آینده دور بسازید؟ تعیین این نیز ممکن است سخت باشد و مستلزم قضاوت بیشتر از سوی بازبینان باشد.
زمان تکرار
اگر بازبینی کد یک تبادل بازخورد مبتنی بر نوبت بین author تغییر کد و بازبین‌ها باشد، «زمان تکرار» را می‌توان به‌عنوان مدت زمانی که طول می‌کشد تا هر تبادل به یک نتیجه رضایت‌بخش برسد تعریف کرد. در فرآیند بررسی کد، پیش از آن دشوار است که بدانید قبل از اینکه تغییر آماده ادغام شود، چند بار تکرار خواهد شد. با این حال، کاهش زمان برای هر تکرار می تواند زمان کلی برای بررسی کد را بهبود بخشد.
در اینجا دلیل ضروری بودن زمان تکرار است:
حلقه بازخورد تسریع‌شده: هرچه زمان بازگشت سریعتر باشد، توسعه‌دهندگان سریعتر می‌توانند مشکلات را برطرف کنند، روی بهبودها تکرار کنند و کد خود را در پایگاه کد اصلی ادغام کنند.
بهبود تجربه توسعه‌دهنده: وقتی توسعه‌دهندگان بازخورد سریع و سازنده را در طول بررسی کد تجربه می‌کنند، احساس قدرت می‌کنند تا بهترین کار خود را انجام دهند. این رضایت روحیه فردی را تقویت می کند و میزان حفظ و انسجام کلی تیم را افزایش می دهد.
آگاه به زمینه باشید: وقتی پاسخ به بررسی کد زمان زیادی طول می کشد، author و بازبین ممکن است بخشی از زمینه و پس زمینه تغییر را از دست بدهند. این می تواند پیامدهای شدیدی داشته باشد و باعث نقص شود.
رفتار خوب را تشویق کنید: بازبینی کدهای آهسته، توسعه دهندگان را از رفتن مایل بیشتر و انجام اصلاح‌کننده‌ها یا پاک‌سازی کدها منصرف می‌کند، زیرا این کار زمان بیشتری را به فرآیند تأیید اضافه می‌کند.
چه چیزی را نباید (به طور مستقیم) بهبود بخشید؟
زمان بین شروع و اتمام فرآیند تولید برای تغییرات
یکی از معیارهای کلیدی DORA نیز "Lead Time for Changes" است. این زمان از زمان اجرای کد تا استقرار کد را اندازه گیری می کند و زمان کوتاه تر به طور کلی با عملکرد بهتر تحویل نرم افزار همراه است. همراه با فرآیندهای CI و CD، بررسی کد نقش مهمی در بهبود این معیار دارد. تمرکز بر کاهش کل زمان تایید کد وسوسه انگیز است. با این حال، اعمال زمان‌بندی‌های سختگیرانه برای تأیید تغییر کد غیرواقعی است و ممکن است بازبین‌ها را مجبور کند تا PR را پیش از موعد برای مطابقت با استانداردها تأیید کنند.
برعکس، اکثر شکایات مربوط به بررسی کند کد را می توان با معیارسنجی و بهبود زمان پاسخ به بررسی حل کرد. خط مشی بررسی کد گوگل همچنین بر زمان پاسخ به عنوان یک شاخص مهم تاکید دارد:
برای پاسخ‌های فردی حتی مهمتر از این است که فرآیند به سرعت اتفاق بیفتد.
درصد پوشش تست
اگرچه این یک روش استاندارد برای اندازه گیری سلامت کد است، درصد پوشش تست ها به عنوان یک عدد مطلق می تواند معیار بهتری باشد. پوشش تست بالا می‌تواند حس امنیت کاذبی ایجاد کند، به این معنی که نرم‌افزار به خوبی تست شده و بدون باگ است. و بازده کاهشی را فراهم می کند، با افزایش پوشش تست، تلاش برای پوشش چند خط آخر کد در مقایسه با مزایا می تواند به طور نامتناسبی بالا باشد.
اندازه‌گیری اثربخشی واقعی تست به کار زیادی نیاز دارد. تست مؤثر مستلزم بررسی دقیق موارد لبه، حالت‌های خرابی و سناریوهای کاربر است که توسط معیارهای پوشش ثبت نشده‌اند.
تست معماری در لاراول چگونه است؟
نحوه بهبود
بررسی SLO
هدف سطح سرویس (SLO) برای بررسی کد را می توان به عنوان مدت زمانی پیشنهادی که بازبین باید برای پاسخ به تغییر کد صرف کند، تعریف کرد. توجه داشته باشید که این مدت زمان لازم برای تایید یک PR نیست. در عوض، فقط زمان لازم برای دریافت پاسخ است.
بررسی کد SLO را به عنوان توافقی بین author و بازبین برای درخواست PR در نظر بگیرید. با این توافقنامه، author انگیزه ایجاد PRهایی می شود که در محدوده توافق نامه SLO قرار می گیرند، و بازبینان انگیزه می یابند که در راس PR قرار بگیرند.
بررسی کد غول پیکر
اما یک لحظه صبر کنید، همه بررسی های کد یکسان نیستند! چگونه می توانیم انتظار داشته باشیم که شخصی یک تغییر 1000 خطی و یک تغییر دو خطی را به طور همزمان بررسی کند؟ هنگام محک زدن زمان تکرار، واقع بین بودن ضروری است. بهترین معیار باید اندازه بررسی را در نظر بگیرد. برای مثال، یک پیش‌فرض خوب می‌تواند این باشد که «تغییر کد با کمتر از 200 خط نیاز به پاسخ در یک روز کاری دارد».
در این صورت، هر چیزی بیش از 200 خط تغییر را می توان کنار گذاشت. این همچنین توسعه دهندگان را تشویق می کند تا تغییرات جزئی بیشتری را آماده کنند که بررسی آنها آسان تر باشد.
بررسی های بین تیمی
مهندسی نرم افزار یک فعالیت مبتنی بر تیم است. برای توسعه دهندگانی که در یک تیم کار می کنند معمول است که سریعتر به بررسی کدهای یکدیگر پاسخ دهند زیرا قبلاً یک قرارداد اجتماعی ساخته اند. بنابراین، محک زدن بررسی های بین تیمی و درون تیمی به صورت متفاوت نیز می تواند ارزشمند باشد.
ملاحظات دیگر
روزهای کاری: برای دریافت داده های معنی دار، روزهای کاری را پیگیری کنید و تعطیلات شرکت و منطقه را حساب کنید.
مناطق زمانی: به طور مشابه، درک مناطق زمانی می تواند هنگام اندازه گیری زمان پاسخ مفید باشد. به عنوان مثال، اگر در کالیفرنیا هستید و بازبینی کننده کد شما در استرالیا است، و کد را برای بررسی در ساعت 10 صبح روز جمعه ارسال می کنید، منتظر پاسخ بازبین در صبح دوشنبه باشید.
بهبود بررسی SLO
1. اولویت بندی بررسی کد: تیم را تشویق کنید که بررسی کد را بخشی جدایی ناپذیر از فرآیند توسعه بداند، نه یک فکر بعدی.
2. زمان‌بندی برای بررسی‌ها: اعضای تیم باید زمان‌های خاصی را در طول روز کاری برای بررسی کد بگذارند. این تضمین می کند که بررسی ها به سرعت انجام می شود و بازخورد در سریع ترین زمان ممکن به توسعه دهنده ارائه می شود.
3. از ابزارهایی برای تسریع بازخورد استفاده کنید: ابزارهایی را برای کمک به خودکار کردن برخی از جنبه‌های فرآیند بررسی کد، مانند پرچم‌گذاری مشکلات احتمالی، پیاده‌سازی کنید. این ابزارها می‌توانند به شناسایی مشکلاتی در کد کمک کنند که تشخیص آنها ممکن است مدت بیشتری طول بکشد.
4. به طور منظم SLO ها را نظارت و تنظیم کنید: این تضمین می کند که تیم همیشه در فرآیند بررسی کد خود به دنبال یک هدف واقعی است.
چرا CI/CD برای شرکت شما مهم است؟
گیت هاب اکشن چیست؟ آشنایی بیشتر با این ابزار
ویرایش SLO
مشابه SLO بازبینی، SLO تجدیدنظر را می‌توان به عنوان مدت زمانی پیشنهادی که نویسنده تغییر کد باید برای پاسخ دادن پس از اظهار نظر یا تأیید تغییر کد از نظر بازبین صرف کند، تعریف کرد.
بازنویسی
در بسیاری از موارد، ویرایش SLO باید بسیار مختصر باشد - برای مثال، اگر بازخورد داور حداقل باشد یا اگر نویسنده با توضیحاتی به بازبین پاسخ می‌دهد. با این حال، در برخی موارد، بازخورد بازبین ممکن است نیاز به بازنویسی قابل توجهی داشته باشد یا وابستگی به تغییر دیگری ایجاد کند.
در چنین مواردی، فراخوانی درخواست بررسی کد ممکن است منطقی باشد و پس از اعمال تغییرات، دوباره آن را ارسال کنید. این استراتژی بار شناختی نویسنده و داور را کاهش می دهد، به خصوص اگر SLO ها به خوبی تعریف شده باشند.
نتیجه
بهبود فرآیند بررسی کد چیزی بیش از تقویت جنبه های فنی یا سرعت بخشیدن به جدول زمانی است. نیاز به رویکردی متعادل دارد که عنصر انسانی را در نظر بگیرد.
اجرای بازبینی و بازنگری اهداف سطح خدمات (SLOs) متناسب با ماهیت بازنگری کد، معرفی ابزارهای کارآمد، و ایجاد فرهنگی که به بازبینی کد به عنوان بخشی جدایی ناپذیر از چرخه عمر توسعه ارزش می دهد و اولویت بندی می کند. استراتژی های موثر علاوه بر این، پرورش فرهنگی که تغییرات جزئی و قابل مدیریت تر را تشویق می کند و اهمیت بررسی های بین تیمی را تایید می کند، می تواند به پیشرفت های قابل توجهی منجر شود.