10 اشتباه رایج توسعه دهندگان بک اند Back-End + راه حل آنها

توسعه دهندگان بک اند مسئولیت برنامه نویسی ساختار و منطق (Logic) پروژه های نرم افزاری را برعهده دارند. در حقیقت توسعه دهندگان بک اند با توسعه، نگهداری و تقویت قابلیت های یک اپلیکیشن باعث می شوند که ما بدون باگ و کندی از کار با آن لذت ببریم.

توسعه دهندگان Back-End به خاطر مسئولیت سنگینی که بر دوش دارند بسیار تحت فشار قرار می گیرند به گونه ای که ممکن است اشتباهاتی را در فرآیند توسعه نرم افزار مرتکب شوند. امروز قصد داریم 10 مورد از اشتباهات رایج توسعه دهندگان Back-End را مورد بررسی قرار داده و نحوه جلوگیری از آن ها را نیز به شما معرفی کنیم.

1- بدهی فنی (Technical Debt) و مهندسی بیش از حد (Over-Engineering) :

بدهی فنی زمانی اتفاق می افتد که توسعه دهندگان بک اند اصول SOLID و DRY را در فرآیند کدنویسی زیر پا بگذارند؛ برای مثال برنامه نویسان برخی اوقات از تستینگ، مرور و ریفکتورینگ پروژه های نرم افزاری خود صرف نظر می کنند. کمبود بودجه یا عقب ماندن پروژه از برنامه زمانی دلیل اصلی بروز این مشکل است.

در این وضعیت توسعه دهندگان ریسک حساب شده ای انجام داده و حداقل کمینه محصول پذیرفتنی (MVP) را قبل از آماده شدن به بازار عرضه می کنند. متاسفانه توسعه دهندگان در بیشتر اوقات صرفا به خاطر فراموش کردن یا صرفه جویی در وقت از انجام مراحل ذکر شده صرف نظر می کنند.

برخی از توسعه دهندگان نیز به علت حواس پرتی از اصل سادگی برنامه نویسی (Keep it Simple, Stupid) چشم پوشی کرده و در نهایت فرآیند توسعه را بیش از حد پیچیده می کنند. به عبارت دیگر آنها به جای تمرکز بر روی قابلیت های تاثیرگذار معمولا به تقویت ویژگی های غیرضروری می پردازند. در این صورت اجرای عملیات ریفکتورینگ، بروز رسانی و مقیاس پذیری پروژه امکان پذیر نیست و تنها راه موجود بازسازی اپلیکیشن می باشد.

راه حل :

بازسازی یک پروژه به معنی دو برابر شدن هزینه و حجم کار است بنابراین اولین راه برای جلوگیری از بدهی فنی و مهندسی بیش از حد پروژه شما مقوله ارتباطات است. در حقیقت شما به عنوان یک مدیر پروژه یا مالک محصول (Product owner) باید مطمئن شوید که اعضای تیم از تمام ملزومات محصول آگاهی دارند.

علاوه بر این شما باید یک فهرست کاملا واقع بینانه از موارد قابل تحویل، اولویت ها و مهلت زمانی مربوط به آنها را نیز تنظیم کنید. در غیر صورت روند پروژه با بی نظمی مواجه می شود. شما می توانید با یک محصول MVP که حداقل ویژگی های ممکن را داراست کار خود را شروع کنید. در این حالت توسعه دهندگان همزمان با انتشار هر نسخه از محصول می توانند قابلیت های مورد نیاز بعدی آن را مورد بررسی قرار داده و استراتژی های مربوطه را تنظیم کنند.

شما همچنین می توانید جلساتی را با دیگر اعضای تیم برگزار کنید و کارهای روزانه را با آنها در میان بگذارید. به طور کلی به خاطر داشته باشید که شما در این راه تنها نیستید و برای تقویت پروژه باید با اعضای دیگر تیم مشورت کنید.

2- عدم اجرای تستینگ یا اجرای ناقص آن :

