همه را بپذیرید، هیچچیز را درک نکنید
فشردن کلید Enter برای پذیرفتن پیشنهادهای کد، تلاش کمتری نسبت به اسکرول کردن از کنار آنها میطلبد. با یک ضربه کلید، کد متعلق به شما میشود. اما سرعت خواندن و درک آن کد هیچ تغییری نکرده است.
شکافی میان سرعت پذیرش کد و سرعت درک آن وجود دارد. این شکاف همان جایی است که اشتباهات رخ میدهند.
بدهی فنی (Technical debt) زمانی دلایل مشخصی داشت. یا ضربالاجلهای فشرده داشتید یا برای سرعت بخشیدن به کار، از مسیر اصلی منحرف میشدید. میتوانستید به دلیل آن اشاره کنید. اما اکنون، در یک سهشنبه آرام، در حال انباشتن بدهی هستید. شش پیشنهاد را پشت سر هم میپذیرید چون خوب به نظر میرسند. کسی شما را تحت فشار قرار نداده، اما کد بدون بررسی باقی میماند.
برایان کرنیگان در سال ۱۹۷۴ گفت که عیبیابی (debugging) دو برابر سختتر از نوشتن یک برنامه است. او درباره کدی صحبت میکرد که انسانها مینویسند. دستکم انسانها کار خودشان را درک میکنند.
امروزه، یک پیشنهاد میتواند از linter عبور کند و حتی تستها را هم پشت سر بگذارد. اما همچنان میتواند بر پایه یک فرض اشتباه باشد. این اتفاق به این دلیل میافتد که افراد، پیشنهاد را به جای «کد»، به عنوان «خروجی» میخوانند. خروجیای که خوب به نظر میرسد، تایید میشود.
اگر یک مدل هم کد و هم تستها را بنویسد، شما در حال نمره دادن به تکالیفی هستید که با پاسخهای خودِ دانشآموز نوشته شده است. این کار به شما نمیگوید که آیا منطق کد درست است یا خیر. به شما نمیگوید که آیا حالات مرزی (edge cases) پوشش داده شدهاند یا نه. وقتی کد در ادیتور خودتان و با سبک نگارش خودتان ظاهر میشود، فراموش کردن این موضوع آسان است.
این موضوع مشکلات واقعی ایجاد میکند:
- کدی را عیبیابی میکنید که هرگز نخواندهاید. وقتی هفتهها بعد مشکلی پیش میآید، از صفر شروع میکنید.
- حالات مرزی (edge cases) با شکست مواجه میشوند. یک پیشنهاد ممکن است مسیر اصلی (happy path) را به خوبی مدیریت کند و شامل بررسی null باشد، اما منطق خاصی که کسبوکار شما نیاز دارد را نادیده بگیرد.
- نمیتوانید از pull requestهای خود دفاع کنید. اگر یک بازبین (reviewer) بپرسد چرا فلان متد را انتخاب کردهاید، پاسخی ندارید. شما تصمیمگیرنده نبودهاید؛ فقط آن را رد نکردهاید.
این ابزارها مفید هستند. آنها به شما در کاوش در پایگاههای کد (codebases) یا برنامهریزی ویژگیهای جدید کمک میکنند. مشکل، طرز برخورد شماست. شما باید با هر پیشنهاد به عنوان چیزی که باید خوانده و دربارهاش تصمیم گرفت برخورد کنید، نه فقط چیزی که به آن نگاهی گذرا میاندازید.
برای کدهای تکراری (boilerplate) یا اسکریپتهای سریع، سرعت اهمیت زیادی ندارد. اما برای منطق کسبوکار یا امنیت، رویکرد شما باید تغییر کند. کد را طوری بخوانید که انگار مسئولیت آن با شماست. چون واقعاً همینطور خواهد بود.
در عوض، این کارها را انجام دهید:
- قبل از درخواست کد، راه حل خود را با مدل در میان بگذارید.
- تغییرات (diff) را طوری بررسی کنید که انگار خودتان آنها را نوشتهاید.
- قبل از پذیرفتن کد، از ابزار بخواهید استدلال خود را توضیح دهد.
- با پیشنهادها مانند کار یک توسعهدهنده تازهکار برخورد کنید. آنها مفید هستند اما حقیقت مطلق نیستند.
- روی خطوطی که شما را غافلگیر میکنند، سرعت خود را کم کنید. غافلگیری یک سیگنال است.
هزینه فشردن یک کلید کاهش یافته است، اما مسئولیت شما نه. سرعت بدون درک، چیزی جز بدهی سریع نیست.
Source: https://dev.to/cloudx/accept-all-understand-none-4dob
Optional learning community: https://t.me/GyaanSetuAi