بررسی کد می تواند یک تغییر دهنده بازی برای تیم های Frontend در هنگام انجام درست باشد. آنها قبل از رسیدن به تولید ، بهبود کیفیت کد و گسترش دانش در تیم ، به گرفتن اشکالات کمک می کنند. اما اغلب اوقات ، بررسی ها به یک جلسه NITPICK ناامید کننده تبدیل می شوند.
اگر تا به حال بخشی از بررسی کد بوده اید که مانند اتلاف وقت (یا بدتر از آن ، سردرد غیر ضروری) احساس می کنید ، تنها نیستید. در اینجا برخی از بزرگترین اشتباهاتی که توسعه دهندگان جبهه در هنگام بررسی کد و نحوه رفع آنها انجام می دهند ، آورده شده است.
1. تمرکز روی سبک به جای ماده
همه ما دیده ایم که این اتفاق می افتد – یک موضوع بررسی به بحث در مورد زبانه ها در مقابل فضاها تبدیل می شود ، یا اینکه آیا یک عملکرد باید نامگذاری شود fetchData یا getData
چگونه آن را اصلاح کنیم:
- اجرای سبک خودکار. از ابزارهایی مانند ESLINT و Prettier استفاده کنید تا داوران نیازی به اظهار نظر در مورد قالب بندی نداشته باشند.
- اولویت بندی آنچه مهم است. روی عملکرد ، عملکرد ، امنیت و قابلیت حفظ تمرکز کنید. سبک فقط باید مسئله ای باشد که بر خوانایی تأثیر بگذارد یا ناسازگاری ها را معرفی کند.
2. کدی را به صورت محلی آزمایش نکنید
اگر همه چیز خوب به نظر برسد ، وسوسه انگیز است که از طریق کد استفاده کنید و آن را تأیید کنید. اما کدی که در یک تفاوت GitHub خوب به نظر می رسد می تواند به طور غیر منتظره ای رفتار کند وقتی واقعاً آن را اجرا می کنید.
نحوه رفع آن:
- شاخه را بکشید و تغییرات را خودتان آزمایش کنید. روی اطراف کلیک کنید ، موارد لبه را امتحان کنید و اطمینان حاصل کنید که این ویژگی مطابق انتظار کار می کند.
- از ابزارهای مرورگر استفاده کنید. مشکلات مربوط به عملکرد ، خطاهای کنسول و مشکلات دسترسی را بررسی کنید.
- تست ها را اجرا کنید. اگر تست ها گنجانده شده اند ، اطمینان حاصل کنید که آنها واقعاً می گذرانند.
3. تعیین پیامدهای عملکرد
عملکرد Frontend بسیار مهم است. یک قطعه کد ممکن است کار کند اما هنوز هم موارد عملکرد ظریف مانند بازپرداخت های غیر ضروری ، اندازه بسته های بزرگ یا تماس های بیش از حد API را معرفی می کند.
نحوه رفع آن:
- به روزرسانی های ناکارآمد حالت را جستجو کنید. آیا این مؤلفه جدید باعث ایجاد مجدد غیر ضروری می شود؟ آیا باید از آن یاد شود؟
- وابستگی های نفخ را بررسی کنید. آیا روابط عمومی برای کاری که می توانست به صورت بومی انجام شود ، یک کتابخانه سنگین معرفی کرد؟
- آزمون برای پاسخگویی. آیا کد جدید بر زمان بار ، انیمیشن ها یا تعامل تأثیر می گذارد؟
4. پرش از بررسی های دسترسی
دسترسی (A11y) اغلب به عنوان یک پس از آن رفتار می شود تا زمانی که کاربر دارای معلولیت با برنامه شما مبارزه کند. اشتباهات اساسی مانند گم شدن متن ALT ، کنتراست ضعیف یا ناوبری صفحه کلید شکسته می تواند یک برنامه را برای بسیاری از افراد غیرقابل استفاده کند.
نحوه رفع آن:
- با یک خواننده صفحه نمایش تست کنید. آیا می توانید محتوا را بدون ماوس حرکت کرده و درک کنید؟
- از ابزارهای دسترسی استفاده کنید. کد را از طریق Lighthouse یا Ax Devtools اجرا کنید تا مشکلات مشترک داشته باشید.
- ناوبری صفحه کلید را بررسی کنید. آیا کاربران می توانند از طریق عناصر به درستی برگه کنند؟ آیا تمرکز به درستی مدیریت می شود؟
5. بازخورد بی فایده
بررسی های کد بد فقط مربوط به آنچه شما می گویید نیست ، بلکه نحوه گفتن آن است. اظهارات مبهم مانند “این به نظر می رسد اشتباه” یا “رفع این” به کسی کمک نمی کند ، و انتقادات بیش از حد شدید می تواند به جای کمک به آنها در پیشرفت ، توسعه دهندگان را تحقیر کند.
نحوه رفع آن:
- خاص باشید به جای “این بد است” ، توضیح دهید که چرا: “این عملکرد کارهای زیادی انجام می دهد – آیا می توانیم آن را به قسمت های کوچکتر تقسیم کنیم؟”
- سؤال کنید به جای فرض اینکه مشکلی پیش آمده است ، از توضیحات بپرسید: “آیا دلیلی وجود دارد که ما به جای شنونده رویداد از استفاده در اینجا استفاده کردیم؟”
- از لحن مشترک استفاده کنید. به بررسی کد به عنوان بحث و گفتگو فکر کنید ، نه حملات شخصی. بازخورد فریم به عنوان پیشنهادات ، نه سفارش.
6. بررسی تست ها (یا اصلاً نداشتن)
یک ویژگی جدید بدون تست یک اشکال آینده است که در انتظار اتفاق می افتد. با این حال ، بسیاری از توسعه دهندگان از پوشش آزمون یا بدتر از آن استفاده می کنند ، این واقعیت را نادیده می گیرند که هیچ آزمایشی اضافه نشده است.
نحوه رفع آن:
- بررسی کنید که آیا آزمایش وجود دارد یا خیر. اگر یک ویژگی جدید اضافه شود ، آیا پوشش تست دارد؟ اگر نه ، بپرسید چرا.
- اطمینان حاصل کنید که آزمایشات لبه را پوشش می دهد. آیا تست ها فقط مسیر شاد را بررسی می کنند ، یا آنها همچنین خطاها و موارد لبه را نیز به خود اختصاص می دهند؟
- تست های معنی دار را تشویق کنید. از تست های عکس فوری که فقط تأیید می کنند تغییر نکرده است ، خودداری کنید. در عوض ، روی تست های رفتار محور تمرکز کنید.
7. در نظر گرفتن قابلیت حفظ طولانی مدت
ممکن است یک قطعه کد امروز کار کند ، اما آیا می توان شش ماه از این پس به راحتی به روز شد؟ آیا یک توسعه دهنده جدید که به تیم می پیوندد می فهمد که چه کاری انجام می دهد؟
نحوه رفع آن:
- پیچیدگی غیر ضروری را بررسی کنید. آیا این راه حل پیچیده تر از آن است که باید باشد؟ آیا می توان آن را ساده کرد؟
- به دنبال الگوهای قابل استفاده مجدد باشید. آیا این کد کپی را معرفی می کند که می تواند در یک مؤلفه یا عملکرد قابل استفاده مجدد استخراج شود؟
- اسناد را تشویق کنید. اگر یک قطعه منطق غیر واضح است ، پیشنهاد کنید یک نظر اضافه کنید یا اسناد را به روز کنید.
افکار نهایی
بررسی کد باید در مورد بهبود کد باشد ، نه فقط پیدا کردن نقص. آنها فرصتی برای به اشتراک گذاشتن دانش ، موضوعات بالقوه در اوایل و کمک به کل تیم هستند.
با اجتناب از این اشتباهات رایج ، تمرکز روی آنچه مهم ، بازخورد سازنده و فکر کردن در مورد قابلیت حفظ طولانی مدت ، می توانید بررسی های کد خود را برای همه افراد درگیر مؤثرتر و لذت بخش تر کنید.