تستینگ یکی از مراحل اساسی در فرآیند توسعه محسوب می شود که امکان شناسایی و بر طرف کردن به موقع باگ ها را در اختیار توسعه دهندگان قرار می دهد. اگرچه آزمایش تمام مولفه های یک پروژه عملا غیر ممکن است اما توسعه دهندگان باید تست های مربوطه را تا حد ممکن در هر مرحله انجام دهند.

اجرای ناقص تست یا صرف نظر از انجام آن مشکلات غیرقابل پیش بینی ایجاد می کند. علاوه بر این، تعمیر و نگهداری نرم افزار بسیار سخت می شود چرا که توسعه دهندگان نمی توانند منشا مشکل و باگ را شناسایی کنند.

راه حل :

سعی کنید تست های مورد نظر را در هنگام توسعه قابلیت های جدید و همچنین بعد از برطرف کردن باگ ها اجرا کنید. شما برای این کار باید رویکرد تفکر چابک TDD (توسعه تست محور) را در مراحل توسعه، تست و اصلاح پروژه اجرا کنید. این کار در طولانی مدت موجب صرفه جویی و کاهش هزینه و وقت در پروژه می شود و شما قبل از آسیب دیدن پروژه می توانید باگ ها را شناسایی و برطرف کنید.

یکی دیگر از استراتژی های موجود این است که شخص دیگری کدهای شما را مورد بازبینی و بررسی قرار دهد. برای مثال مدیر ارشد پروژه، سرپرست فنی و دیگر اعضای تیم می توانند در این مسیر به شما کمک کنند. در حقیقت اقدامات مربوط به تستینگ برای دیگر اعضای تیم جدید است بنابراین درصد فراموش کاری آنها پایین می آید. البته به خاطر داشته باشید که این کار نباید به عنوان جایگزین فرآیند تستینگ در نظر گرفته شود.

در برخی اوقات ممکن است دست اندرکاران پروژه نظیر مالکان محصول درباره فرآیند تستینگ تردید داشته باشند. در این صورت شما باید آنها را از پیامدهای این موضوع آگاه کنید. برای مثال شما می توانید با برگزاری یک جلسه کاری اهمیت تستینگ را به زبان خیلی ساده برای مدیران پروژه شرح دهید.

3- عدم بررسی و تحلیل کدهای استاتیک :

تجزیه و تحلیل کدها معمولا در اکثر شرکت های توسعه دهنده به صورت همتا به همتا (Peer-to-Peer) اجرا می شود. در حقیقت زمانی که یک توسعه دهنده در حال آماده سازی قابلیت های یک نرم افزار است، کدهای مربوطه توسط یک توسعه دهنده دیگر مورد بازبینی قرار می گیرند. این شخص هر خط کد را به صورت دستی بررسی کرده و در صورت تایید، آن را به شاخه اصلی پروژه منتقل می کند.

تجزیه و تحلیل کدهای استاتیک (Static Code) یا همان سورس کدها نیز فرآیندی است که قبل از دیپلوی کردن کدها، آنها را به صورت اتوماتیک مورد آزمایش قرار می دهد. توسعه دهندگان Back End معمولا با استفاده از ابزارهای مختلف، کدهای استاتیک را بر اساس دستورالعمل های برنامه نویسی نظیر MISRA مورد بررسی قرار می دهند.

راه حل :

در وهله اول باید به اعضای تیم خود اعتماد داشته باشید و فیدبک آنها را دریافت کنید، در حقیقت هر کدام از اعضای تیم دارای مهارت های منحصر به فردی هستند که موجب افزایش کیفیت پروژه می شود. علاوه بر این، تجارب مختلف اعضای تیم ایده هایی را در اختیار شما قرار می دهد که شاید تا به حال به آن ها فکر نکرده باشید.

ابزارهای بسیاری نیز در بازار وجود دارند که تجزیه و تحلیل کدهای استاتیک را به صورت خودکار انجام می دهند، بنابراین باید با توجه به نوع پروژه و تیم توسعه دهنده بهترین گزینه را برای خود انتخاب کنید.

4- بی نظمی در انتخاب تکنولوژی و ابزارهای مورد نیاز :

