در حال حاضر بیشتر مشاغل در سراسر جهان فعالیت می کنند. و همه چیز خیلی سریع در حال تغییر است. در حال حاضر بیشتر مشاغل در تجارت مدیریت استفاده می شود. اکنون که همه چیز به سرعت در حال تغییر است ، نرم افزار باید توسعه یابد. اما مشکل این است که این نوع نرم افزار در چنین مدت کوتاهی ایجاد نمی شود. معلوم است که پس از ایجاد نرم افزار ، نیازی به آن ندارد.
شرکت ها ممکن است موافقت کنند که این مشکل را حل کنند. آنها می توانند روی تمرکز و نیازهای چاه نرم افزار فشرده شوند. تا بتوانند نرم افزار را به سرعت مستقر کنند. دلیل این امر را می توان استدلال کرد ، همه چیز در حال تغییر است و تجارت دائماً در حال تغییر است ، بنابراین ایجاد یک نرم افزار کامل تقریبا غیرممکن است.
دلیل اصلی توسعه سریع نرم افزار این است که مشتری می داند یا می داند که این نرم افزار چگونه بر زندگی وی تأثیر خواهد گذاشت. به همین دلیل ممکن است این نرم افزار هم موفق باشد یا هم شکست. در این حالت بازخورد مشتری از اهمیت بیشتری برخوردار است. برخی از نرم افزارها وجود دارد که در مشتری مفید است یا چیزی وجود دارد که ممکن است نیاز به تغییر کمی داشته باشد.
این در صورت استفاده از مدل برنامه محور یا آبشار است که اغلب نسبی است ، پس مشتری آن را آزاد می کند.
توسعه سریع نرم افزار نیاز به فرآیند چیزی دارد که با تغییرات به راحتی قابل مدیریت است. تنها راه حل برای این کار توسعه چابک یا روشهای چابک است.
روشهای چابک
روشهای چابک یک روش توسعه افزایشی است ، که در آن افزایش ها کوچکتر هستند و به طور کلی ویژگی های جدید طی 2-5 هفته منتشر می شوند. مشتری در اینجا متصل است و بازخورد آن انجام می شود. بسته به این بازخورد ، ویژگی جدید AD یا قابل جابجایی در نسخه بعدی است.
روش برنامه محور در ابتدا کشف شد ، عمدتاً برای تیم بزرگ. این روش زمان زیادی می برد. روش محور برنامه بهتر است برای طراحی سیستم های مهم استفاده شود. زیرا این روش بیشترین سردرد را در برنامه ریزی ، زرنگ کردن و مستندات دارد. مطمئناً غیر وجود دارد. از آنجا که این سیستم ها کمی بیشتر هستند و آسیب بیشتری می تواند آسیب برساند. تکمیل این امکان پذیر نیست.
استفاده از این روش سنگین باعث ایجاد نوعی آشفتگی در هنگام بروز روش های چابک می شود. چشم انداز روشهای چابک یا آشکار فلسفه درک شده است.
ما با انجام این کار و کمک به دیگران در انجام این کار ، روشهای بهتری برای توسعه نرم افزار کشف می کنیم. از طریق این کار ما به ارزش خود رسیده ایم:
افراد و تعامل در مورد فرآیندها و ابزارهایی که نرم افزار کار می کنند بیش از مستندات جامع همکاری مشتری در مورد مذاکره قرارداد در پاسخ به تغییر در ادامه یک برنامه
یعنی در حالی که در موارد سمت راست ارزش وجود دارد ، ما موارد را در سمت چپ بیشتر ارزیابی می کنیم.
از مانیفست چابک دیدن کنید
تمام روشهای چابک یک چیز را توصیه می کنند تا سریع توسعه و تحویل را انجام دهند. این روش ها به روش های مختلفی کار می کنند ، اما اصول یا اصول موجود یکسان هستند.
روشهای چابک برای توسعه دو نوع سیستم موفق ترین هستند.
- توسعه محصول در حال توسعه یک محصول با اندازه متوسط متوسط برای فروش یک شرکت در آنجا است.
- توسعه سیستم سفارشی برای هر سازمانی
تکنیک های توسعه چابک
روشهای چابک اساساً در دهه نود توسعه یافته است. تغییر در فرهنگ توسعه نرم افزار از طریق برنامه نویسی شدید. در این روش بهترین شیوه ها دنبال می شوند ، توسعه تکرار انجام می شود و توسعه در سطح شدید تحت فشار قرار می گیرد. نسخه جدیدی از یک سیستم در همان روز توسعه یافته ، یکپارچه و آزمایش می شود.
در برنامه نویسی شدید ، الزامات به عنوان سینمای مختلف منتشر می شود ، که در محاسبه وظیفه سری اصلی اجرا می شوند. برنامه نویسان بر اساس این کارها موارد آزمایشی مختلفی را تهیه می کنند و باید این آزمون های نوشتن کد آزمون را پشت سر بگذارند.
از نظر عملی ، می بینید که XP آسان به نظر می رسد ، در واقع یک روند دشوار است. در بیشتر شرکت های اینجا ، این فرایند امکان ادغام وجود ندارد. انواع مختلفی از مشکلات رخ می دهد. مدیریت بیشترین مشکلات بوجود می آید. در حال حاضر بیشتر شرکت ها از اسکریپت استفاده می کنند زیرا این یک تمرکز کامل مدیریت است.
داستانهای کاربر
نیازهای نرم افزاری همچنان به طور مداوم تغییر می کند. برای رسیدگی به این تغییرات ، مهندسی مهندسی نیازهای جداگانه ای از روشهای چابک وجود ندارد. اساساً الزامات هنگام توسعه استخراج می شوند. این چیز “داستانهای کاربر” برای ساده کردن این چیز است. “داستانهای کاربر” سینمایی است که سیستم پس از توسعه کاربر توسعه می یابد.
مشتری و تیم توسعه با بحث و گفتگو با هم در جایی که همه چیز با جزئیات ذکر شده است ، کارت داستان را devolop می کند. کارتهای داستان ممکن است همانند زیر باشد ،
از داستان های کاربر می توان برای برنامه توسعه استفاده کرد ، جایی که کار در این راه انجام می شود. پس از توسعه کارت های داستان ، آنها به یک کار جداگانه تقسیم می شوند. درخواست های اصلی منابع در اینجا تخمین زده می شود و مشتری مورد بحث قرار می گیرد و دیده می شود ، آیا نیاز به ایجاد هرگونه تغییر وجود دارد. وظایف در اینجا به گونه ای تقسیم می شوند که طی 2 هفته می توان آنها را انجام داد.
اگر چیزی تغییر کند ، آنها به نسخه ای اضافه می شوند که 2 هفته بعد به آنها داده می شود. و اگر قبلاً توسعه یافته باشد ، بازخورد مشتری تصمیم می گیرد که آن ویژگی جدید یا آنچه قبلی را داشت ، داشته باشد. و کسانی که نیازی به آن ندارند حذف می شوند.
بزرگترین مشکل داستانهای کاربر در مورد تحقق آن است. درک این مسئله که آیا تمام داستانهای مورد نیاز برای تکمیل یک نیاز کامل سیستم بسیار دشوار است یا خیر. باز هم ، درک این مسئله که آیا فعالیتی در یک سیستم قصه گویی به طور کامل مورد بحث قرار گرفته است ، دشوار است. کاربر غالباً فراموش می کند که چیزهای زیادی را ذکر کند.
تغییر شکل
هدف اصلی مهندسی نرم افزار تغییر در طراحی سیستم است. این سیستم باید به گونه ای طراحی شود که به راحتی قابل تغییر باشد. اصلاح مجدد بدان معنی است که تیم برنامه نویسی پیشرفت های بالقوه ای پیدا کرده و بلافاصله آنها را پیاده سازی می کند.
کسانی از ما ، به ویژه توسعه دهندگان میانه ، بیشتر این کار را انجام می دهند. در ابتدا ، اگر بتوانید آن را حل کنید ، می توان مشکل را حل کرد. سپس وقتی سیستم آماده است ، من شروع به تغییر کمی آنها می کنم (جایی که ممکن است). حتی بسیاری از توسعه دهندگان ارشد این کار را انجام می دهند. در ابتدا کد بد نوشته شده است اما نمی توان آن را بد نامید. زیرا وقتی نسخه اول داده می شود ، شخصی می داند که چند کاربر از سیستم استفاده می کند. و اگر کد بسیار خوبی بنویسید ، هزینه و هزینه زیادی خواهد داشت. به همین دلیل خوب است که این نوع کارها را انجام دهیم.
توسعه افزایشی یک مشکل اساسی است ، در اینجا ساختار سیستم به تدریج به بدتر حرکت می کند. در یک مقطع ممکن است که سیستم دیگر امکان کار نباشد. سیستم اصلاح مجدد مقدار ساختار را افزایش می دهد و آن را به ساختار تبدیل می کند و ساختار با هدف نگه می دارد تا ساختار بدتر نشود.
نمونه های زیادی از اصلاح مجدد وجود دارد. کپی برداری کد حذف ، کد بلااستفاده حذف شده ، ویژگی ناخواسته حذف ، سازماندهی کد و غیره. برای گفتن بهتر ، قسمت های زیادی از کد وجود دارد که برای میله ها استفاده شده است. یک کد کپی شده است. در این حالت ، با استفاده از آن کد A ، کپی برداری کد کاهش می یابد.
توسعه محور آزمایش
توسعه محور تست یا TDD روشی است که در آن پرونده آزمون قبل از اجرای آن نوشته شده است. TDD بخشی از یک برنامه خارج از کشور است. XP برخی از ویژگی های آزمایش را دارد.
- آزمون توسعه اول
- توسعه آزمون افزایشی از سناریوها
- مشارکت کاربر در توسعه و اعتبار سنجی آزمون
- استفاده از چارچوب های تست خودکار
یک نوآوری مهم در توسعه تست یا مهندسی نرم افزار TDD. معمولاً آنچه انجام می دهیم را پیاده سازی می کنیم. سپس پرونده آزمون مورد نیاز برای او را بنویسید. مشکل اینجاست که ما می توانیم بسیاری از موارد را نادیده بگیریم و روی سطح کد تمرکز کنیم ، بسیاری از موارد آزمایش می توانند از بین بروند. در بسیاری از موارد ممکن است بسیاری از اشکالات رخ دهد. تمام موارد آزمون مورد نیاز برای آن قبل از اجرای TDD نوشته شده است. و سپس کد در سطح سطح انجام می شود. شانس یک اشکال کاهش می یابد. رمزگذار نیازی به نگرانی زیاد ندارد. و بزرگترین چیز این است که تا زمانی که از آن عبور کند موارد آزمون به سیستم اصلی اضافه نمی شوند.
مزیت دیگر TDD این است که مشتری را می توان خوشحال کرد. من در کار شخصاً با مشکلات زیادی روبرو شده ام.
“چرا این کار می کند ، چرا کار نمی کند؟ چرا این اتفاق می افتد؟ شب گذشته چه اتفاقی افتاد؟ و غیره.”
من در اینجا اشتباه کردم که نتوانستم داستان او را خوب توضیح دهم. حتی اگر بحث کنید که به چه نوع ویژگی هایی نیاز دارید ، آنها سطح بسیار بالایی داشتند (بالاتر از کد). اگر TDD در اینجا اعمال می شد ، چه اتفاقی می افتاد ، احساس مشتری تغییر می کرد. سپس سخنان او ممکن است به شرح زیر باشد ،
“این ویژگی را نمی توان انجام داد؟ آیا این ویژگی را می توان به سمت بالا پرداخت کرد؟ آیا این ویژگی می تواند دوباره اضافه شود؟”
لحن مشتری تغییر خواهد کرد. از آنجا که وقتی کارت داستان بر روی داستان خود ساخته شد ، مشتری در آزمون نوشته شده است. ممکن است موارد آزمایشی زیادی روی سر وی وجود داشته باشد که به راحتی رئیس توسعه دهنده نخواهد بود. اگر اتفاقی بیفتد ، مشتری فرصتی برای سرزنش نخواهد داشت. چون خودش بود. و بنابراین تمام شرایط برآورده می شود ، به این معنی نیست که مشکلی وجود ندارد. کد برای افزودن با سیستم اصلی آماده است.
اتم تست برای TDD بسیار است. آزمایشات نوشته شده است که قبل از ایجاد مؤلفه ها اجرا شود. این موارد آزمون باید متمایز باشد تا ورودی به راحتی آزمایش شود. تست باید به صورت خودکار انجام شود که در صورت تغییر ، آزمایش شروع شود. اگر نتیجه مثبت باشد ، اجازه داده می شود به سیستم اصلی اضافه شود یا اگر نه ، دوباره کد کنید.
برخی از مشکلات در TDD وجود دارد.
- برنامه نویس در اولویت آزمایش قرار می گیرد ، اما در بسیاری از موارد او هنگام نوشتن یک آزمون از آزمون استفاده می کند. در این مدت بسیاری از موارد آزمایشی اجتناب می شود. در این حالت ، باگ در منحصر به فرد دیده می شود.
- برخی از تست ها وجود دارد که نوشتن آن بسیار دشوار است.
بسیاری از موارد آزمون در TDD نوشته شده است. اما دشوار است که بگوییم پرونده آزمایش قادر به پوشش کل سیستم است.
برنامه نویسی
بنگالی جفت یک جفت است. هنگامی که دو برنامه نویس در حال برنامه نویسی در یک رایانه با هم هستند ، آن را برنامه نویسی جفت می نامند. شما یک شریک متحد برای انجام یک کار خواهید داشت. با این حال ، این جفت هر بار به صورت پویا ایجاد می شود.
برخی از مزایای برنامه نویسی جفت وجود دارد.
- مالکیت جمعی: سیستمی که همه به طور همزمان کار می کنند ، بنابراین مالکیت سیستم همه است. هیچ کس نمی تواند کسی را سرزنش کند. مسئولیت یا مسئولیت همه.
- بررسی های غیررسمی: از آنجا که یک جفت وجود دارد ، کد به یک بررسی آگاهانه تبدیل می شود. بسیاری از خطاها می توانند قبل از اضافه شدن سیستم از اینجا به وجود بیایند. اگر این فرآیند طولانی شود ، روند توسعه در معاملات ایجاد می شود.
- تجدید نظر را تشویق می کند: نوشتن کد به خودی خود به معنای این نیست که می توان در اینجا تحت تأثیر قرار گرفت. و جزئیات دیگر را نگویید. حال اگر یک جفت وجود داشته باشد ، بحث بین این دو می تواند کارهای زیادی انجام دهد.
هرکسی در اینجا فکر خواهد کرد که برنامه نویسی جفت بهتر از برنامه نویسی نیست. در حقیقت ، کدی که این دو به روش های مختلف می توانند متفاوت بنویسند ، در برنامه ریزی جفت نیمی از آنها خواهد بود. بسیاری از شرکت ها وجود دارند که از برنامه نویسی جفت استفاده می کنند تا در این مورد شک و تردید داشته باشند و دیگر از آن استفاده نمی کنند. با این حال ، برنامه نویس ارشد ویژه همراه با برنامه Junior کار می کند.
برنامه نویسی جفت مناسب ترین برنامه نویسان جوان و میانه است. اما استدلال یک بار برای برنامه نویسان سطح ارشد نیست. این باعث می شود بهره وری آنها تا حد زیادی کاهش یابد.
زمینه های برنامه نویسی جفت هنوز در ویژه استفاده می شود. با این حال ، اکثر شرکت ها نمی خواهند از آن استفاده کنند.
ادامه یابد …
