آشنایی با برخی دلایلی که پروژه‌های نرم‌افزاری با شکست مواجه می‌شوند!

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

تست نکردن سورس‌کد
معمولاً ریفکتور کردن سورس‌کد باعث بروز باگ در دیگر جاهای پروژه که در ظاهر بی‌ربط هم هستند می‌شود! هرچقدر هم که دولوپر مُجربی باشید، باز هم نمی‌توانید همهٔ تأثیراتی را پیش‌بینی کنید که ممکن است در اثر تغییر بخشی از کد به‌‌ وجود می‌آیند و به همین هم دلیل هست که حرفهٔ برنامه‌نویسی به‌ عنوان یکی از حرفه‌های پُراسترس شناخته می‌شود. به‌ عبارت‌ دیگر، هر لحظه امکان اشتباهی گیج‌کننده وجود دارد که توصیه می‌شود برای جلوگیری از عدم بروز چنین مشکلاتی، از Unit Testing استفاده نمایید.

عدم لاگ‌گیری
آگاه شدن از همهٔ مشکلات و نواقص برنامه‌ای که نوشته‌اید کار آسانی نیست چرا که برخی از این نواقص و مشکلات ممکن است به‌ ندرت رخ دهند آن‌ هم در صورت استفاده از موارد خیلی خاص. گرچه ممکن است این توانایی را نداشته باشید که همهٔ مشکلات احتمالی را پیش‌بینی کنید و مانع رخ دادن آن‌ها شوید، اما می‌توانید تلاش کنید تا مطمئن شوید که اگر این مشکلات زمانی رخ دادند، از وجود آن‌ها اطلاع می‌یابید. برای این کار می‌توانید از مکانیسم‌های Exception Reporting استفاده کنید که برای کسب‌ اطلاعات بیشتر، توصیه می‌کنیم به مقالهٔ آشنایی با مفهوم Structured Logging در توسعهٔ نرم‌افزار مراجعه نمایید.

کدهایی که برای مدت طولانی ایزوله می‌شوند
توسعهٔ کدهای ناتمام و نگاه‌داری آن‌ها به‌ صورت مجزا از کدهای اصلی نوشته شدهٔ نرم‌افزار، نشانه‌ای از پیشرفت کاری شما است؛ اما توجه کنید که اگر برای مدت طولانی کدهای خود را همراه با سایر کدهای نوشته شده به‌روزرسانی نکنید، آن‌وقت است که سورس‌کد شما ایزوله شده و پروژهٔ شما ممکن است که با مشکلات عدیده‌ای روبه‌رو شود. اما سؤال اینجا است که چرا نباید کدهای قدیمی و کدهای جدید را به‌ مدت طولانی از هم جدا کرد؟

در پاسخ به این سؤال بایستی گفت که علت این است که هر چقدر دیرتر کدهای جدید را با کدهای قدیمی ترکیب کنید، بر این احتمال افزوده‌اید که این کدها سازگاری خود را با یکدیگر از دست دهند و در نتیجه یک مُشت کد ناسازگار روی دست‌تان می‌ماند که با هم سازگار نیستند؛ لذا سعی کنید هرچند وقت یک‌ بار، کدها را ترکیب کرده و ترکیب مستمر کدها را به بخشی از فرایند کاری خود تبدیل کنید.

پروژه‌های تک-دولوپری
وقتی فقط یک دولوپر مسئول توسعهٔ یک سورس‌کد است، چنین پروژه‌ای به‌ نوعی انحصاری می‌شود چرا که کاملاً به‌ وجود آن فرد مسئول وابسته است. بگذارید یک مثال برایتان بزنیم تا قضیه کمی روشن‌تر شود. فرض کنید که ساسان تنها کسی است که به یک بخش از سورس‌کد فلان پروژه اشراف دارد و از شواهد نیز چنان برمی‌آید که وی قصد سفر به دُبی را دارد اما در‌ عین‌ حال شما هم برای تکمیل پروژه، به این قسمت از کد نیاز دارید (به نظر می‌رسد که توضیح ادامهٔ این داستان فرضی ضرورتی نداشته باشد!)

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

برای اجتناب از این مشکل می‌توانید به Pair Programming پناه ببرید و/یا کدها را به‌ صورت مرتب با یکدیگر مرور کنید تا مالکیت کدها به‌ اشتراک گذاشته شود (برای آشنایی بیشتر با برنامه‌نویسی دونفره، به مقالهٔ نکاتی در مورد نحوۀ اجرای صحیح Pair Programming مراجعه نمایید.)

