اشتباهاتی که توسعهدهندگان جونیور مرتکب میشوند
تحویل کدی که کار میکند، حداقلِ کار است، نه هدف نهایی.
یک بار یک pull request را بررسی کردم که درک کردنش ۴۵ دقیقه طول کشید. منطق کد درست بود. تستها هم پاس شدند. اما کد طوری نوشته شده بود که انگار فقط خود نویسنده قرار است آن را بخواند.
وقتی بازخورد دادم، توسعهدهنده گفت: «اما که کار میکند!»
حق با او بود. کد کار میکرد. و مشکل دقیقاً همین بود.
توسعهدهندگان جونیور اغلب روی مهارتهای فنی تمرکز میکنند، اما شکافهای واقعی معمولاً در عادتها و طرز فکر آنهاست.
در اینجا به اشتباهات ظریفی اشاره میکنیم که سرعت شما را کاهش میدهند:
نوشتن برای خودتان به جای دیگران کد بسیار بیشتر از اینکه نوشته شود، خوانده میشود. تابعی که امروز مینویسید، ممکن است طی دو سال توسط سه نفر مختلف تغییر داده شود. اگر یک غریبه نتواند کد شما را در ۳۰ ثانیه درک کند، شکست خوردهاید.
کپی کردن کد بدون درک آن استفاده از Stack Overflow مشکلی ندارد، اما کپی کردن یک الگوی regex بدون دانستن نحوه عملکرد آن خطرناک است. شما یک «جعبه سیاه» در پایگاه کد خود ایجاد میکنید و وقتی خراب شود، نمیتوانید آن را دیباگ کنید.
اضافه کردن پیچیدگیهای غیرضروری جونیورها اغلب پیچیدگی را با مهارت یکی میدانند. آنها الگوهای طراحی (design patterns) را روی کارهای ساده اعمال میکنند. انتزاع (abstraction) غیرضروری، دیباگ کردن و تغییر کد را سختتر میکند. فقط زمانی از انتزاع استفاده کنید که نبودِ آن را به صورت دردناک حس کنید.
نادیده گرفتن پیامهای خطا پیامهای خطا، مستندات رایگان هستند. به محض دیدن یک stack trace، بلافاصله به سراغ گوگل نروید. کل پیام را بخوانید. پیام معمولاً دقیقاً میگوید کدام خط با خطا مواجه شده و چرا.
درخواست کمک خیلی زود یا خیلی دیر سه ساعت را صرف یک مشکل ۱۰ دقیقهای نکنید؛ این کار ناکارآمد است. اما با یک اسکرینشات بدون هیچ توضیحی، به یک توسعهدهنده ارشد (senior) پیام ندهید. از قانون ۲۰ دقیقه استفاده کنید: ۲۰ دقیقه برای حل مشکل تلاش کنید. آنچه را که امتحان کردهاید مستند کنید، سپس با همراه داشتن آن مستندات، درخواست کمک کنید.
بازسازی آنچه از قبل وجود دارد قبل از اینکه یک ابزار کاربردی (utility) جدید بنویسید، در پایگاه کد جستجو کنید. تیم شما احتمالاً قبلاً آن مشکل را حل کرده است.
پیامهای کامیت (commit) ضعیف پیامی مثل "fix bug" هیچ چیزی به تیم شما نمیگوید. توضیح دهید چه چیزی تغییر کرده و چرا. با تاریخچه Git مانند یک مستندات رفتار کنید.
برخورد با نیازمندیها به عنوان قانون مطلق نیازمندیها اغلب موارد خاص (edge cases) را نادیده میگیرند. فقط آنچه به شما گفته شده را پیادهسازی نکنید؛ بپرسید اگر اوضاع اشتباه پیش رفت، چه اتفاقی میافتد.
متوقف شدن در دکمه "Merged" مسئولیت شما با ادغام (merge) شدن PR تمام نمیشود. روند ویژگی (feature) خود را تا مرحله QA دنبال کنید. آن را در محیط production زیر نظر بگیرید و گزارشهای خطا را بخوانید.
بزرگترین شکاف، مسئولیتپذیری است. توسعهدهندگان ارشد فقط کد نمینویسند؛ آنها مشکلات را بدون ایجاد مشکلات جدید حل میکنند.
بهینهسازی برای «انجام شدن» را متوقف کنید. بهینهسازی برای «خوب بودن» را شروع کنید.