۱۰ عادت بد کد نویسی که در روند پروژه های نرم افزاری مشکل‌ساز می شود

اصل پارتو (‌Pareto‌‌‌‌‌‌) می گوید: ۸۰ درصد رخدادها از ۲۰ درصد دلایل بوجود می‌آید. در زمینه‌ی توسعه نرم‌افزار می‌توان گفت بیشتر مشکلات توسط تعداد محدودی از عادات بد برنامه نویسی ایجاد می‌شود. اجتناب از این عادات بد معمول باعث آسان تر شدن کار شما، بالا رفتن امنیت نرم افزار و افزایش انعطاف در اجرا می شود. پس آنها را بر‌طرف کنید تا کار شما بسیار بسیار راحت، سازنده و موثر باشد.

۱٫ غلط املایی در کد شما :
غلط های املایی در کد بسیار شایع و مشکل آفرین است. چون آنها هیچ ارتباطی با توانایی شما در برنامه‌نویسی ندارند. با این حال یک اشتباه در نام متغیر یا نام یک تابع در کد شما، می‌تواند یک اشتباه ویران کننده باشد چون آنها را نمی‌توان به راحتی کشف کرد.
اما راه حل چیست؟ کدنویسی در محیط‌های توسعه‌ی یک پارچه (IDE) یا حتی یک ویرایشگر متن خاص برای برنامه‌نویسان می‌تواند غلط‌های املایی را به طور قابل توجهی کاهش دهد. کار دیگری که می‌توانید انجام دهید نام متغیرها و توابع را به صورت اختیاری ساده انتخاب کنید تا به راحتی آنها را بنویسید یا درصورت اشتباه شدن بتوانید آنها را پیدا کنید. از کلماتی که می‌توانند با غلط‌های املایی همراه شوند و جابجایی حروف در آنها زیادتر است پرهیز کنید. (مانند receive)

۲٫ عدم رعایت تورفتگی و قالب دهی به کد:
تورفتگی و قالب‌دهی به کد باعث درک راحت‌تر در یک نگاه و کشف اشتباهات می شود. از طرفی باعث آسان‌تر خوانده شدن کد شما توسط سایر افراد مادامیکه به صورت یک مدل یکپارچه ارائه گردد، می شود. اگر شما از یک محیط توسعه‌ی یکپارچه (IDE) استفاده میکنید که بصورت خودکار کد شما را قالب‌بندی نمی کند توصیه می کنیم که از نرم افزار‌های قالب بندی کد همچون Uncrustify که کد شما را به صورت یکپارچه، با توجه به قوانین قابل تنظیم طبقه‌بندی و قالب‌بندی می کند استفاده کنید.

۳٫ عدم قطعه بندی یا ماژولار نبودن :
عادت کنید توابعی بنویسید که تنها یک کار را انجام دهد. این کار باعث می شود که آنها را مختصر کنید، راحت تر بفهمید و نگه‌داری کنید. توابع طولانی دارای مسیرهای بسیاری هستند که باعث سخت شدن تست و اشکال‌زایی در آن‌ها می شود.
دو قانون برای نوشتن توابع :
۱) تابع نباید بیش از یک صفحه نمایش را اشغال کند.
۲) اگر بیش از ۱۰ شرط ( if ) یا حلقه ( loop ) دارید، تابع شما بیش از حد پیچیده است و باید آن را بازنویسی کنید.

۴٫ اجازه بدهید محیط های توسعه‌ی یک پارچه ( IDE ) به شما یک حس امنیت کاذب بدهد:
محیط‌های توسعه‌ی یکپارچه و ابزارهای مشابه آنها که کد را برایتان کامل می کنند ابزارهای سودمندی هستند. آنها متغیر و بقیه ی چیزهایی که وابسته به حوزه ی فعالیت شما هستند را برای شما آماده میکنند. اما با اینکه آنها مفید هستند خطرناک هم هستند. شما ممکن است متغیر یا تابعی را توسط IDE انتخاب کنید، زیرا مشابه آن چیزی است که شما انتظارش را دارید. اما ممکن است دقیقا همان چیزی است که شما می خواهید برداشته نشود.
شما برای استفاده از IDE ها نیاز به یک خط احتیاط دارید. این ابزارها به کاهش خطاها و غلطهای املایی شما و افزایش بهروری کمک می‌کنند. در اصل این ابزارها برای شما فکر می‌کنند اما شما باید انتخاب کنید که آیا این فکرها درست هستند یا خیر. زیرا شما برنامه نویس هستید و آنها یک کمک برای شما هستند.

