نویسنده: زیمون آدامیاک — ما می‌خواهیم کارها را تمام کنیم. این ذات ما است و چیزی است که بابت آن حقوق می‌گیریم. ولی وقتی از یک کار سراغ کار دیگری می‌رویم، گاهی اوقات چیزهای اساسی‌ای را فراموش می‌کنیم: کیفیت کد و رشد ما به عنوان برنامه‌نویس.
میان گناهان زیادی که مرتکب می‌شویم، آن‌هایی که به خاطر عجله رخ می‌دهند از همه غیرمنطقی‌ترند. به همین دلیل، باید هر از چند گاهی دنبال فرصتی باشیم تا کمی سرعت‌مان را کم و نفسی تازه کنیم.
این لیستِ من از مهم‌ترین اشتباهاتی است که مرتکب می‌شویم، وقتی که حس می‌کنیم زمان کافی برای انجام کار به شیوه درستش وجود ندارد.
اشتباه اول: نخواندن کد به اندازه کافی
تا حالا فیلمی دیده‌اید که در آن برنامه‌نویسی برای چندین دقیقه به صفحه نمایش خیره شود و هیچ‌کاری انجام ندهد؟ من هم ندیده‌ام! معمولا آن‌ها چیزی را با سرعت نور تایپ می‌کنند و تمام؛ مشکل حل می‌شود. با کمال تاسف، کار ما به این زیبایی نیست.
ما باید یک عالمه کد بخوانیم و در کنار آن، باید بفهمیم که این کد چه‌کاری انجام می‌دهد و چرا این کار را می‌کند.
کدهای تصادفی از اینترنت
همین نخواندن کد گونه‌های متفاوتی دارد. آخرین باری که دنبال جواب چیزی در اینترنت بودید، کدی را در StackOverflow پیدا کردید و آن را یک‌سره کپی پیست کردید چه زمانی بود؟ برای خود من، احتمالا همین هفته.
به احتمال خیلی زیاد این کد کار هم می‌کند. ولی آیا می‌دانید که این کد چه‌کار می‌کند، چرا این‌کار را انجام می‌دهد و محدودیت‌هایش چیست؟ آیا امن است؟ در قبال الزامات و موارد خاص چگونه عمل می‌کند؟
بعضی وقت‌ها فقط باید کد را پیست کنید و دعا کنید که کار کند. بعضی چیزا برای فهم و زمان من و شما زیادی پیچیده هستند! ولی معمولا در ۱۵ تا ۳۰ دقیقه می‌توانید کد را بفهمید. شما باید اطمینان کافی داشته باشید که کدی را که برای پروژه وارد کرده‌اید بلدید. اگر این‌گونه نباشد، شما امنیت و قابلیت نگهداری پروژه در بلندمدت را به خطر انداخته‌اید.
کدهای پروژه
خواندن کد پروژه‌ی خودتان چه؟ این همان داستان قدیمی است. فرض کنید برای درست‌کردن باگی فراخوانده شوید که با آن آشنا نیستید. خوشبختانه یک حدس دارید و سعی می‌کنید با استناد به آن بلافاصله مشکل را حل کنید. این شیوه کار کرد؛ پس تغییرات را اعمال می‌کنید و سر کار خودتان می‌روید.
این یک اشتباه بزرگ است. اگر با کد پروژه آشنا نیستید و تست‌ها را ندارید، احتمال این که این کارِ شما چیزی را خراب نکند و همه‌ی موارد را مدیریت کند بسیار کم است.
برای درست‌کردن چیزی باید با آن آشنا باشید. این‌که با تغییرات مختلف با کد سر و کله بزنید دردی را دوا نمی‌کند. ممکن است یکی دو بار هم شانس بیاورید ولی نهایتا دیر یا زود یک فاجعه به بار می‌آورید.
کد کتابخانه‌ها
چند کتابخانه را در شروع پروژه به صورت پیش‌فرض اضافه می‌کنید؟ مطمئنید که به همه‌ی آن‌ها نیاز دارید و می‌دانید چگونه پیاده‌سازی شده‌اند؟
نمی‌خواهم بگویم که نباید از کتابخانه‌ها و فریم‌ورک‌ها استفاده کنید. اتفاقا باید از هر کدِ امتحان پس داده و تایید شده در هرجایی که می‌شود استفاده کرد. اختراع دوباره‌ی چرخ یکی از مشکلات رایج است و می‌تواند بیشتر از سود، ضرر برساند.
چیزی که می‌خواهم بگویم این است که باید ابزاری را که استفاده می‌کنیم بشناسیم. کتابخانه‌های محبوب معمولا از لحاظ نرم‌افزاری بی‌نظیرند و با مطالعه‌ی کد آن‌ها می‌تونید بسیار بیاموزید. این کار یا باعث می‌شود که توسعه‌دهنده‌ی ماهرتری شوید یا متوجه شوید که اصلا نیازی به این کتابخانه ندارید. در هر صورت، این بازی برای شما برد-برد است.
نیازی به تحلیل همه‌ی کتابخانه‌هایی که استفاده می‌کنید نیست؛ ولی وقتی از چیزی بارها استفاده می‌کنید، خوب است نگاهی به چگونگی کار کردن آن بیندازید.
خواندن کدهای خوب به شما کمک می‌کند تا توسعه‌دهنده بهتری شوید و محصولات‌تان را بهتر بشناسید. ممکن است فکر کنید که زمان کافی را برای این کار ندارید، ولی این اشتباه است. آشنایی با کد محصول‌تان باعث می‌شود تا سرعت کدزنی‌تان بالا برود و خواندن کدهای دیگر به رشد شما به عنوان یک توسعه‌دهنده کمک می‌کند. پس در بلندمدت، کدخوانی باعث صرفه‌جویی در زمان می‌شود نه هدر دادن آن.
اشتباه دوم: ریفرکتور نکردن
می‌خواهید یک فیچر را پیاده‌سازی کنید و عجله هم دارید. خوشبختانه شما ایده‌ای دارید تا این ویژگی را خیلی سریع بسازید. پس به سرعت یک کد رمزآلود می‌نویسید و همه‌چیز هم به نظر درست کار می‌کند. مشکل حل شد، برویم سراغ بعدی.
اشتباه!
وقتی بدون توجه به گزینه‌های مختلف شروع به کدزنی می‌کنید و اولین راه حل را در نظر می‌گیرید، کد شما ناقص است. ممکن است ناکارآمد، ناخوانا و غیرقابل نگهداری باشد. در بدترین حالت، ممکن است هر سه‌تای این‌ها باشد و حتی مشکل را هم حل نکند.
این که کارتان را سریع تمام کنید، وسوسه‌انگیز است. حتی ممکن است باعث افتخار شما شود. ولی یکی از نشانه‌های یک توسعه‌دهنده‌ی قوی، ساختن کدهای با کیفیت و ارتقا کدهای پروژه است.
پروژه‌ای که در آن همه مشغول ساختن فیچرهای جدید به سریع‌ترین شکل ممکن هستند، محکوم به یک خطای بزرگ فنی است. در طول زمان، کمتر و کمتر قابل نگهداری می‌شود و بهره‌وری توسعه‌دهندگان از دست می‌رود. این وظیفه همه توسعه‌دهنده‌های یک تیم است که کد را بهبود ببخشند.
پس مطمئن شوید که برای پیاده‌سازی یک فیچر به اندازه کافی وقت بگذارید. عوارض جانبی کارتان و چگونگی تناسب آن با ساختار کلی برنامه را در نظر بگیرید. شما باید همیشه کد پروژه را در شرایطی بهتر از قبل تحویل بدهید. این کار نه‌تنها سرعت توسعه را در بلندمدت افزایش می‌دهد، بلکه شما را هم برنامه‌نویس ماهرتری می‌کند.
اشتباه سوم: تست نکردن
چند وقت یک‌بار یک فیچر را بدون آماده‌کردنِ تست برای اطمینان از درست بودن آن می‌نویسید؟ متاسفانه این یک خطای رایج است؛ به خصوص در پروژه‌هایی که باید سریع باشید. همه فکر می‌کنند که تست‌ها وقت ارزشمند توسعه‌دهندگان را می‌گیرند، پس وقت دیگری هم می‌توان سراغ آن رفت، گاهی هیچ‌وقت!
در واقع، تست‌کردن برای هر پروژه با طول عمر زیاد یا قابلیت رشد بالا حیاتی است. مهم نیست کدتان چقدر خوب باشد. یک نفر باید آن را تغییر دهد. و وقتی این کار را بکند، باید برایشان این اطمینان وجود داشته باشد که کد هنوز کار می‌کند.
بدتر از آن، یک نفر می‌تواند بخش‌های مختلف کد را تغییر دهد که احتمالا فیچر شما را خراب می‌کند. بدون یک تست، شما هرگز متوجه این نمی‌شوید.
پس ممکن است تصور کنید که تست نوشتن اتلاف وقت و هزینه است ولی دقیقا برعکس. بعدا در آینده خودتان یا دیگر توسعه‌‌دهنده‌ها برای نوشتن این تست‌های مفید از شما ممنون خواهند بود!
ترجمه از:
“Three Mistakes Developers Make When They’re in a Hurry” by Szymon Adamiak
