این که فقط دو خط کد بود، پس چرا دو روز طول کشید؟

چی بدتر از رفع خطاست؟ اینکه مجبور بشیم دوباره همون خطا رو رفع کنیم. ارزش کدهایی که خطاهای اساسی رو رفع می‌کنند بالاست و نباید تعداد خط کد رو معیار قرار بدیم

ارزش کد شما چقدره؟

موقع وبگردی رسیدم به این مقاله که قصد دارم یک ترجمه آزاد و خلاصه ازش رو بنویسم و کمی درباره‌اش صحبت کنیم. موضوع اصلی درباره ارزش کد و دیدگاه‌های اشتباه در مورد این موضوعه.

تو فقط دو خط کد اضافه کردی، چرا دو روز طول کشید؟

ممکنه سوال منطقی به نظر برسه، ولی پیش‌فرض‌های وحشتناکی داره:

  • فرض شده که تعداد خط کد = تلاش صورت گرفته
  • فرض شده که تعداد خط کد = ارزش کسب شده
  • فرض شده که همه خط‌های کد یکسان هستند.

هیچ‌کدام از این فرض‌های بالا درست نیستند.

چرا یک اصلاح که وقتی به تغییرات کد نگاه می‌کنید خیلی ساده به نظر میاد، دو روز طول کشید تا تمام بشه؟

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

چون گزارش مساله مربوط به عملکردیه که من باهاش آشنا نیستم امکانی که مربوط به مشکل گزارش شده است رو به ندرت استفاده کردم یا طوری نبوده که با جزئیات زیاد درگیرش باشم. این یعنی بیشتر زمان می‌گیره که درک کنم چطوری کار می‌کنه و چطوری باید باگش رو برطرف کرد

چون وقت گذاشتم که دلیل اصلی مساله رو پیدا کنم نه فقط علائمش رو ببینم اگر کدی خطا می‌ده می‌تونید خیلی ساده توی یک بلاک try catch قرارش بدین و خطا رو خفه کنین. خطا نباشه، مشکلی هم نیست. درسته؟ متاسفانه برای من نامرئی کردن مشکل به معنی حل کردنش نیست. قورت دادن خطا خیلی راحت ممکنه به اثرات جانبی ناخواسته منجر بشه و من نمی‌خوام با این اثرات ناخواسته در آینده دست و پنجه نرم کنم.

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

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

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

-چون تغییرات رو تست کردم و مطمئن شدم که مشکل رو برای همه مسیرهای کد حل کردم نمی‌خوام یک نفر دیگه تایید کنه که کاری که من انجام دادم درست بوده. نمی‌خوام یک باگ دیگه پیدا بشه و مجبور بشم به این کد برگردم وقتی که از نظر ذهنی دیگه ازش عبور کردم.

چی بدتر از رفع خطاست؟

خلاصه‌ای از مطلب اصلی رو خوندیم. نویسنده در پایان مطلب می‌پرسه چی بدتر از رفع خطاست؟ اینکه مجبور بشیم همین خطا رو دوباره رفع کنیم.

می‌خوام کمی درباره این موضوع صحبت کنیم. نکات مهمی که باید بهشون توجه کنیم این‌هاست:

  • دغدغه زمان نباید باعث بشه خیلی کیفیت اجرا رو پایین بیاریم. در واقع کد محصول فکر ماست و هر چه عمیق‌تر فکر کرده باشیم و بهتر طراحی لازم رو پیاده کنیم، بعداً با دردسر کمتری روبرو می‌شیم. فراموش نکنین که هزینه اصلی نرم‌‌افزار در زمان تولیدش نیست بلکه در زمان توسعه و پشتیبانی و نگهداری از اون نرم‌افزاره
  • مهمه به این توافق با همه ذی‌نفعان پروژه برسیم که تعداد خط کد هیچ شاخصی نیست. تنها چیزی که می‌تونه تا حدی نشون بده میزان بزرگی کدبیس ماست. اما اینکه اگر مثلاً یک نرم‌افزار با x خط کد داریم، نرم‌افزار با 2x خط کد بهتره. لزوماً اینطوری نیست چون توسعه نرم‌افزار اینطور کار نمی‌کنه.
  • فقط دیکته نانوشته غلط نداره. همه ما توی کارمون ایراد داریم. بزرگترین شرکت‌های نرم‌افزاری هم محصولاتی تولید می‌کنند که باگ دارند. نکته اینکه که چطور برای رفع مشکلات برنامه‌ریزی می‌کنیم. فراموش نکنیم که باید قبل از کد جدید، مشکلات موجود رفع بشوند
  • وقتی یک مشکل امنیتی در کد رو حل می‌کنیم صرفنظر از اندازه تغییرات، ارزش بسیار زیادی رو به نرم‌افزار اضافه می‌کنیم. بنابراین وقتی حتی نمی‌شه ارزش رفع دو باگ رو با هم مقایسه کرد چرا چنین کاری رو برای تعداد خط کد به نسبت زمان صرف شده انجام بدیم؟
  • فراموش نکنیم «حرف زدن ساده است» و در حوزه برنامه‌نویسی، کد حرف می‌زنه. بنابراین اگر یک نفر همواره داره با اتلاف وقت صرفاً خودش رو مشغول نشون می‌ده دیر یا زود فهمیده می‌شه و بنابراین این بهانه‌ای برای مدیریت ذره‌بینی (Micromanagement) نیست

شما درباره این موضوع چه فکری می‌کنید؟