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

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

معرفی اشخاصی که ما در این مطلب نظر آنها را بیان می کنیم

اولین نفر Daniel Jacobson می باشد که معاون تیم مهندسی Netflix است و مسئولیت تیم api این شرکت بر عهده او می باشد.

نفر دوم Stefan Estrada است که سرپرست یک تیم پنج نفره از مهندسان کامپیوتر است که در سرویس تلویزیونی OnCue کار می کنند.

سومین نفر از افرادی که ما در این مطلب با آنها صحبت می کنیم Dave Sweeton تکنسین ارشد Stout Systems است که مشاوره های مختلفی را در زمینه تعمیر پروژه های نرم افزاری ارائه می دهد.

وظیفه وصله کردن بخش های یک پروژه نرم افزاری

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

وجود مشکلات در معماری پروژه نرم افزاری

Sweeton از Stout Systems می گوید:  در چنین سناریوهایی می توان مقصران بسیار زیادی را پیدا کرد. در چنین مواردی معمولا مشکل اساسی در معماری نرم افزار می باشد و به همین دلیل فریم ورکی که شما مورد استفاده قرار داده اید از آن چیزی که می خواهید بسازید پشتیبانی نمی کند. این فریم ورک می تواند یا برای شما خیلی کوچک باشد و یا فریم ورک بزرگی برای کاری که می خواهید انجام دهید باشد. بنابراین اولین قدم این است که فریم ورک مناسبی را برای ساخت پروژه نرم افزاری خود انتخاب کنید.

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

مرحله ابتدایی برای حل مشکلات پروژه نرم افزاری

Sweeton می گوید در چنین مواردی شما باید اقدام به refactoring پروژه خود کنید و این اولین گام برای حل مشکلات نرم افزاری شما است.

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

همیشه نیاز به جایگزینی تمامی کدها نیست

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

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

هزینه های مربوط به تعمیر کدها

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

مشکل duplex تصادفی

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

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

در یک پروژه نرم افزاری به فکر اولویت ها باشید

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

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

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

چند نکته مهم درباره معماری پروژه های نرم افزاری

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

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

در زمان اولویت بندی سعی کنید تعیین کنید که امروز یا این هفته چه فعالیت هایی را باید انجام دهید. Jacobson در این باره می گوید: " سوال درست در چنین مواردی از ارزش و اهمیت بسیار زیادی برخوردار می باشد."

از دست دادن توسعه دهنده ارشد در پروژه های نرم افزاری

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

Jacobson می گوید: " اگر یک شخص تمام چیزها را بسازد مشکل از مدیریت است و اگر شما مدیر پروژه نرم افزاری هستید باید بدانید که عملکرد ضعیفی را داشته اید."

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

یک تیم کامل برای انجام پروژه نرم افزاری

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

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

مشکلات مالی برای تعمیر یک پروژه نرم افزاری

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

بهترین راه حل شرایط مالی بد

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

Jacobson می گوید این موضوع کم کم به بازی موش و گربه تبدیل می شود و در نتیجه شما نمی توانید بر روی موضوعات اصلی پروژه نرم افزاری خود تمرکز کنید.

درباره موارد مهم تصمیم گیری کنید

ابتدا سعی کنید تصمیم بگیرید که چه مواردی برای پروژه نرم افزاری شما مهم هستند و اهمیت آنها نسبت به سایر موارد بیشتر است.

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

مراقب پیچیده تر شدن پروژه باشید

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

چه زمانی کل پروژه را از ابتدا بازنویسی کنیم؟

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

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

کدهای قدیمی را کنار بگذارید

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

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

ساخت پروژه های نرم افزاری خیره کننده

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