توسعه دهندگان برای انجام کارهای روزانه خود از زبان های برنامه نویسی، فریم ورک ها و کتابخانه های متنوعی استفاده می کنند. در حقیقت هر برنامه نویس از ابزارهای مورد علاقه خود استفاده می کند و اغلب درباره مزایای آنها با دیگر توسعه دهندگان اختلاف نظر نیز دارد.

راه حل :

شما و اعضای تیم قبل از شروع پروژه باید درباره مجموعه ابزارهای مورد استفاده در طول روند توسعه به توافق نظر برسید. در حقیقت استفاده از ابزارهای بی شمار یا پیچیده مشکلات زیادی را در روند تعمیر و نگهداری پروژه به وجود می آورند چرا که توسعه دهنده مجبور است تمام تکنولوژی های استفاده شده در پروژه را به خوبی بشناسد. علاوه بر این برخی از ابزارهای استفاده شده در روند توسعه ممکن است با یکدیگر سازگار نباشند، بنابراین سعی کنید همواره پروژه را ساده و سبک نگه دارید.

5- عدم بک آپ گیری اتوماتیک :

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

بک آپ گیری در این شرایط بسیار کمک کننده است به گونه ای که در صورت خرابی هر کدام از دیتابیس ها می توان آخرین نسخه آن را مجددا راه اندازی کرد. اگرچه مقداری از داده ها در این شرایط هم ممکن است از بین بروند اما حجم عظیمی از دیتا به سلامت بازیابی می شود.

راه حل :

به محض شروع کار دیتابیس، آن را برای تهیه نسخه بک آپ خودکار پیکربندی کنید. اگر تا به حال این کار را انجام نداده اید حتما پس از مطالعه این مقاله دست به کار شوید.

6- عدم نظارت بر میکروسرویس ها :

میکروسرویس ها قابلیت هایی هستند که در مجموعه کدهای مستقل قرار داده شده اند و توسعه دهندگان برای بهبود امکانات یک محصول از آنها استفاده می کنند. برای مثال به ویژگی Login یا Signup وبسایت های امروزی نگاه کنید، شما در اکثر مواقع می توانید از طریق گزینه های مختلف نظیر گوگل اکانت، ایمیل و حساب های شبکه های اجتماعی در وبسایت های امروزی لاگین کنید.

حتی برخی از وبسایت ها این امکان را در اختیار کاربران قرار می دهد تا به صورت مستقیم با Gmail یا حساب شبکه های اجتماعی خود در آن لاگین کنند. در حقیقت این میکروسرویس موجب افزایش سرعت، امنیت و در مجموع بهتر شدن تجربه کاربری می شود.

البته بیشتر این سرویس ها به صورت مستقل توسط کمپانی های دیگر ارائه می شوند بنابراین توسعه دهندگان نظارت زیادی بر روی آنها ندارند. به عبارت دیگر اگر یک میکروسرویس دچار اختلال شود، هیچ جایگزینی برای آن وجود ندارد و کاربران نمی توانند به آن دسترسی پیدا کنند.

راه حل :

در وهله اول سعی کنید در صورت امکان گزینه های جایگزین را در اختیار کاربران قرار دهید. برای مثال لاگین با Gmail بسیار راحت و سریع انجام می شود اما اگر کاربران به خاطر اختلال در میکروسرویس گوگل نتوانند به اکانت خود وارد شوند، شما را مقصر این امر می دانند.

علاوه بر این، به محض انتشار محصول حتما یک سیستم مانیتورینگ برای بررسی عملکرد هر کدام از میکروسرویس ها در نظر بگیرید. به این ترتیب شما می توانید از بروز اختلال در آنها با خبر شده و اقدامات لازم را انجام دهید.

7- دیتا مدل های نامناسب :

مدل داده یا همان Data Model اولین مرحله از طراحی دیتابیس به شمار می رود. این فرآیند در واقع نوع دیتا، نحوه جمع آوری آن و همبستگی (Correlation) بین هر کدام از داده ها را برای دیتابیس تعیین می کند. دیتا مدل های نامطلوب بر روی عملکرد کلی پروژه تاثیر می گذارد به گونه ای که درخواست های کاربران با تاخیر بسیار زیاد انجام می شود، علاوه بر این، آپگرید و نگهداری زیر ساخت های پروژه در دراز مدت پر هزینه و دشوار می شود.

