چند عادت بد که به عنوان یک برنامه‌نویس از آن‌ها رنج بردم

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