مخصوص اعضای ویژه 
شکستن عادت های بد دشوار است و حتی سخت تر این است که ندانید کدام کار باعث تحلیل کار شما می شود و اگر بدانید و به آن اهمیت ندهید از همه بدتر است. اما شما درحال خواندن این مقاله هستید، اینطور نیست؟
به عنوان یک برنامه نویس بسیاری از کار های غلط را نه تنها در حوزه ی کدزنی بلکه در کارتیمی نیز دیده ام. خود من هم بسیاری از این کار های اشتباه را انجام داده ام. در این مقاله من 35 مورد از این عادت های برنامه نویسی غلط را در 4 دسته ی: سازماندهی کد، کار گروهی، نوشتن کد و تست و نگهداری، بررسی می کنم.
سازماندهی کد
1.گفتن اینکه "بعدا درست می کنم"
عادت به تعویق انداختن تعمیر کد ها از مشکل در اولویت ها نیست. سازماندهی موضوعات پی در پی ممکن است یک پروسه را ایجاد کند، اما شما نیاز به راهی برای پیگیری موضوعات کوچک تری که به وجود می آید، دارید. اضافه کردن کامنت های "TODO" راهی سریع برای اطمینان از اینکه چیزی را از دست نمی دهید، می باشد.
2. پا فشاری روی یک راه حل یک خطی
حساسیت روی نوشتن کد های کارآمد و قطعه کدهای زیبا، یک ویژگی مشترک بین برنامه نویسان است. این کار مانند حل پازل است و مانند پیدا کردن یک تابع ترکیبی و عبارات منظم است که 20 خط کد را به 2 یا 3 خط تبدیل می کند. متاسفانه این کار همیشه منجر به کدهای خوانا نمی شود که این موضوع نتیجه ی مهم تری است. ابتدا کد خود را دسترس پذیر کنید سپس آن را هوشمندانه کنید.
3. بهینه سازی های بیهوده
یکی از موارد دیگری که بیهوده تلاش خود را صرف آن می کنیم، بهینه سازی است. کاهش اندازه ی سایز به اندازه ی چند بایت عالی به نظر می رسد اما آیا gzipاین کار را انجام نمی دهد؟ و آیا request ها مهم تر نیستند؟ آدرس ها را در انتهای پروژه بهینه سازی کنید زیرا اغلب پیش نیازها تغییر خواهد کرد و زمان شما هدر می رود.
4. متقاعد کردن خود با این موضوع که استایل دهی خیلی مهم نیست
چیزی که طی سالیان های زیاد از بررسی کدهای دیگران یاد گرفتم روند استایل دهی به کدهایشان می باشد که اکثر توسعه دهندگان مایل هستند که آن را به تاخیر بیندازند. برای کدنویس های بی تجربه با گذر زمان متوجه خواهند شد که استایل داشتن کد میتواند تاثیر خوبی داشته باشد. اما زمانی که کد کیفیت خود را از دست می دهد یک مشکل کوچک، تمام پروژه را با مشکل روبرو می کند. درباره ی بهترین روش ها هرچند اگر بی اهمیت به نظر برسند سخت گیرانه عمل کنید. بررسی کد و ابزار های linting را تنظیم کنید تا فرصت داشته باشید درباره ی موضوعات مهم تر فکر کنید.
5.لاپوشانی کردن
با گرفتن یا نادیده گرفتن exception ها یا با استفاده از کتابخانه هایی که خطاها را گزارش نمی دهند (مانند jQuery) و راه های بسیار دیگر می توانید لاپوشانی کنید اما زمانی که رفع یکی از این ارور ها از اولویت ها باشد، این کار بسیار زمان بر خواهد بود زیرا شما هیچ سرنخی برای شروع ندارید. یک راه ساده برای انجام این کار درنظر گرفتن ارور های نادیده گرفته شده است که می توانید درباره ی این موضوع بعدا مطالعه کنید.
6.استفاده از نام هایی که هیچ اطلاعاتی نمی دهند
نام گذاری سخت است اما یک راه آسان برای اطمینان حاصل کردن از اینکه نام متغیرها و توابع حداقل از یک کیفیت مناسب برخوردار هستند، وجود دارد. بنابراین از آنجایی که نام گذاری ها اطلاعاتی که مابقی قسمت های کد منتقل نمی کند را می رساند بقیه ی توسعه دهندگان راحت تر می توانند کد را بخوانند. دلیل اینکه نام گذاری بسیار مهم است این است که نام ها یک ایده ی کلی از آنچه کد انجام می دهد را در اختیار می گذارند. عمیق شدن در محاسبات برای اینکه متوجه شوید کد چه کاری را انجام می دهد بسیار زمان گیر است اما نام گذاری خوب کاری را که تابع انجام می دهد را در چند ثانیه معرفی می کند.
7. نادیده گرفتن روش های خوب اثبات شده
بررسی های کد، توسعه ی حاصل از تست، تضمین کیفیت، خودکارسازی توسعه و چندین موارد دیگر، از روش هایی هستند که ارزش آن ها در پروژه های بی شماری اثبات شده است به همین دلیل است که توسعه دهندگان بطور مداوم از این روش ها استفاده می کنند. یک مرجع خوب برای این روش ها کتاب ساخت نرم افزار: چه چیزی واقعا کار می کند و چرا به این کار معتقد هستیم، می باشد. زمان بگذارید و یادبگیرید که چگونه این کار ها را به درستی انجام دهید با این کار ها پروسه ی نرم افزار در همه ی پروژه های شما به راه هایی که شما را شگفت زده خواهد کرد، بهبود خواهد یافت.
کارگروهی
8. زود رها کردن طرح ها
یک راه مطمئن برای این که سیستم شما نفوذناپذیر باشد این است که فقط یک طرح استفاده نکنیم. شما همیشه می توانید بگویید که هرگاه کدشما مورد نقد قرار گرفت یعنی طرح شما کامل نیست اما داشتن ماژول های نیمه کاره شما را راهنمایی می کند تا آن ها را کامل کنید. این نوع از تکمیل سازی ها، زمانی که قوانین پروژه تغییر می کند و مدیر پروژه ی جدید تصمیم می گیرد که روشی خاص ، از معماری مهم تر است.
9.پافشاری روی طرحی که شانس کمی برای کار دارد
درست همانطور که رها کردن کار ها ممکن است مشکل ایجاد کند پافشاری کردن روی طرح هایی که کار نمی کنند هم باعث مشکل می شود. به همین دلیل است که باید ایده های خود را با تیم خود به اشتراک بگذارید تا از بازخورد ها و توصیه های آن ها استفاده کنید. گاهی یک دیدگاه متفاوت می تواند همه چیز را تغییر دهد.
10.همیشه برای خود کار کردن
شما باید تلاش کنید تا پروسه و ایده های خود را با تیم درمیان بگذارید. گاهی شما فکر می کنید که کاری را به روش درست درحال انجام دادن هستید اما درحقیقت این گونه نیست بنابراین ارتباط پیوسته بسیار ارزشمند است. زمانی که شما با دیگران کار می کنید برای آن ها نیز سودمند است. کارها معمولا با بحث درباره ی ایده ها و آموزش افرادی که کم تجربه تر هستند و ممکن است درکار ها گیر کنند، بهبود می یابد.
11.اجتناب از نوشتن کدهای بد
در زندگی همه ی توسعه دهندگان زمانی پیش می آید که مهلت پایانی پروژه آن ها را وادار به نوشتن کد های بد کرده است که کاملا طبیعی است. شما تلاش خودتان را می کنید که مشتری یا مدیر را درباره ی عواقب کار آگاه کنید. اما آن ها روی زمان پروژه پافشاری میکنند، بنابراین اکنون زمان کدنویسی است یا احتمالا با یک باگ ضروری روبرو می شوید که نمی توانید صبر کنید تا با یک solution تمیز سراغ آن بروید. به همین دلیل است که شما باید به عنوان یک برنامه نویس، همه کاره باشید تا بتوانید همانطور که کد های تمیز می نویسید سریعا کد های ضعیف نیز بنویسید. خوشبختانه شما می توانید کد را بعدا بازبینی کنید و همان اصول تکنیکی را اجرا کنید.
12.سرزنش دیگران
هیچ شکی نیست که غرور یک ویژگی عادی بین توسعه دهندگان و دیگر افراد تکنیکی است. مسئولیت پذیری برای خطا های خود ویژگی است که باعث درخشش شما بین همکارانتان می شود. از اعتراف به این که خطایی مرتکب شده اید نترسید. زمانی که با این قضیه کنار بیایید می توانید آزادانه روی اینکه چرا مرتکب آن خطا شدید و چگونه می توانید از آن اجتناب کنید تمرکز کنید و از آن بیاموزید. اگر شما از قبول اشتباهات خود سرباز بزنید، یادگیری غیر ممکن می شود.
13. به اشتراک نگذاشتن چیز هایی که یادگرفته اید با تیم خود
ارزش شما به عنوان یک توسعه دهنده فقط به کدی که می نویسید نیست بلکه به چیزی که زمان نوشتن یاد می گیرید نیز می باشد. تجربیات خود را به اشتراک بگذارید، نظرات خود را درباره ی آن به اشتراک بگذارید، اجازه دهید تا بقیه بدانند که چرا چیز ها به این گونه هستند و به آن ها کمک کنید تا چیز های جدید درباره ی پروژه و پیچیدگی های آن یاد بگیرند.
14. کند بودن در ارائه فییدبک به مدیران/ مشتریان
یکی از ارزشمند ترین ویژگی های شخصیتی یک صاحب پیشه، متکی بر این است که به دیگران این اطمینان را بدهند که آن ها نیز در کار به اندازه ی ممکن سهیم بوده اند. این دلیلی است که مدیران می توانند صفحات گسترده را پر کنند.این کار به سود خود شما نیز می باشد: زیرا ناامنی ها و خطرات در زمان حیات و آینده ی پروژه ی شما کاهش می یابد.
15.استفاده ی کافی نکردن از گوگل
بهترین راه برای حل سریع یک مساله ی پیچیده، جستجو کردن در گوگل است. اگر نسبت به چیزی شک دارید حتما آن را در گوگل جستجو کنید. بجای این کار می توانید مهندس کناردستی خود را اذیت کنید اما در عوض به ندرت پیش می آید که کسی بتواند پاسخی به دقیقی Stack Overflow به شما بدهد، لازم به گفتن نیست که پرسیدن از دیگران باعث قطع کردن کار آن ها نیز می شود.
16.ارزش دادن بیش از حد به استایل
همیشه سعی کنید با محیط کاری تیم تان خود را هماهنگ کنید. بطور ایده آل، هرکس در تیم شما تحت همان شرایط کار می کند و از یک روش برای کدنویسی استفاده کند. انجام کارها به روش خودتان، برای خودتان ممکن است جذاب باشد اما برای همکارانتان همان روش کدنویسی جذاب نباشد، و اگر روش شما غیرمعمول باشد، برای توسعه دهنده ی بعدی، کار روی چیزی که شما ساخته اید، دشوار خواهد بود.
17.داشتن یک پیوست شخصی در کد
وقتی کسی در کد شما کامنت می گذارد، آن را شخصی نکنید. کد شما باید واضح باشد یعنی باید قادر باشید که توضیح دهید چرا کد را به آن صورت نوشته اید. اگر نیاز به بهبود بود، به معنی تصحیح کد شماست و به خود شما مربوط نمی شود.
نوشتن کد
18.ندانستن نحوه ی بهینه سازی
یک استراتژی بهینه سازی درست ، نیاز به تجربه دارد. برای دستیابی به یک استراتژی خوب نیاز به تحقیق،آنالیز و دانستن این که هر سیستم در یک پروسه شامل می شود، دارد. خودتان را راجع به این موارد آگاه کنید. درباره ی پی الگوریتم های پیچیدگی، ارزیابی کوئری های پایگاه داده، پروتکل ها و چگونگی اندازه گیری عملکرد سیستم به صورت کل بیاموزید.
19.استفاده از ابزارهای غلط برای کار
شما می توانید به داشتن اطلاعات محدودی بسنده کنید اما دلیلی که باعث می شود یادگیری را ادامه دهید این است که هر مشکل جدیدی که پیش می آید، محتوا های مختلفی دارد و به ابزار های مختلفی نیاز دارد. نسبت به زبان ها و کتابخانه های جدید پذیرا باشید و نسبت به چیزی که هم اکنون بلد هستید پافشاری نکنید.
20. مسلط نبودن روی ابزارها و IDE های خودتان
هر کلید ترکیبی، کلید های میانبر یا پارامتر هایی که زمان استفاده از ابزار ها یاد می گیرید، یک اثر مثبت روی سرعت کدزنی شما دارد که متوجه آن می شوید. استفاده از کلید های ترکیبی فقط باعث صرفه جویی چند ثانیه ای از کار شما نمی شود بلکه تعویض محتوا را کاهش می دهد. هرچه زمان بیشتری را روی کار های کوچک صرف کنید، زمان کمتری دردسترس دارید که فکر کنید چرا یک کد را نوشته اید و چه چیزی بعد از آن اتفاق خواهد افتاد. تسلط بر روی کلید های میانبر ذهن شما را آزاد می کند.
21. نادیده گرفتن پیام های خطا
فرض نکنید که بدون خواندن پیغام خطا می دانید که اشکال کدشما کجاست یا اینکه به سرعت متوجه آن خواهید شد. همیشه داشتن اطلاعات بیشتر درباره ی مشکل بهتر است و زمانی که برای جمع آوری اطلاعات صرف می کنید درطولانی مدت، ذخیره خواهد شد.
22. ابزار های توسعه ی خود را به صورت تخیلی فرض کردن
گاهی ویرایشگر یا ابزار خط دستور موردنظر شما، بهترین ابزار برای کاری که دردست دارید نیست. Visual Studio برای نوشتن IDE ها عالی است، Sublime برای زبان های پویا عالی است، Eclipse برای جاوا عالی است و غیره. ممکن است شما به vim یا emacs علاقه داشته باشید اما این به این معنی نیست که این ابزار ها برای هرکاری مناسب هستند.
23. ارزش های هاردکدینگ به جای قابل تنظیم کردن
همیشه به تغییراتی که ممکن است پیش بیاید و اینکه چگونه با آن ها مواجه شوید فکر کنید. بدهی های تکنیکی، اگر قطعات متحرک را از باقی کار جدانکنید به سرعت رشد خواهد کرد. درصورت لزوم از ثابت ها و فایل های پیکربندی استفاده کنید که قابلیت تنظیم کردن داشته باشد.
24.تعویض دائم روش ها
کد هایی که به آن ها نیاز ندارید را ننویسید. ممکن است شخص دیگری به اندازه ی کافی زمان روی مشکلی که شما هم اکنون دارید صرف کرده باشد و یک راه حل بهتر داشته باشد که شما بتوانید از آن استفاده کنید. خودتان را از روبرو شدن با برخی مشکلات حفظ کنید.
25.copy/past کورکورانه ی کد
قبل از اینکه از کد استفاده کنید آن را کامل متوجه شوید. گاهی شما بایک نگاه گذرا روی کد، کاری که انجام می دهد را سریعا متوجه می شوید و گاهی هم زمانی که کد را به طور دقیق مطالعه کنید بیشتر یاد خواهید گرفت.
26. وقت نگذاشتن روی اینکه چیزها واقعا چگونه کار می کنند
همیشه شانس اینکه چگونه کد ها واقعا کار می کنند را دریابید و درباره ی لایه های زیرین آن مطالعه کنید. ممکن است الان با مطالعه نکردن درباره ی این موضوع زمان خود را ذخیره کنید اما آنچه شما در یک پروژه یاد می گیرید در طولانی مدت از آنچه که انجام می دهید مهم تر خواهد بود.
27. اعتماد به نفس بیش از حد روی کد خودتان
اینکه فکر کنید چون شما کدی را نوشته اید باید عالی باشد خطرناک است. هرچه شما روی موارد جدید کار کنید و تجربه به دست بیاورید، بیشتر یاد خواهید گرفت بنابراین هرازگاهی روی کد های قدیمی خودتان نگاهی بکنید و ببینید که چگونه پیشرفت کرده اید.
28. فکر نکردن درباره ی تعادل بین طراحی، solution یا کتابخانه
هر محصول نقاط مثبت خود را دارد که فقط با استفاده و آنالیز کردن آن متوجه آن ها خواهید شد. مشاهده ی مثال های محدود از استفاده های یک کتابخانه شما را روی آن کتابخانه مسلط نخواهد کرد البته به این معنی هم نیست که برای همه ی راه حل هایی که در پروژه ی شما پیش خواهد آمد مناسب است. درباره ی هرچیزی که استفاده می کنید نگاهی انتقادی داشته باشید.
29. کمک نگرفتن در زمانی که نیاز دارید
داشتن یک حلقه فییدبک همیشه برای شما کمتر سخت خواهد بود. درخواست کمک کردن به معنی این نیست که شما مناسب این کار نیستید. دیگران تلاش شما را خواهند دید و ندانستن را به عنوان مرحله ای از یادگیری میبینند و این یک ویژگی بسیار خوب است.
تست و نگهداری
30. نوشتن تست هایی که می دانید درست هستند
نوشتن تست هایی که می دانید درست هستند لازم است زیرا باعث بازسازی و مدیریت پروژه به صورت امن تر می شود. از سوی دیگر شما باید تست هایی بنویسید که می دانید به جواب درست ختم نمی شود. این تست ها نیاز هستند زیرا باعث می شود پروژه به سمت جلو حرکت کند و مشکلات را حل کنید.
31. صرف نظر کردن از تست عملکرد برای موارد ضروری
بین روند توسعه ی پروژه یک تنظیم تست عملکرد اتوماتیک را آماده کنید. به این ترتیب می توانید اطمینان حاصل کنید مشکلاتی که به عملکرد مربوط می شود را می توانید به سرعت حل کنید.
32. بررسی نکردن این که ساخته ی شما کار می کند یا نه
به ندرت پیش می آید که build شما با موفقیت انجام شود اما واقعا کار نکند اما به هرحال ممکن است پیش بیاید و برطرف کردن آن نیز دشوار است و زمان زیادی را باید برای این کار صرف کنید. بررسی سریع هر build یک عادت مهم است که باید داشته باشید.
33. به تاخیر انداختن تغییرات بزرگ یا رها کردن پس از یک تغییر بزرگ
اینجاست که اعتماد به نفس زیاد ممکن است به شما آسیب برساند و تا زمانی که متوجه شوید چرا این کار را نباید انجام دهید چندبار شکست بخورید بنابراین توصیه ی من را به خاطر داشته باشید که همیشه از اینکه زمانی که پروژه ی شما با مشکل روبرو شد دردسترس خواهید بود، اطمینان حاصل کنید.
34.منکر شدن کدی که خودتان نوشته اید
به پشتیبانی از کدی که خوتان نوشته اید تمایل نشان دهید. خود شما مناسب ترین فردی هستید که می توانید به دیگران در فهم کدتان کمک کنید. شما باید تلاش کنید تا کد شما برای خودتان و دیگران تا سال های سال خوانا بماند.
35. نادیده گرفتن احتیاجات غیر ضروری
زمانی که شما سعی می کنید مطلبی را برسانید درنظر نگرفتن نقاط مهم مثل عملکرد و امنیت می تواند آسان تر باشد. یک لیست برای بررسی این موارد داشته باشید. شما نمی خواهید که سهم کاری خود را به دلیل درنظر نگرفتن این موارد غیر ضروری در لحظات پایانی پروژه از بین ببرید.
بدترین عادت برنامه نویسی شما چیست؟
همانطور که اغلب گفته می شود ما موجوداتی با عادت های مختلف هستیم. بهبود راهی که شما با این عادت ها کار می کنید راهی عالی برای جلوگیری از فکر کردن درباره ی هر وضعیتی بطور جداگانه می باشد. زمانی که شما راهی خوب برای انجام کاری پیدا کنید، انجام آن ساده خواهد شد.
نظرات کاربران در رابطه با این دوره