قبل از دهه ۲۰۰۰ میلادی توسعه نرم افزار با یک رویکردی آبشاری جلو می‌رفت. این بدان معناست که یک پروژه نرم افزاری بعد از چند پروسه طولانی مانند آنالیز، توسعه، QA و چند مورد دیگر به بازار عرضه می‌شد. این موضوع باعث می‌شد که فرایند توسعه نرم افزار بسیار کند شود و نتیجه کار آنچنان هم مناسب و ایده‌آل نباشد.
امروزه بیشتر پروژه‌ها با رویکردی Agile توسعه داده می‌شوند. این رویکرد از فلسفه‌هایی مانند Scrum یا eXtreme Programming استفاده می‌کند. تمام این موارد باعث می‌شوند که فرایند توسعه نرم افزار بسیار سریع‌تر شود و برای ارائه آن از میانبرهای سریع‌تری استفاده بکنند.
با این حال امروزه نیز شرکت‌هایی پیدا می‌شوند که از روش توسعه نرم افزار به صورت آبشاری بهره می‌برند و باید بگویم که این روش هنوز هم برای اهداف آن‌ها بسیار عالی است.
فرایند آبشاری توسعه نرم افزار همچنین بسیار گران بود. از آنجایی که اینترنت به شکل امروزی توسعه نیافته بود، برنامه‌ها از طریق منابع سخت افزاری مانند دیسک و فلاپی ارائه می‌شدند. از همین جهت هم باید بگویم که معمولا برنامه‌های ساخته شده در روند کار ارتباط مستقیمی با واحد پشتیبانی نداشتند.
اما براساس تجربیات من در کارهای بسیاری که کرده‌ام و مشارکت‌هایی که با تیم‌های مختلف داشته‌ام باید بگویم که کلید اصلی موفقیت برای نرم افزارها متدولوژی آن‌ها که خواه Agile باشد و یا آبشاری نبوده است. بلکه کلید موفقیت در پروسه توسعه اتفاق می‌افتد. برخی از شرکت‌ها چنین پروسه‌ای ندارند و یا از پروسه شرکت دیگری استفاده نمی‌کنند. تنها کاری که آن‌ها انجام می‌دهند دنبال کردن یکسری وظایف است که باعث می‌شود چیزهای جدیدی را از طُرُق قدیمی ارائه کنند.
این پروسه از یک تیم به تیم دیگری، متفاوت بود و معمولا برای پیاده‌سازی یک ویژگی یا پروژه تعداد قدم‌ها یکسان نبود. اما در نهایت تمام این پروسه‌ها یک رفتار مشابه روی شیوه عملکرد تیم‌ها در روند توسعه داشت. به همین دلیل است که شرکت‌ها نباید این کار را انجام دهند.
مستقیما وارد کدنویسی نشوید
به نظر می‌رسد که شگفت زده شدن از ایده‌های جدید و وارد عمل شدن کاری باشد که برای همه امکان پذیر است. مقاومت در برابر این تمایل سخت است.
معمولا افرادی که به این شیوه عمل می‌کنند می‌خواهند خیلی سریع به نتیجه برسند اما این رویکرد مناسبی نیست.
اگر شما با دقت فکر کنید خواهید دید که اگر نیمی از روز را مشغول فکر کردن راجع به یک ویژگی جدید بوده‌اید، طراحی آن می‌تواند چند روز و پیاده‌سازی آن حداقل یک هفته طول بکشد. این موضوع دقیقا همان فلسفه را دنبال می‌کند که می‌گوید: حرف زدن راجع به یک چیز از انجام دادن آن بسیار ساده‌تر است.
تیم‌های عالی زمان کافی را برای آنالیز مشکل‌شان و تعیین یک مسیر برای رسیدن به راه‌حلی مناسب صرف می‌کنند. همیشه باید یک بالانس را نیز برای زمان‌بندی در فاز فکر کردن در نظر بگیرید. با این حال این موضوع کاملا بسته به پروژه‌ای است که در حال پیاده‌سازی آن هستید. تیم‌های خوب همواره قبل از آنکه شروع به پیاده‌سازی یک ویژگی و یا حل کردن یک باگ بکنند به خوبی راه‌حل‌های مناسب آن را طراحی کرده و در ارتباط با آن فکر می‌کنند.
کدهای مرده و یا کامنت شده را قرار ندهید
مدیر پروژه می‌گوید که فلان کدها را حذف کنید دیگر به آن‌ها نیازی نداریم. شما نیز آن کار را انجام میدهید اما بعد از سه چهار روز معلوم می‌شود که به آن قطعه کدها نیاز خواهید داشت. چه کار می‌کنید؟ یک رویکرد همیشه آن بوده که در چنین شرایطی کدها را به صورت کامنت در بیاورید. به نظر نمی‌رسد که کامنت به کسی آسیبی بزند.
اما اینگونه نیست. در مهندسی نرم افزار کامنت کردن کدها مشکلی تکنیکی به نام Technical Debt را بوجود می‌آورد. این مشکل باعث می‌شود که در آینده توسعه‌دهندگان دیگر در غیاب شما با آن کدها مواجه شوند و درگیری پیدا کنند. همچنین فایل‌ها بزرگ‌تر شده و خواندن کدها بسیار عذاب آور می‌شود.
اما با استفاده کردن از رویکردهای مدرن‌تر برای توسعه نرم افزار می‌توانید این مشکل را حل بکنید. استفاده از نرم افزارهای کنترل نسخه مانند گیت یک راه‌حل مناسب برای این کار است. شما هر نسخه نرم افزاری را به صورت کامیت جداگانه‌ای نگه‌داری می‌کنید بنابراین می‌توانید به بهترین شکل ممکن در بین آن‌ها کاوش کرده و تفاوت فایل‌ها را مشاهده بکنید.
جمعه‌ها دیپلوی نکنید
این موضوع را در کالج‌ها و یا دوره‌های آموزشی به شما نمی‌گویند، زیرا این موضوع تنها تجربه است و هیچ استانداردی را دنبال نمی‌کند. با این حال موضوع مههمی است که باید در نظر بگیرید.
دیپلوی کردن یک پروژه گاهی اوقات بسیار پیچیده و عجیب و غریب می‌شود. هیچگاه در روزهای تعطیل و یا عیدها پروژه‌تان را دیپلوی نکنید. فرایند دیپلوی کردن گاهی اوقات نیازمند ارتباط داشتن با بخش سرور و یا افراد مختلف دیگر می‌شود.
همانطور که گفته شد این موضوع استاندارد نیست اما دسترسی پیدا کردن به افراد و شرکت‌ها در روزها و مناسبات تعطیلی بسیار سخت و گاهی اوقات ناممکن می‌شود. به همین دلیل بهتر است که دیپلوی پروژه خود را در روز کاری انجام دهید.
دستی دیپلوی نکنید
Continuous Integration یکی از مهمترین تکنیک‌هایی است که مهندسین نرم افزار باید از آن استفاده بکنند. امروزه توسعه‌دهندگانی را می‌بینیم که از این تکنیک استفاده نمی‌کنند و در نهایت همه فرایندها را به صورت دستی انجام می‌دهند.
این موضوع بهتر است که به شیوه‌ای خودکارسازی شود. در غیر اینصورت زمان زیادی را از شما تلف می‌کند و همچنین پیچیدگی بسیار زیادی را به دوش شما می‌کشد.
از ارزیابی‌های کیفیتی چشم‌پوشی نکنید
پروسه QA در روال توسعه یک نرم افزار بسیار موضوع مهمی است. در واقع این پروسه به شما اطمینان کافی را در این رابطه می‌دهد که همه چیز معتبر و درست است. در این پروسه دو موضوع مهم است که باید آن‌ها را در نظر بگیرید:
- از طریق ارزیابی‌ها مطمئن شوید که کدها به خوبی نوشته شده‌اند.
- مطمئن شوید که کدها هدف شما را به جلو می‌برند.
برای آنکه اعتبارسنجی درستی را پیاده‌سازی کنیم باید مطمئن شویم فردی که کدها را نوشته است با فردی که مشغول اعتبارسنجی آن‌هاست یکی نیست. به این شکل می‌توانید تاثیرات جانبی روی اعتبارسنجی را بردارید.
در پایان: از پروسه توسعه نرم افزار چشم‌پوشی نکنید
استفاده کردن از پروسه دیگر تیم‌ها برای اجرای پروژه خودتان رویکردی مناسب است. اما باید در نظر بگیرید که هر کدام از این پروسه‌ها از یک نقطه‌ای سر چشمه می‌گیرند که شاید با شما سازگاری نداشته باشند. بهتر است در صورتی که می‌توانید پروسه توسعه مربوط به تیم‌تان را به صورت منحصر به فرد طراحی کنید و مطمئن شوید جوانب مختلف تیم تان را در نظر گرفته‌اید. اینگونه می‌توانید مطمئن شوید که در مسیر درستی مشغول حرکت هستید.
دیدگاه و پرسش
در حال دریافت نظرات از سرور، لطفا منتظر بمانید
در حال دریافت نظرات از سرور، لطفا منتظر بمانید