راه حل :

قبل از شروع به کار پروژه با اعضای تیم درباره دیتا مدل مناسب به توافق نظر برسید. اگر در اوایل کار هستید نیز می توانید مدل داده را تنظیم نمایید اما اگر دیتا مدل نامناسبی را دیپلوی کرده اید باید مدل مربوطه را بروز رسانی کرده و برای داده های مشکل دار یک Migration Script بنویسید. متاسفانه در این مرحله برخی از اطلاعات دیتابیس حذف می شوند.

8- تزریق SQL :

تزریق SQL در واقع کوئری های نوشته شده توسط کاربران غیر مجازی است که از طریق رشته های به هم پیوسته در دیتابیس اجرا می شوند. این اقدامات باعث می شود که کاربر خرابکار به اطلاعات بسیار حساس موجود در دیتابیس دسترسی پیدا کند. تزریق SQL یک اصطلاح نسبتا عمومی است چرا که زبان های مشابه دیگر نیز مستعد حملات تزریق قرار دارند.

راه حل :

یکی از بهترین روش ها برای جلوگیری از تزریق SQL عدم استفاده از الحاق رشته ای (String Concatenations) است، در عوض شما می توانید پارامترها را به هر کوئری منتقل کنید. بازبینی کدها نیز یکی از روش های خوب برای جلوگیری از تزریق SQL به شمار می رود، اما با این حال مطمئن شوید که کوئری های رشته ای همواره توسط یک سری از کاربران دیتابیس (ها) تایید شود.

9- فراموش کردن Logs :

استفاده از فایل های Log در تعمیر و نگهداری پروژه موجب صرفه جویی در وقت توسعه دهندگان می شود. متاسفانه جمع آوری گزارشات Log آنچنان در بین توسعه دهندگان Back-End مرسوم نیست. این روش در مقایسه با گزارشات Stack Trace (استراتژی محبوب توسعه دهندگان بک اند) این امکان را در اختیار شما قرار می دهد که علاوه بر شناسایی خطا و مکان آن، چگونگی بروز رسانی آن را نیز مشاهده کنید.

راه حل :

یک سیستم Logging نظیر تایم استمپ (Timestamp) و Stack Trace بر روی محصول پیاده سازی کنید تا ارورهای هر سرور را برای شما ردیابی کنند. سیستم های جمع آوری داده ساده و معمولی نیز یک نمای کلی از نحوه عملکرد و استفاده از سیستم را در اختیار شما قرار می دهد.

10- عدم نمایش اطلاعات حساس در ارورهای سمت کاربر و سمت سرور :

همه ما با ارورهای 404 و Page Not Found آشنایی داریم. به طور کلی ارورهایی که با عدد 4 شروع می شوند ارورهای سمت کاربر به شمار می روند و باید حاوی جزییات و اطلاعات بسیار ناچیز باشند. به این ترتیب توسعه دهندگان به سرعت مشکل را متوجه شده و برای برطرف کردن آن اقدام می کنند.

در طرف دیگر ارورهای سمت سرور که با عدد 5 شروع می شوند باید فاقد هرگونه جزییات باشند. برای مثال نمایش اطلاعات در ارور 500 دیتابیس و سیستم را در معرض خطر حمله قرار می دهد.

راه حل :

برای جلوگیری از نشت اطلاعات حساس در ارورهای 500 از تمام آموخته های خود استفاده کنید. علاوه بر این سعی کنید از روش های مناسب برای توسعه استفاده کرده و Endpointها را بر اساس آن پیاده سازی کنید. برای مثال کدهای موجود را بازبینی کرده و تا حد ممکن فرآیند تستینگ را انجام دهید. در نهایت مطمئن شوید که تمام ارورهای 500 حاوی پیام ساده internal server error هستند.