چگونه بررسی کد خود را تسریع کنیم؟

فرآیند بررسی کد اغلب می تواند خسته کننده و پر از تنگناها باشد، که آن را کند و زمان بر می کند. با این حال، ابزارهایی مانند Promyze و Reviewpad وجود دارند که می توانند به بهبود روند بررسی کد کمک زیادی کنند و میزان قابل توجهی از کار شما و تیمتان را صرفه جویی کنند. در این مقاله که توسط Promyze ارائه شده است، استراتژی های موثری را در مورد چگونگی تسریع روند بررسی خود کشف خواهید کرد.

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

زمان انجام تغییر، مدت زمانی است که یک تعهد برای وارد شدن به تولید طول می‌کشد و بخشی از معیارهای 4 کلیدی است که توسط تحقیق و ارزیابی DevOps (DORA) تعریف شده است.
تیم های مهندسی به دنبال بهینه سازی این تاخیر هستند تا ارزش زودتر را به مشتریان خود ارائه دهند. اما قبل از آوردن راه حل، ابتدا مشکل را تعریف می کنیم:

در طول بررسی کد، چه چیزی می تواند کل فرآیند را کند کند، گلوگاه ایجاد کند و زمان تغییر را افزایش دهد؟

https://www.youtube.com/watch?v=cqxtE-DcvcA

محدود کردن زمینه و هدف بررسی کد

مهمترین موانعی که برای بازبینی کد ذکر می شود کمبود منابع انسانی و حجم کاری مهندسان است که زمان کافی برای بررسی کدها را نمی دهد. یک واکنش رایج شامل افزودن منابع انسانی بیشتر برای رسیدگی به موضوع است. نه خیلی سریع!

ابتدا از خود بپرسید:
آیا بررسی هر کد واقعا ضروری است؟ آیا می‌توانیم تأیید کنیم که همه بحث‌ها در بررسی‌ها مرتبط هستند و باید در آنجا اتفاق بیفتند؟

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

تایید کد شماره 1

قبل از ادغام باید مطمئن شوم کدم درست است ⇒ به تأیید شما نیاز دارم.

در این مورد، ممکن است باعث ایجاد اصطکاک از هر دو طرف شود، زیرا بررسی‌ها در اواخر فرآیند انجام می‌شوند.
نویسندگان می‌توانند نظرات را به‌عنوان محدودیتی که ارائه آن‌ها را کند می‌کند، و برای دریافت نظرات بسیاری که همیشه با آن موافق نیستند، احساس ناامیدی کنند.
داوران همچنین می توانند رفتار دفاعی را اتخاذ کنند. چه می شود اگر فکر کنند: «این کار را نمی کردم [the code] بدین ترتیب.
اینو بگم؟ آیا برای ادغام باید مسدود شود؟ همکار من 2 روز صبر می کند. چگونه از بازخورد من استقبال می شود؟
بنابراین می‌توانید ببینید که اصطکاک‌ها می‌توانند از بررسی کد پدید آیند، عمدتاً به این دلیل که فشار ناشی از تلاش برای زمان رضایت‌بخش برای تغییر را داریم.

#2 برای بهبود کد کمک بگیرید

من می خواهم کدم را به شما نشان دهم و بازخورد شما را برای بهبود آن دریافت کنم ⇒ به کمک شما نیاز دارم.

در مقایسه با مورد شماره 1، ما به دنبال بهبود کد خود و یادگیری از یک همتا هستیم.
در این زمینه، شایان توجه است که آیا این بررسی بخشی از فرآیند تحویل است یا خیر.
ممکن است متقاعد شده باشیم که این کد می تواند ابتدا ادغام شود. این چیزی است که معمولاً در توسعه مبتنی بر تنه مشاهده می شود.

گردش کار و سیاست ها بر اساس زمینه روابط عمومی متفاوت است، بنابراین منطقی است که آن را به وضوح تعریف کنید.

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

آیا هنوز به بررسی کد نیاز داریم؟

جدا از این بحث، ممکن است بپرسید که آیا انجام بازبینی کد هنوز در سال 2023 منطقی است، در دورانی که می‌توانیم ابزارهای «اتوماسیون DevOps» را در بازار پیدا کنیم.

ما در نظر داریم که، بله، در واقع، بازبینی کد هنوز ضروری است.
اگرچه ابزارهای خودکار به طور فزاینده ای قدرتمند شده اند، اما در تشخیص مشکلات شناخته شده خوب هستند.
آنها نمی توانند عدم وجود مشکلات را ثابت کنند. به این نقل قول Dijkstra فکر کنید:

“تست برنامه را می توان برای نشان دادن وجود اشکالات استفاده کرد، اما هرگز برای نشان دادن عدم وجود آنها!”

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

حال بیایید به موضوع اصلی خود بازگردیم: چگونه به مسائل فوق الذکر رسیدگی کنیم؟

بررسی کد را فقط زمانی انجام دهید که منطقی باشد

مفهوم درخواست کشش سیال

برای پاسخ به این سوال: «آیا همه درخواست‌های کششی نیاز به بررسی کد دارند؟»، می‌توانیم مدل Ship Show Ask را بررسی کنیم. در این رویکرد*، * نویسندگان روابط عمومی برای ارزیابی خود بدون اعتماد در نظر گرفته می شوند اگر:

• کد نیازی به بازبینی کد ندارد زیرا تغییرات بی اهمیت هستند (کشتی)
• آنها مایلند تغییرات کد را به همکاران نشان دهند و بازخورد آنها را دریافت کنند (نمایش). این حالت می تواند کاملاً غیرطبیعی به نظر برسد زیرا بازخورد می تواند پس از ادغام ارائه شود. این بخشی از تغییر پارادایم است.
• کد نیاز به بررسی دارد (بپرسید)

بنابراین به جای اضافه کردن نیروی انسانی بیشتر برای بازنگری کد، ضرورت تایید هر یک از روابط عمومی را بازنگری می کنیم.
به این ترتیب می‌توانیم تأثیر مثبتی بر زمان انجام تغییر داشته باشیم. به این مفهوم درخواست کشش سیال نیز گفته می شود.

درخواست های کشش نسل بعدی با Reviewpad

Reviewpad یک برنامه GitHub است که برای خودکارسازی فرآیند بررسی کد شما طراحی شده است و مفهوم درخواست کشش سیال را پیاده سازی می کند.
یک فایل پیکربندی واحد در مخزن Git شما حاوی تمام گردش‌های کاری و خط‌مشی‌های شما برای درخواست‌های کششی شما خواهد بود.
بر اساس زمینه، قوانینی را برای اعمال یا تسهیل شبکه امنیتی خود تعریف خواهید کرد. با Reviewpad می توانید قوانینی مانند:

• اگر فایلی در این پوشه ویرایش شود، یک نفر از این گروه باید کد را تایید کند.
• اگر PR شامل یک روش جدید در کد با حاشیه نویسی @Critical است، یک برچسب ‘security’ اضافه کنید و نیاز به اعتبارسنجی دوگانه دارید. قوانین می توانند تصمیم بگیرند که آیا PR ها می توانند به طور خودکار ادغام شوند یا رد شوند، یک گردش کار اعتبار سنجی و موارد دیگر را تعریف کنند. قوانین می توانند به الگوهای نحوی در تغییرات کد بپردازند.

در اینجا یک مثال از گردش کار برای افزایش خودکار آگاهی در هنگام معرفی یک تغییر حیاتی آورده شده است:

labels:
  critical:
    description: Modifications to critical changes
    color: "#294b75"

groups:
  - name: owners
    spec: '["lina", "caris"]'

workflows:
  - name: changes to critical code
    run:
      - if: $hasAnnotation("critical") || $hasFileName("runner.go")
        then:
          - $addLabel("critical")
          - $assignReviewer($group("owners"), 1)
          - '$info("@samir: you are being notified because critical code was modified")'

بهترین شیوه ها را مورد بحث قرار دهید و بررسی های خارج از کد را طراحی کنید

اشتراک دانش باید جمعی باشد

اگر برای بهبود کد خود یا نشان دادن آن درخواست بازبینی دارید، این کار نباید تحت فشار قبل از ادغام کد انجام شود.
مهندسان در عوض باید زمان اختصاصی برای بحث در مورد طراحی کد و بهترین شیوه‌ها بیابند و از اصطکاک اجتناب کنند.
اگر مکالمه 1:1 دارید و در مورد بهترین روش بحث می کنید، بحثی را برگزار می کنید که ممکن است بر کل تیم شما تأثیر بگذارد.
در واقع، اگر تصمیمی بگیرید، آیا همه نباید با آن موافق باشند؟ ما می توانیم فرض کنیم که شما به دنبال یکنواختی کد و همسویی تمرین هستید.

بنابراین شاید زمان آن رسیده است که کارگاه های اختصاصی را در مورد بهترین شیوه های کدنویسی خود در نظر بگیرید، زیرا مکالمات 1:1 نباید مکان مناسبی برای این منظور باشد.

به اشتراک گذاری بهترین شیوه ها با Promyze

Promyze یک پلت فرم به اشتراک گذاری دانش برای توسعه دهندگان است و ادغام با IDE و بررسی کد (GitHub، GitLab، Azure DevOps، Bitbucket، و Helix Swarm) را ارائه می دهد.
با افزونه‌های بررسی کد، می‌توانید بهترین روش کدنویسی را از یک نظر ایجاد کنید و کد به همراه بهترین پیشنهاد شما برای Promyze ارسال می‌شود.
بنابراین از بحث های طولانی 1:1 در طول بررسی کد جلوگیری می کنید.

سپس، Promyze به تیم شما کمک می کند تا به طور منظم کارگاه های اختصاصی را برای بررسی مشارکت های توسعه دهندگان (که در طول بررسی کد یا در داخل IDE انجام شده است) اجرا کنند.
زمان مناسبی برای به اشتراک گذاشتن دانش و تصمیم گیری فنی با هم و اطمینان از همسویی همه با حرکات مناسب برای اعمال در کد است.
این یک روند بهبود مستمر برای بهترین شیوه های کدنویسی شما و رشد مهارت های توسعه دهندگان است.

آیا می خواهید بررسی کد خود را تسریع کنید؟

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

• لزوم تایید هر تغییر کد را در نظر بگیرید.
• جلسات اختصاصی را در نظر بگیرید تا از بحث های بی پایان در طول بررسی جلوگیری کنید.

ما همچنین نشان دادیم که Reviewpad و Promyze می‌توانند مکمل یکدیگر برای تسریع بررسی کد و در عین حال تقویت اشتراک دانش باشند.

به ما بگویید که آیا زمان پیشروی خود را برای تغییر در زمینه خود بهبود داده اید و چگونه آن را ایجاد کرده اید. ما خوشحال می شویم که یاد بگیریم!