روند بررسی کد خود را بهبود بخشید

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

⚠️ مشکل: ارتباط ضعیف بررسی کد (درخواست های کششی).

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

👀 – مرور

🔀 – تغییرات درخواست شده است

✅ – تایید شده

📝 – نظرات باقی مانده است

استفاده از پیام‌رسانی فوری برای به‌روزرسانی‌های روابط عمومی، به دلایل زیر روشی ناکارآمد برای برقراری ارتباط با روابط عمومی است:

• از همکاران می‌خواهد که اعلان‌هایی را برای واکنش‌های ایموجی فعال کنند.

• شما باید به دنبال پست های کانال بروید تا روابط عمومی را که در حال بررسی/نویسندگی هستید پیدا کنید.

• کانال روابط عمومی می‌تواند با تیم‌های بزرگ‌تر پر شود، به این معنی که روابط عمومی اغلب از دست می‌رود.

در نتیجه، PR ها شروع به انباشته شدن می کنند و کار را مسدود می کنند (حتی اگر یک استراتژی داستان کاربر کارآمد را اتخاذ کنید) تا زمانی که PM (مدیر پروژه) شروع به پرسیدن سؤال کند.

یکی دیگر از روش‌های ضعیفی که من دیده‌ام، پیام‌رسانی فوری به افراد است که مدیران از اعضای تیم می‌خواهند:

بازبینان خود را پیدا کنید / مسئولیت روابط عمومی خود را بپذیرید

تفکر پشت این موضوع این است که مالکیت بلیط را از بقیه اعضای تیم و مدیرانی که در تعقیب وضعیت روابط عمومی هستند حذف کنیم.

با این حال، در عمل، این اتفاق نمی افتد. در عوض، اتفاقی که می‌افتد این است که همکاران با هم تیم می‌شوند و کار یکدیگر را بررسی می‌کنند (به این معنی که سایر اعضای تیم باید در معرض کد پایه قرار بگیرند و شکاف‌های دانشی ایجاد کنند). یا، افراد تیم فردی را پیدا می‌کنند که در نقد کردن عالی است.

راه حل ها

شما می توانید این مشکل را با ابزارهای مدیریت پروژه مانند JIRA، Trello یا بسیاری دیگر که به صورت آنلاین (پرداخت و رایگان) در دسترس هستند، حل کنید. از این به عنوان منبع حقیقت برای حجم کاری تیم توسعه دهنده خود استفاده کنید.

با در نظر گرفتن مثال JIRA یا Trello، هر دو روی تجسم وضعیت بلیط ها (کار) کار می کنند که باید در تیم تکمیل شود.

پیشنهاد من این است که تعدادی ستون اولیه اولیه روی برد Trello / JIRA خود داشته باشید، مانند:

• Todo: ستونی که در آن کارهای شروع نشده منتظر می مانند تا یکی از اعضای تیم در دسترس قرار گیرد.

• در حال پیشرفت: ستونی برای جایی که اعضای تیم روی آن کار می کنند و وظایف محول شده خود را قبل از انتقال به مرحله بعدی تکمیل می کنند.”

• در انتظار بررسی: زمانی که توسعه‌دهنده کار روی آن‌ها را به پایان رساند و یک درخواست کشش برای بررسی توسط یک یا چند عضو تیم ایجاد کرد، بلیط‌ها به ستون «در انتظار بازبینی» منتقل می‌شوند. پیوند درخواست کشش را به بلیط اضافه کنید تا پیدا کردن آن آسان شود.

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

همچنین به این معنی است که هر یک از اعضای تیم این فرصت را دارند که با نگاهی به صفحه و دیدن اینکه آیا چیزی در کد وجود دارد (که به نظر من بسیار بیشتر از کیفیت کد را ارائه می دهد) درگیر فرآیند بررسی کد است. Awaiting Review ستون، توسط یک عضو دیگر نگاه نمی شود.

⚠️ مشکل 2: اما چه کسی درخواست کشش من را بررسی می کند؟

بنابراین ما این مسئله را حل کرده ایم که بدانیم آیا درخواستی برای بررسی وجود دارد یا خیر، اما در مورد اینکه آیا کسی به آن نگاه می کند چه؟

راه حل:

