6 اشتباه برنامه نویسی که نباید انجام دهید
در همه شغل ها و حرفه ها اشتباهاتی وجود دارد که اگر آنها را بشناسیم می توانیم در تصمیم گیری بهتر عمل کنیم و آن اشتباه ها را تکرار نکنیم. در این مطلب اشتباهاتی را مشخص می کنیم که شاید خیلی از ما قبلا مرتکب آن شده بودیم ولی دیگر به اشتباه بودن آن پی برده ایم و آنها را تکرار نمی کنیم.
دوره های شبکه، برنامه نویسی، مجازی سازی، امنیت، نفوذ و ... با برترین های ایران
سرفصل های این مطلب
استفاده نکردن از ORM درست
لایه DataAccess لایه ای از پروژه برنامه نویسی است که اگر به درستی مدیریت و ساخته نشود می تواند کابوسی برای برنامه نویسان باشد. حالتی را تصور کنید که شما برای ارتباط با دیتابیس کلاس هایی را پیاده سازی کرده اید و راه ارتباطی خودتان را برای این کار پیاده سازی کرده اید. حال تغییری پیش می آید که بخشی از برنامه باید عوض شود. این تغییر در حدی بزرگ است که به بخش ارتباط با داده ها یا حتی به جداول دیتابیس نیز کشیده می شود و ساختار آنها را عوض می کند. (این تغییرات ممکن است خیلی وقت ها پیش بیاید) اینجاست که اگر کلاس های لایه DataAccess را به خوبی پیاده سازی نکرده باشید تراژدی شروع می شود و باید زحمت بکشید و تغییرات را اعمال کنید که خود همین کار زمان و انرژی زیادی از شما خواهد گرفت. یا ممکن است که دستوراتی را که در این لایه نوشته اید برای اجرا کردن کوئری ها بهینه نباشند و باعث افت کارایی و سرعت و بار اضافی بر روی سیستم شود. اینجاست که ORM ها وارد می شوند. کتابخانه هایی که تست شده است و به صورت استاندارد تعریف شده اند و هر چند وقت یک بار بروزرسانی و بهینه می شوند. از آنها استفاده کنید. اگر برای زبانی که با آن کار می کنید ORM های مختلفی وجود دارد تحقیق کنید و با توجه به ویژگی های پروژه گزینه مناسب را انتخاب کنید و تا حدودی خیالتان از لایه DataAccess راحت باشد.
یاد نگرفتن و یا استفاده نکردن از Generic
اگر شما با زبانی Strongly Type مثل جاوا و یا سی شارپ را استفاده می کنید شاید لازم باشد که یک کار تکراری را بر روی اشیا از کلاس های مختلف پیاده سازی کنید. در این صورت باید برای هر کلاس عملیات گفته شده را پیاده سازی کنید. شاید برای نوشتن یک برنامه ساده این خیلی مشکلی نباشد ولی اگر پروژه شما یک پروژه بزرگ است به مشکل های جدی برخورد خواهید کرد. تصور کنید که شما این کار را برای چند تا از کلاس های پروژه انجام داده اید. حالا بنا به درخواست کارفرما و یا دلایل دیگر لازم است که تغییری در روند عملیات ایجاد کنید. خب اینجاست که کار گِل شروع میشه و تغییر مورد نظر رو باید روی همه کلاس ها انجام بدید. انجام دادن کار تکراری باعث بالا رفتن اشتباه و باگ می شود و یا حتی ممکن است که تغییر در برخی کلاس ها فراموش شوند. خب استفاده از Generic باعث می شود که همه این مشکلات از بین برود. پس اگر بلد نیستید حتما آن را یاد گرفته و از آن استفاده کنید.
دوباره چرخ را احتراع نکنید.
خیلی از برنامه نویسان تازه کار می خواهند که همه چیز را از صفر خودشان بنویسند و چرخ را دوباره اختراع کنند. چه کاریه خب؟ دوستانی که این کار را می کنند دلیلشان این است که چیزی که وجود دارد مشکل دارد پس من بهترش را می سازم. در اکثر مواقع توصیه می شود که از موارد موجود استفاده کنید. چون کتابخانه ها و کلاس های آماده بسیاری وجد دارند که نیاز شما را برطرف می کنند و لازم نیست که وقت برای پیاده سازی همان موارد صرف کنید. آخر سر هم خواهید دید که پیاده سازی شما پر از نواقص و خطاها خواهد بود.
مستندسازی زیادی موقوف!
مستندات پروژه چیست؟ توضیحاتی که در مورد آن قسمت از کد در برنامه به زبان آدمیزاد نوشته می شود. به نظر شما چه مشکلی دارد که مستندسازی انجام شود؟ باید بگویم که خود مستندسازی کار خوب و پسندیده ای است اما خیلی وقت ها مستندسازی نوشته های اشتباه و تاریخ گذشته و ناقصی است که ما در قسمت های مختلف برنامه آنها را نوشته ایم. دلیلش هم این است که شما یک قسمت از برنامه را مستندسازی کرده اید. خب همین مستندسازی زمانی را از شما گرفته است. حال در همان قسمت برنامه باید تغییراتی ایجاد کنید. دقت کنید که انجام دادن تغییر مورد نظر و خطایابی آن امری واجب ولی تغییرات در مستندسازی امری مستحب است. به همین دلیل شما وقتی که کار تغییر آن قسمت از برنامه را انجام دادید باید مستندسازی را نیز تغییر بدهید. تجربه نشان داده شده است که این کار معمولا به آخر وقت روز کاری موکول می شود و خیلی اوقات هم فراموش می شود. پس در این حالت مستندسازی تبدیل به یک سری نوشته ناقص و تاریخ گذشته و غلط خواهد شد که به هیچ دردی نمی خورد و شاید گمراه کننده هم باشد. پس مستندسازی زیادی موقوف.
ماژول بندی کردن برنامه برای دیباگ و خطایابی
این که بخواهیم کل برنامه را اجرا کنیم و قدم به قدم با آن پیش برویم تا خطایابی کنیم کار درستی نیست. زیرا که این کار باعث می شود که زمان زیادی را صرف کنیم که از قسمت های بی عیب رد بشویم تا به خطا برسیم. شاید بعضی اوقات حالتی وجود داشته باشد که خطایابی آن بسیار زمان بر باشد. مثلا برنامه شما متدی دارد که بعد از 45 دقیقه اجرای برنامه فراخوانی می شود. آیا شما برای تست آن باید 45 دقیقه منتظر بمانید؟ مسلما خیر. مشا می توانید برنامه را به ماژول های مختلف تقسیم کنید و آنها را خطایابی کرده و بعد از این که صحت هرکدام ارزیابی شد آنها را کنار یکدیگر قرار دهیم.
تست واحد| Unit test بنویسید
من قبلا فکر می کردم که برنامه ای که می نویسم اولا که بسیار واضح است و ثانیا بسیار راحت قابل ارزیابی است و می توان به صورت دستی و چشمی خطایش را پیدا کرد و unit test برای برنامه های بزرگ و پیچیده است نه برای برنامه های من. اما همین برنامه کوچک من بعد از تغییرات تبدیل به یک هیولا می شد که وقتی باگی در آن پیدا میشد کلی وقت لازم داشت تا پیدا و رفع شود. همچنین این برنامه ها من به خاطر این ذهنیت که یک برنامه کوچک است مفاهیمی مانند seperation of concern, refactoring را نیز در آن لحاظ نکرده بودم و یک کد بد نوشته می شد.
به خاطر همین شکل کد من با انجام کوچک ترین تغییراتی مقابله می کردم چون هر تغییری ممکن بود که خطاهایی به وجود بیاورد که کلی زمان برای رفع آن لازم خواهم داشت. اما با unit test شما خواهید دانست که خطا در چه محلی و به چه دلیلی رخ داده است و مستقیم به آن قسمت رفته و آن را رفع می کنید و این طوری زندگی زیبا تر خواهد بود. پس تست بنویسید.
با وب سایت tosinso همراه باشید
نویسنده: مهدی عادلی فر