وقتی سخت مشغول کد نوشتن هستیم، گاهی دچار اشتباهاتی می‌شویم. بیشتر اوقات پیش‌نیازهایی که ما را محدود می‌کنند و ملزم به رعایت آن‌ها هستیم یا نیاز فوری و کمبود وقت را مقصر می‌دانیم.
پس از مدت‌ها فعالیت در این حرفه و بعد از این که مرتکب خطاهای بسیاری شدم، متوجه شدم اگر لازم باشد مقصری اعلام شود، آن مقصر تنها خود من و تمرین‌های نادرستی که در طول فعالیتم داشتم، هستند.
زمانی که مشغول کد زدن می‌شویم گاهی تمایل داریم که کدمان را شبیه اسکریپت بنویسیم. به خوبی می‌دانیم که توابع باید تنها یک کار را انجام دهند و آن کار را به بهترین شکل ممکن انجام دهند.
برنامه‌نویسان تازه‌کار به خاطر تجربه کمی که دارند، توابع و کلاس‌های طولانی‌ای می‌نویسند. از طرفی برنامه‌نویسان باتجربه، به خاطر مهارت بالایی که دارند و راحت‌تر بودن نوشتن یک تابع طولانی به جای چند تابع، مرتکب این خطا می‌شوند. من هم این خطا را زمانی که تازه‌کار بودم انجام می‌دادم و هنوز هم گاهی دچار این خطا می‌شوم.
برای حل این مشکل من مرحله‌ای برای بازبینی کد خودم به تمرین‌های برنامه‌نویسی‌ام اضافه کردم. هنگام بازبینی، هر زمان چنین تابع یا کلاس طولانی‌ای می‌بینم سریعاً آن را به توابع و کلاس‌های کوچک‌تر می‌شکنم.
همه ما گاهی از این جمله‌ها استفاده کرده‌ایم یا آن‌ها را از زبان دیگران شنیده‌ایم:
روی کامپیوتر من درست کار می‌کنه.
یا
کد من درسته. مشکل از قسمت‌های دیگست.
جملاتی مثل این، اطمینان بیش از حد برنامه‌نویس را نشان می‌دهد. من از همین اطمینان زیاد، سال‌ها رنج بردم.
شک نکردن به کدی که نوشته‌اید اختلاف را بین اعضای تیم بیشتر می‌کند. هم‌چنین باعث می‌شود زمان و تلاش لازم برای حل مشکل بیشتر شود.
پس از سال‌ها تلاش و الهام گرفتن از برخی از همکارانم خوشبختانه متوجه این عبارت "همیشه به کد خودت شک داشته باش" شدم. حالا زمانی که کسی به من می‌گوید که ممکن است اشکالی در کد من باشد واکنش من این است:
ممکنه، بگذار کدم رو چک کنم.
من مزایای استفاده از توسعه آزمون‌محور (TDD) را مشاهده کرده‌ام. TDD کمک می‌کند تا باگ‌ها را زودتر در چرخه توسعه پیدا کنید و باعث می‌شود نسبت به آنچه نوشته‌اید اطمینان بیش‌تری پیدا کنید. هم‌چنین باعث صرفه‌‌جویی در مصرف زمان و پول می‌شود.
من همواره تمایل داشتم تا یک پروژه‌ی جدید را با استفاده از TDD شروع کنم. اما معمولا به طور تدریجی از تست نوشتن دست می‌کشیدم و ردپای TDD در پروژه از بین می‌رفت.
علتش این است که زمانی که مشغول توسعه قابلیتی هستم که نیاز فوری به آن دارم، در ذهنم همواره تمایل دارم که تست‌های آن بخش را رد کنم، حتی اگر نوشتن تست برای آن قابلیت زمان زیادی از من نگیرد.
برای مقابله با این مشکل، قانونی ساختم که هیچ کدی (حتی برای بازبینی) نباید بدون تست بماند. این قانون به من و تیم کمک کرده تا TDD در طول پروژه در جریان بماند.
من دیگر این مشکل را ندارم. همواره از قانون DRY (خودت را تکرار نکن) پیروی می‌کنم. زمانی بود که من هم خیلی در برابر قانون DRY انعطاف نداشتم و تیکه‌کدهای تکراری‌ای در سورس‌کدهایم وجود داشت.
این اتفاق معمولاً زمانی رخ می‌دهد که شما برای نوشتن کد به اندازه‌ی کافی تلاش نمی‌کنید و به جای آن از راه‌های میانبر ساده‌تر استفاده می‌کنید. من هم چندین بار برای کوتاه کردن فرایند تست تصمیم گرفتم که از قانون DRY پیروی نکنم زیرا برای پیروی از آن لازم بود در برخی از کدهای قبلی تغییراتی را ایجاد کنم.
اما حالا هیچ تردیدی در مورد این قانون ندارم. همواره مطمئن می‌شوم که هیچ‌گاه کدم را تکرار نمی‌کنم.
زمانی که غرق در کدنویسی هستیم، معمولا فراموش می‌کنیم که برای کدمان کامنت بنویسیم. کامنت‌ها هنگام بازبینی کد به ما کمک می‌کنند و باعث می‌شوند زمان کم‌تری را برای فهم کد صرف کنیم. من همچنان هم به اندازه‌ی کافی از کامنت استفاده نمی‌کنم.
من طرفدار استانداردهایی که سازمان‌های مختلف برای نوشتن کامنت دارند نیستم. هر زمان که لازم باشد از کامنت استفاده می‌کنم.
من معمولا زمانی کامنت می‌نویسم که منطقِ به کار رفته پیچیده باشد یا وقتی کدی که نوشته‌ام بر پایه چند فرض ثابت باشد. اما برای توابع و کلاس‌هایی که با دیدنشان می‌توان کاربردشان را متوجه شد کامنت نمی‌نویسم.
طبق آنچه بارها و بارها دیده‌ام، بسیاری از تیم‌ها و مدیران، اولویت دادن به باگ‌ها را کاری مشکل می‌دانند. مهم‌تر از آن، حتی زمان زیادی را برای مدیریت باگ‌ها صرف می‌کنند.
من برای استفاده نکردن از Bug tracker و عدم تنظیم صحیح اولویت‌ها در گذشته مقصرم.
گاهی اوقات به شدتِ تاثیر یک باگ، بیشتر از اولویت آن اهمیت داده می‌شود. در صورتی که باگ ممکن است بسیار مشکل‌زا باشد اما با توجه به شرایط فعلی رفع آن در اولویت نباشد.
باگ‌های جدید پیش‌آمده به همراه باگ‌های تلنبارشده قبلی لازم است بر اساس وضعیت فعلی کسب و کار و لزومات آن در بازه‌های زمانی معقول اولویت‌بندی شوند.
مشخصاً مستندسازی کاری حوصله‌سربر است. بیشتر ما دوست نداریم ایده‌ها و طراحی‌هایمان را مستند کنیم. در واقع مستندسازی را برای پرداختن به کارهای جذاب‌تر رد می‌کنیم.
اما بدون مستندسازی اگر شخصی بخواهد به کدی که نوشته‌ایم نگاهی بیاندازد، احتمالاً در کد سردرگم می‌شود.
در صورتی که از کامنت‌نویسی به طور مناسب استفاده شده باشد، می‌توان با استفاده از برخی ابزارهای موجود، از کامنت‌ها برای تولید مستندات استفاده کرد. بسیار خوب است که همواره ایده‌ها و طراحی‌های‌تان را مستند کنید تا در آینده به عنوان مرجع از آن‌ها استفاده شود. این کار به دیگران کمک می‌کند تا طراحی شما را به خوبی متوجه شوند و به شما کمک می‌کند تا به کمک نظرات و پیشنهادهایی دیگران می‌دهند، پروژه خود را بهبود بخشید.
همه ما برخی عادت‌ها و شیوه‌های غلطی داریم. من تعدادی از آن‌ها که برای مدت زیادی از انجامشان رنج می‌بردم را نام بردم. اما همچنان هم با هوشیاری تلاش می‌کنم که این عادت‌های بد را پیدا و آن‌ها را متوقف کنم.
شما چه عادت‌های بدی در برنامه‌نویسی دارید؟ لطفا در کامنت‌ها بنویسید.
متنی که خواندید ترجمه این مقاله است
ما را در تلگرام دنبال کنید
