چند عادت بد برنامه نویسی که باعث خرابی کد شما می شود.
عادتی به نام بعدا درستش میکنم!
عادت محول کردن کارها به آینده صرفا مربوط به اولویت‌ها نیست؛ گاهی اوقات فقط برحسب عادت، حل یک مشکل هنگام کدنویسی را به آینده موکول میکنیم و سپس ممکن است آن را فراموش کنیم. حل و رفع مشکلات کوچک به مرور زمان باعث پیشرفت شما می‌شـود و نباید به راحتی از حل این مشکلات غافل شوید. پس اگر عادت دارید کارها را به آینده موکول کنید، می‌توانید با استفاده از ابزاری مثل To-Do استفاده کنید، برنامه‌ی تمام کارهای خود را سازمان‌دهی کنید و مرتب بچینید. با استفاده از این روش پس از این، هرگز کارهای کوچک خود را فراموش نخواهید کرد و یکی از عادت‌های بد خود را رفع می‌کنید.
علاقه‌ی بی مورد به راه‌حال‌های تک خطی!
حساس بودن روی قطعات کد و علاقه به کوچک کردن آن می‌توان گفت عادت و ویژگی برنامه‌نویسان است. این قضیه مانند این است که شما ۲۰ خط کد را به ۲ خط کد تبدیل کنید. ممکن است کد شما جواب دهد اما خوانایی کد از بین می‌رود و کم می‌شـود. بهتر است ابتدا کد خود را به جواب درست و صحیح برسانید و سپس روی هوشمندانه شدن کدتان تمرکز کنید.
بهینه‌سازی بی ثمر
بهینه‌سازی تا حدی بسیار خوب و مناسب است؛ اما هنگامی که بیش از حد بخواهید حجم فایل‌ها را کاهش دهید، تلاش خود برای نوشتن کد را هدر می‌دهید. بهینه‌سازی زیاد به طور کلی نیازها را تغییر می‌دهد و همه‌چیز متفاوت می‌شود؛ آنگاه شما بیهوده تلاش کرده‌اید.
استفاده از نام‌هایی که حاوی اطلاعات مناسب نیستند!
نام‌گذاری سخت است ولی لازم است نام تمام متغیرها و توابعی که مشخص می‌کنید متناسب با عملکرد آنها باشد؛گر نام‌گذاری صحیح باشد خوانایی کد به طرز قابل توجهی، افزایش می‌یابد و به راحتی می‌توان فهمید که یک تابع چه کاری انجام می‌دهـد.
نادیده گرفتن ارورها
ممکن است شما با استفاده از دستورات، استثنائات را نادیده بگیرید و یا با استفاده از یک کتابخانه این‌کار را انجام دهید. اما زمانی که یکی از آن خطاها، خطای اصلی برنامه باشد و در اولویت قرار گیرد، حل کردن آن بسیار زمان‌بر خواهد بود و رشته‌ی کد از دستان شما خارج می‌شود. بهترین راه این است که زمانی را صرف یادگیری و رفع خطاهایی کنید که آنها را نادیده گرفته‌اید.
متقاعد کردن خود با این موضوع که استایل دهی خیلی مهم نیست
چیزی که طی سالیان های زیاد از بررسی کدهای دیگران یاد گرفتم روند استایل دهی به کدهایشان می باشد که اکثر توسعه دهندگان مایل هستند که آن را به تاخیر بیندازند. برای کدنویس های بی تجربه با گذر زمان متوجه خواهند شد که استایل داشتن کد میتواند تاثیر خوبی داشته باشد. اما زمانی که کد کیفیت خود را از دست می دهد یک مشکل کوچک، تمام پروژه را با مشکل روبرو می کند. درباره ی بهترین روش ها هرچند اگر بی اهمیت به نظر برسند سخت گیرانه عمل کنید. بررسی کد و ابزار های linting را تنظیم کنید تا فرصت داشته باشید درباره ی موضوعات مهم تر فکر کنید.
لاپوشانی کردن
با گرفتن یا نادیده گرفتن exception ها یا با استفاده از کتابخانه هایی که خطاها را گزارش نمی دهند (مانند jQuery) و راه های بسیار دیگر می توانید لاپوشانی کنید اما زمانی که رفع یکی از این ارور ها از اولویت ها باشد، این کار بسیار زمان بر خواهد بود زیرا شما هیچ سرنخی برای شروع ندارید. یک راه ساده برای انجام این کار درنظر گرفتن ارور های نادیده گرفته شده است که می توانید درباره ی این موضوع بعدا مطالعه کنید.
نادیده گرفتن روش های خوب اثبات شده
بررسی های کد، توسعه ی حاصل از تست، تضمین کیفیت، خودکارسازی توسعه و چندین موارد دیگر، از روش هایی هستند که ارزش آن ها در پروژه های بی شماری اثبات شده است به همین دلیل است که توسعه دهندگان بطور مداوم از این روش ها استفاده می کنند. یک مرجع خوب برای این روش ها کتاب ساخت نرم افزار: چه چیزی واقعا کار می کند و چرا به این کار معتقد هستیم، می باشد. زمان بگذارید و یادبگیرید که چگونه این کار ها را به درستی انجام دهید با این کار ها پروسه ی نرم افزار در همه ی پروژه های شما به راه هایی که شما را شگفت زده خواهد کرد، بهبود خواهد یافت.
اگر در فکر این هستید از تلفن همراه برای پیشرفت کسب و کارتان استفاده کنید و با یک طراحی اپلیکیشن حرفه ای ارتباطی موثر بین خود و مشتریان ایجاد کنید.پیشنهاد میکنیم این لینک را کلیک کنید.
کار تیمی
فراموش کردن برنامه
یک روش که مطمئنا کار تیمی را به نابودی می‌کشد این است که کارتان را طبق برنامه انجام ندهید و یا نیمه کاره انجام دهید. فرض کنید چندین تابع نیمه‌کاره در یک کد بسیار بزرگ وجود داشته باشد، چه افتضاحی! تغییر رهبر گروه ممکن است باعث ایجاد چنین مشکلی شود.
برنامه‌ی بی نتیجه
همانطور که عدم پایبندی به برنامه میتواند کارتیمی را نابود کند، ادامه دادن و اصرار داشتن بر یک برنامه و نقشه‌ی ضعیف نیز کار را نابود می‌کند. این مسئله دال بر اهمیت و ضرورت مشورت و ایده‌دهی به دیگر اعضای گروه است. گاهی اوقات یک طرز فکر و یا ایده‌ی جدید می‌توانید کار تیم را به سرانجام برساند.
عدم استفاده‌ی کافی از گوگل
بهترین راه حل مشکلات پیچیده استفاده از گوگل است. انجمن و سایتی مانند Stack Overflow ، کمک بسیار شایانی به حل مشکلات گروه می‌کند. ممکن است مخالفت با مهندسین دیگر آنها را آزرده خاطر کند اما بهتر است که هم‌اکنون به اشتباهات خود پی ببرند و آنها را اصلاح کنند.
عدم به اشتراک گذاری مطالبی که یاد گرفته‌اید!
ارزش شما به عنوان یک شخص حرفه‌ای و توسعه دهنده صرفا به مهارت شما در کدنویسی بستگی ندارد؛ بلکه به مطالبی که هنگام نوشتن کدها یاد می‌گیرید بستگی دارد. می‌توانید مواردی را که یاد گرفته‌اید با دیگر هم‌تیمی‌های خود به اشتراک بگذارید تا دیگران نیز از تجربیات شما استفاده کنند و کار تیمی بهتر از پیش جلو برود.
عدم تعامل با دیگران!
بهتر است که همیشه پیشرفت و ایده‌های خود را با دیگر اعضای تیم در میان بگذارید. ممکن است شما فکر کنید کاری را به بهترین شکل ممکن انجام داده‌اید اما از نظر بقیه ایراداتی داشته باشد و شما از این ایرادات بی خبر باشید. صحبت کردن و مشورت با دیگران باعث می‌شود به تجربیات شما افزوده شـود و بسیار موفق‌تر از پیش باشید.
میدونستی بخاطر نداشتن سایت، روزانه چقدر مشتری از دست میدید؟!!ا گر قصد گسترش کار خود را داشته و میخواهید یک وبسایت زیبا و کاربر پسند داشته باشد پیشنهاد میکنم این لینک را کلیک کنید
نوشتن کد
ندانستن نحوه ی بهینه سازی
یک استراتژی بهینه سازی درست ، نیاز به تجربه دارد. برای دستیابی به یک استراتژی خوب نیاز به تحقیق،آنالیز و دانستن این که هر سیستم در یک پروسه شامل می شود، دارد. خودتان را راجع به این موارد آگاه کنید. درباره ی پی الگوریتم های پیچیدگی، ارزیابی کوئری های پایگاه داده، پروتکل ها و چگونگی اندازه گیری عملکرد سیستم به صورت کل بیاموزید.
استفاده از ابزارهای غلط برای کار
شما می توانید به داشتن اطلاعات محدودی بسنده کنید اما دلیلی که باعث می شود یادگیری را ادامه دهید این است که هر مشکل جدیدی که پیش می آید، محتوا های مختلفی دارد و به ابزار های مختلفی نیاز دارد. نسبت به زبان ها و کتابخانه های جدید پذیرا باشید و نسبت به چیزی که هم اکنون بلد هستید پافشاری نکنید.
نادیده گرفتن پیام های خطا
فرض نکنید که بدون خواندن پیغام خطا می دانید که اشکال کدشما کجاست یا اینکه به سرعت متوجه آن خواهید شد. همیشه داشتن اطلاعات بیشتر درباره ی مشکل بهتر است و زمانی که برای جمع آوری اطلاعات صرف می کنید درطولانی مدت، ذخیره خواهد شد.
مسلط نبودن روی ابزارها و IDE های خودتان
هر کلید ترکیبی، کلید های میانبر یا پارامتر هایی که زمان استفاده از ابزار ها یاد می گیرید، یک اثر مثبت روی سرعت کدزنی شما دارد که متوجه آن می شوید. استفاده از کلید های ترکیبی فقط باعث صرفه جویی چند ثانیه ای از کار شما نمی شود بلکه تعویض محتوا را کاهش می دهد. هرچه زمان بیشتری را روی کار های کوچک صرف کنید، زمان کمتری دردسترس دارید که فکر کنید چرا یک کد را نوشته اید و چه چیزی بعد از آن اتفاق خواهد افتاد. تسلط بر روی کلید های میانبر ذهن شما را آزاد می کند.
copy/past کورکورانه ی کد
قبل از اینکه از کد استفاده کنید آن را کامل متوجه شوید. گاهی شما بایک نگاه گذرا روی کد، کاری که انجام می دهد را سریعا متوجه می شوید و گاهی هم زمانی که کد را به طور دقیق مطالعه کنید بیشتر یاد خواهید گرفت
ابزار های توسعه ی خود را به صورت تخیلی فرض کردن
گاهی ویرایشگر یا ابزار خط دستور موردنظر شما، بهترین ابزار برای کاری که دردست دارید نیست. Visual Studio برای نوشتن IDE ها عالی است، Sublime برای زبان های پویا عالی است، Eclipse برای جاوا عالی است و غیره. ممکن است شما به vim یا emacs علاقه داشته باشید اما این به این معنی نیست که این ابزار ها برای هرکاری مناسب هستند.
ارزش های هاردکدینگ به جای قابل تنظیم کردن
همیشه به تغییراتی که ممکن است پیش بیاید و اینکه چگونه با آن ها مواجه شوید فکر کنید. بدهی های تکنیکی، اگر قطعات متحرک را از باقی کار جدانکنید به سرعت رشد خواهد کرد. درصورت لزوم از ثابت ها و فایل های پیکربندی استفاده کنید که قابلیت تنظیم کردن داشته باشد.
تعویض دائم روش ها
کد هایی که به آن ها نیاز ندارید را ننویسید. ممکن است شخص دیگری به اندازه ی کافی زمان روی مشکلی که شما هم اکنون دارید صرف کرده باشد و یک راه حل بهتر داشته باشد که شما بتوانید از آن استفاده کنید. خودتان را از روبرو شدن با برخی مشکلات حفظ کنید.
اعتماد به نفس بیش از حد روی کد خودتان
اینکه فکر کنید چون شما کدی را نوشته اید باید عالی باشد خطرناک است. هرچه شما روی موارد جدید کار کنید و تجربه به دست بیاورید، بیشتر یاد خواهید گرفت بنابراین هرازگاهی روی کد های قدیمی خودتان نگاهی بکنید و ببینید که چگونه پیشرفت کرده اید.
وقت نگذاشتن روی اینکه چیزها واقعا چگونه کار می کنند
همیشه شانس اینکه چگونه کد ها واقعا کار می کنند را دریابید و درباره ی لایه های زیرین آن مطالعه کنید. ممکن است الان با مطالعه نکردن درباره ی این موضوع زمان خود را ذخیره کنید اما آنچه شما در یک پروژه یاد می گیرید در طولانی مدت از آنچه که انجام می دهید مهم تر خواهد بود.
فکر نکردن درباره ی تعادل بین طراحی، solution یا کتابخانه
هر محصول نقاط مثبت خود را دارد که فقط با استفاده و آنالیز کردن آن متوجه آن ها خواهید شد. مشاهده ی مثال های محدود از استفاده های یک کتابخانه شما را روی آن کتابخانه مسلط نخواهد کرد البته به این معنی هم نیست که برای همه ی راه حل هایی که در پروژه ی شما پیش خواهد آمد مناسب است. درباره ی هرچیزی که استفاده می کنید نگاهی انتقادی داشته باشید.
کمک نگرفتن در زمانی که نیاز دارید
داشتن یک حلقه فییدبک همیشه برای شما کمتر سخت خواهد بود. درخواست کمک کردن به معنی این نیست که شما مناسب این کار نیستید. دیگران تلاش شما را خواهند دید و ندانستن را به عنوان مرحله ای از یادگیری میبینند و این یک ویژگی بسیار خوب است.
طراحی اپلیکیشن قدرتمند
مسیر جذب مشتریان بیشتر