عدم وجود کدهای حلال مشکل
هر بخش از یک کد مخصوص حل یک مشکل خاص است که اگر بخواهیم این جمله را به‌ صورت ایده‌آل تفسیر کنیم، بایستی بگوییم هر کد می‌تواند یکی از مشکلاتی که اکنون با آن دست‌وپنجه نرم می‌کنید یا مشکلاتی که ممکن است در آینده با آن‌ها روبه‌رو شوید را حل کند. اما در عین حال مشکلات بی‌شماری نیز ممکن است رخ دهند! اگر احتمال رخ دادن این‌گونه مشکلات کم باشد و سعی در حل کردن تک‌تک آن‌ها داشته باشید، کد شما بسیار پیچیده خواهد شد و برای رفع این معضل همواره سعی کنید بیش از حد مهندسی به خرج ندهید و تا جایی‌ که ممکن است همه چیز را ساده نگاه دارید (برای آشنایی بیشتر با تأثیر ساده‌سازی سورس‌کد، به مقالهٔ KISS: رویکردی که کمک می‌کند به دولوپر بهتری مبدل گردیم! مراجعه نمایید.)

چرخ را دوباره اختراع نکنید 
مطمئناً این اصطلاح قبلاً به گوشتان خورده است، اما برای آن‌هایی که بار اول است این اصطلاح را می‌شوند، نکاتی را در ادامه توضیح خواهیم داد. این جمله در یک کلام عبارت است از اینکه از هرگونه دوباره کاری اجتناب کنیم. یعنی کاری که دیگران کلی زحمت کشیده‌اند و انجامش داده‌اند را دوباره با کلی زحمت انجام نداده و راهی را که دیگران پیموده‌اند را دوباره نپیماییم؛ اما این جملهٔ مهم به چه درد دولوپرها می‌خورد؟

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

کدها به لایبرری‌های خارجی زیادی وابسته‌اند
گرچه لایبرری‌های مختلف می‌توانند مسیر کاری شما را روشن سازند اما متأسفانه در عین‌ حال می‌توانند مُخرب هم باشند. در پاسخ به این سؤال که چه زمانی لایبرری‌های خارجی مخرب‌ هستند، بایستی گفت که:

- وقتی باگی مرتبط با آن لایبرری به اطلاع مجرمین سایبری می‌رسد
- وقتی که بهینه نبوده و زمان لود نرم‌افزار را طولانی می‌کنند
- وقتی که توسعهٔ آن‌ها دیگر ادامه پیدا نمی‌کند و یا اصطلاحاً Deprecated می‌شوند
- وقتی‌ که در پروژهٔ خود تعداد زیادی از این لایبرری‌ها دارید و در عین‌ حال زمان کافی برای خواندن سورس‌کد، کاستومایز کردن برخی فیچرها و ... ندارید

روی‌ هم‌ رفته تنها زمانی از لایبرری‌های به‌ اصطلاح Third Party استفاده کنید که مطمئن باشید کیفیت بالایی دارند و شما نیاز مبرم بدان‌ها دارید و اگر آن لایبرری رایگان است، اطمینان حاصل کنید که توسعه‌دهندگان آن پس از مدتی درخواست پول نمی‌کنند!

سورس‌کد آن‌طور که باید و شاید نگهداری نمی‌شود
همچون مواد خوراکی، کدها هم فاسد می‌شوند و این حقیقتی تلخ است اما باید آن‌ را پذیرفت. هنگامی که یک بخش از پروژه رشد می‌کند و توسعه می‌یابد، سایر بخش‌ها عقب می‌مانند و متأسفانه باید بگوییم که کم‌کم وبال گردنتان می‌شوند. مثلاً از آنجا که برخی فیچرهای فریمورک‌ها از رده خارج (Deprecated) می‌شوند و یا برخی ملزومات فریمورک‌ها برای اجرای درست مرتفع نمی‌شوند، کدهای به‌جای مانده به نقطهٔ ضعفی برای نرم‌افزار شما تبدیل می‌شوند و این در حالی است که این نقطه ضعف، روزبه‌روز بزرگ‌تر هم می‌شود.

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