۵٫ کلمه ی عبور رشته ای درون کد:
شاید شما وسوسه شوید که یک کلمه‌ی عبور رشته ای درون کد برای دسترسی به سیستم خود بگذارید. کلمه عبور رشته ای درون کد یا hard coded ها رمزهایی هستند که در کد اصلی گذاشته می شوند و با قاعده‌ی برابری تصدیق میگردند. شما نباید این کار را انجام دهید. شاید کار شما با این کار راحت شود، اما این برای هرکسی که به کد اصلی دسترسی دارد نیز، راحت‌تر است.
مسئله‌ی اصلی این است که کلمه عبور رشته ای درون کد (hard coded) به طور گسترده‌ای شناخته شده است. این مسئله باعث خطر بزرگی می شود که آسیب جدی و ناخوشایندی را در نرم افزارتان پدید خواهد آورد.

۶٫ عدم استفاده از یک رمز نگاری خوب برای محافظت از اطلاعات:
داده‌های مهم زمانی که در شبکه مورد استفاده قرار گیرند به دلیل آسیب پذیر بودن نیازمند رمزنگاری هستند. این فقط یک ایده‌ی خوب نیست. شاید این کار یک قانون نباشد اما این یک نیاز نظارتی برای امنیت نرم افزار شماست. نوشتن سیستم رمزنگاری ایمنی خودتان سخت است. تنها ببینید چه اتفاقی بر سر WEP افتاده است. بنابراین یک کتابخانه ی مطمئن رمزنگاری استاندارد را انتخاب و به درستی از آن استفاده کنید.

۷٫ بهینه سازی کد در هنگام نوشتن:
برنامه‌نویس افسانه‌ای Donald Knuthگفت: برنامه‌نویسان زمان بسیاری را در خصوص تفکر یا پریشانی درمورد سرعت بخشیدن بخش‌های غیر اساسی برنامه‌هایشان هدر می دهد و این تلاش‌ها تاثیر منفی بر روی زمان در نظر گرفته شده برای اشکال‌زدایی و نگهداری می شود.
هشیار بودن در خصوص کد شاید باعث سرعت اجرا شود اما باعث سخت‌تر شدن اشکال‌زدایی و نگهداری هم خواهد شد. بهتر آن است که کد را به صورت واضح بنویسید و سپس وارد تمامی بخش‌هایی شوید که نیاز به بهینه سازی به منظور بهبود عملکرد دارند.

۸٫ عدم توانایی در آینده نگری:
پروژه‌ی شما برای چیست؟ تا چه اندازه از آن انتظار می‌رود؟ چه حجمی از پروژه انتظار می‌رود؟ چه تعداد کاربر از آن استفاده می‌کنند؟ چقدر باید سریع باشد؟ پاسخ به این سوالات ممکن است در دسترس نباشد. اما اگر شما با تخمین جواب این سوالات مشکل دارید و آن‌ها را پیدا نکرده‌اید پس چگونه می‌توانید یک چارچوب مناسب برای توسعه‌ی نرم‌افزار انتخاب کنید که پاسخگوی نیازهای شما باشد. اگر شما با دست‌کم گرفتن نیازهای آینده مشکل دارید، توییتر یک مثال خوب از مشکلاتی است که شما با آن دسته پنچه نرم می کنید.
توییتر مجبور شد زبان برنامه‌نویسی Ruby On Rails را رها کند و بیشتر کدهای آن را با استفاده از Scala و تکنولوژی‌های دیگر بازنویسی کند.‌ چون معماری اصلی Ruby به سادگی نمی توانست همگام با رشد روزافزون کاربران توییتر افزایش یابد.

۹٫ اضافه کردن افراد برنامه نویس برای جبران زمان از دست رفته:
تقریباً هر پروژه نرم‌افزاری از زمان بندی عقب می‌افتد. اضافه کردن افراد به پروژه برای اینکه آن را به زمان‌بندی برگردانیم در تئوری ایده‌ی خوبی است. اما این یک اشتباه رایج است. در واقع اضافه کردن افراد جدید به پروژه در اکثر موارد منجر به کاهش بهره وری کلی می شود.

۱۰٫ استفاده از زمان بندی بد گذشته:
در عین حال این نکته بسیار مهم است که اگر از زمان بندی عقب افتاده ایم از اضافه‌کردن افراد جدید جلوگیری کنیم. دلیل این امر تحمیل اشتباه زمان بندی شماست. این بدان معنی است که شما نیاز به تخمین دیگری از زمان پروژه هستید. نه این که کورکورانه در حال به اثبات رساندن حرف قبل خود باشید.

منبع:

۱۰bad coding practices that wreck software development projects