لطفا جاواسکریپت مرورگر خود را فعال سازید!

نحوه فعال سازی در کروم
  1. ابتدا باید اینکارو بگنید
  2. بعدش اونکارو
نحوه فعال سازی در فایرفاکس
  1. ابتدا باید اینکارو بگنید
  2. بعدش اونکارو
۸ دلیلی که پروژه‌های نرم‌افزاری با شکست مواجه می‌شوند!

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

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

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

2. عدم لاگ‌گیری
آگاه شدن از همهٔ مشکلات و نواقص برنامه‌ای که نوشته‌اید کار آسانی نیست چراکه برخی از این نواقص و مشکلات ممکن است به‌ندرت رخ دهند آن‌هم درصورت استفاده از موارد خیلی خاص! گرچه ممکن است این توانایی را نداشته باشید که همهٔ مشکلات احتمالی را پیش‌بینی کنید و مانع رخ دادن آن‌ها شوید، اما می‌توانید تلاش کنید تا مطمئن شوید که اگر این مشکلات زمانی رخ دادند، از وجود آن‌ها اطلاع می‌یابید. برای این کار می‌توانید از مکانیسم‌های Exception Reporting استفاده کنید (برای این منظور، می‌توانید از سرویس‌های Airbrake و HockeyApp استفاده نمایید.) 

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

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

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

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

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

5. عدم وجود کدهای حلال مشکل!
هر بخش از یک کد، مخصوص حل یک مشکل است؛ اگر بخواهیم این جمله را به‌صورت ایده‌آل تفسیر کنیم، بایستی بگوییم «هر کد می‌تواند یکی از مشکلاتی که اکنون با آن دست‌وپنجه نرم می‌کنید یا مشکلاتی که ممکن است در آینده با آن‌ها روبه‌رو شوید را حل کند.» اما مشکلات بی‌شماری نیز ممکن است رخ دهند، آن‌ها را چه می‌کنید؟ می‌خواهید برای هر کدام از آن‌ها هم یک کد اختصاصی بنویسید؟

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

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

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

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

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

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

منبع