هیئت مدیره شما می تواند شاخص هایی داشته باشد که چه کسانی روی آن کار می کنند. به عنوان مثال، با استفاده از Trello، می توانید اضافه کنید اعضا به هیئت مدیره، نشان می دهد که این عضو با بلیط در وضعیت فعلی آن مرتبط است. به همین ترتیب، در JIRA می توانید بلیط را به همین ترتیب به خود یا دیگران اختصاص دهید.

توجه داشته باشید: هنگام اتخاذ این استراتژی، پیشنهاد می‌کنم هنگام انتقال آیتم‌ها به آن موافقت کنید Awaiting Review ستونی که assignee تنظیم شده است تعیین نشده، به این معنی که واضح است که کسی آن را بررسی نمی کند. سپس، هنگامی که در حال انتخاب PR هستید، باید نام خود را به بلیط اختصاص دهید تا کسی از قبل به آن نگاه کند.

گزینه جایگزین

یک گزینه اضافی، استفاده از عملکرد داخلی بسیاری از هاست های Git برای تخصیص کاربران به درخواست های کششی است. به عنوان مثال، GitHub (یکی از محبوب ترین هاست های git) را انتخاب کنید. می توانید از آنها استفاده کنید مأمورین قابلیت اختصاص دادن خود یا سایر اعضای تیم به یک درخواست کشش ایجاد شده.

چرا این کمک خواهد کرد؟

این تیم می تواند از GitHub به عنوان منبع حقیقت استفاده کند. Github به مکانی تبدیل می شود که تمام فعالیت های Pull Request در آن نظارت و ثبت می شود.

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

1. درخواست کشش را به حال خود رها کنید، زیرا شخص دیگری قبلاً به آن اختصاص داده شده است و آن را بررسی خواهد کرد.
2. خود را به افراد واگذار شده اضافه کنید (شما می توانید چندین نفر داشته باشید)، و نظر دوم را در مورد کد ارائه دهید.

وقتی تیمی دارید که روی یک پروژه کار می کند، می توانید از ترکیب GitHub و JIRA/Trello برای افزایش شفافیت و کارایی استفاده کنید. برای مثال، توسعه‌دهندگان شما می‌توانند از GitHub برای پیگیری بررسی‌های معلق استفاده کنند، در حالی که از JIRA/Trello برای ارائه به‌روزرسانی‌ها برای اعضای غیر فنی تیم، مانند تیم‌های مدیریت پروژه، تحویل، و آزمایش استفاده می‌کنند. این فرآیند به همه این امکان را می دهد که به راحتی بر هر مسدود کننده یا گلوگاه نظارت کنند و همکاری در بین تیم را بهبود بخشند.

چندین ابزار یکپارچه سازی امکان همگام سازی بین Github و JIRA را فراهم می کند و گردش کار کارآمد و دید بهتر را ارتقا می دهد.

⚠️ مشکل 3: تعداد زیادی بلیط در انتظار بررسی هستند

شما تعداد معقولی از توسعه دهندگان در تیم خود دارید، مثلاً حدود 15 تا 20. آنها از طریق کار نیرو می گیرند. با این حال Awaiting Revew ستون از کنترل خارج می شود گلوگاهی از بلیط ها وجود دارد که فقط باید بررسی شوند، و هیچ کس به یکی از دلایل متعدد به آنها نگاه نمی کند، مانند:

1. “من وقت نداشتم.”
2. من مشغول انجام کارم هستم.
3. من مهارتی ندارم که بتوانم در تایید آن منطقه پروژه احساس راحتی کنم.

راه حل

یک محدودیت Work in Progress (WIP) را می توان برای ستون در انتظار بازبینی تنظیم کرد که به هر توسعه دهنده اجازه می دهد هر بار فقط یک یا دو بلیط در این ستون داشته باشد. انجام این کار باعث می شود تعداد بلیط های در انتظار بازبینی به حداقل برسد و به حفظ شتاب کمک می کند. علاوه بر این، تیم را تشویق می کند تا تکمیل کار و پیشبرد آن را در اولویت قرار دهد.

⚠️مشکل 4: عقب نشینی زیاد

معمولاً، PR به دلیل جنبه های کوچکی مانند:

• اشتباهات املایی
• توابع با نام ضعیف
• طرح کد
• تفاوت در سبک های کدنویسی

