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

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

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

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

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