در نتیجه، روند روابط عمومی با رفت و برگشت غیر ضروری گسترش می یابد.

راه حل

یک تیم برنامه نویسی باید به طور جمعی بر روی استانداردها و سبک های کدنویسی برای ترویج کد سازگار و خوانا توافق کنند. اطمینان از اینکه همه اعضای تیم در یک صفحه هستند و به راحتی می توانند کد یکدیگر را درک کنند.

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

پیاده‌سازی استانداردها و سبک‌های کدنویسی، محیط کدنویسی کارآمدتر و مؤثرتری ایجاد می‌کند. علاوه بر این، مقدار رفت و برگشت را در طول فرآیند بررسی کاهش می دهد، زیرا نویسنده کد باید استانداردهای کدگذاری را که قبلاً توافق شده بود، رعایت می کرد.

موارد اضافی برای در نظر گرفتن

برای تسریع بیشتر این فرآیند، می توانید a لنگر. و یک اسکریپت از پیش commit در پروژه شما. مثلا وجود دارد

• Flake8 یا Black – Linting برای Python
• StyleCop & ReSharper – Linting برای C#
• ESLint – Linting برای جاوا اسکریپت
• StyleLint – Linting برای CSS

Linter ابزاری است که کد شما را تجزیه و تحلیل می کند و آن را در برابر مجموعه ای از قوانین یا دستورالعمل ها بررسی می کند. هدف از لینتر این است که قبل از اجرای کد، اشتباهات یا مشکلات رایج در کد خود را پیدا کند و به شما کمک کند تا خطاها را زودتر شناسایی و رفع کنید.

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

مثال با ESLint و JS Project

می توانید از ابزاری مانند هاسکی استفاده کنید. Husky ابزاری است که به شما امکان می دهد قلاب های Git را به پروژه خود اضافه کنید. قلاب‌های Git اسکریپت‌هایی هستند که به طور خودکار در نقاط خاصی از گردش کار Git مانند قبل یا بعد از یک commit اجرا می‌شوند. با افزودن قلاب هاسکی، می‌توانید اسکریپت‌های سفارشی را برای انجام کارهایی مانند لینتینگ، قالب‌بندی یا آزمایش کد خود قبل از اجرای آن اجرا کنید.

ابتدا هاسکی را به پروژه خود اضافه کنید.

npm install husky eslint --save-dev

هاسکی را در پروژه خود راه اندازی کنید:

npx husky-init && npm install

فایل Package.json خود را در یک پروژه js باز کنید و کد زیر را کپی کنید.

"scripts": {
 "lint": "eslint .",
 "lint-staged": "lint-staged",
 "precommit": "npm run lint-staged"
},

کد بالا یک اسکریپت جدید به نام precommit را تعریف می کند که وقتی می خواهید تغییرات را انجام دهید اجرا می شود.

کد زیر را به فایل package.json خود اضافه کنید تا lint-staged برای اجرای ESLint روی فایل های مرحله بندی شده پیکربندی شود.

این به lint-staged می گوید که ESLint را با گزینه –fix روی همه فایل های جاوا اسکریپت که برای commit مرحله بندی شده اند اجرا کند و سپس به طور خودکار هر تغییری را به Git اضافه کند.

"lint-staged": {
 "*.js": [
 "eslint --fix",
 "git add"
 ]
},

در نهایت، تغییرات خود را در Git انجام دهید و با ایجاد تغییر در فایل جاوا اسکریپت و تلاش برای انجام آن، بررسی کنید که اسکریپت pre-commit با موفقیت اجرا شود. اگر ESLint هر گونه خطا یا هشداری را شناسایی کند، تا زمانی که آنها را اصلاح نکنید، از commit جلوگیری می شود.

نتیجه

ما اجرای موارد زیر را بررسی کرده ایم:

• یک سیستم گردش کار/بلیت با تابلو.
• یک سیستم ارتباطی
• چگونه می توان با افزودن استانداردهای کدنویسی و اسکریپت های Pre-Commit آن را کارآمدتر کرد.

امیدوارم این مقاله اطلاعات مفیدی ارائه کرده باشد یا مواردی را که باید در نظر گرفته شود تا کارها کارآمدتر شود.

در صورت تمایل به من ادامه دهید توییتر و برای مقالات بیشتر مشترک شوید.