Antipatterns

1. Antipatterns سمینار درس الگوهای طراحی نرم افزار شی گرا آقای دکتر نورحسینی ارائه دهنده: فاطمه دهشیری زاده

2. پادالگوها • پادالگوها اولین بار توسط Brown و همکاران در سال 1998 ارائه شد. • پادالگوها راه حل های نامناسب برای مشکلات در فرآیند ایجاد نرم افزار است. • پادالگوها نتیجه کار مدیر یا توسعه دهنده ای است که: • اطلاعات کافی برای حل مسئله ای ندارد. • تجربه کافی برای حل مسئله ای ندارد. • یک الگوی مناسب را در جای نامناسبی مورد استفاده قرار می دهند

3. تقسیم بندی پادالگوها • Development Antipatterns • Architectural Antipatterns • Management Antipatterns

4. Development Antipatterns • The Blob • Continuous Obsolescence • Lava Flow • Ambiguous Viewpoint • Functional Decomposition • Poltergeists • Boat Anchor • Golden Hammer • Dead End • Spaghetti Code • Input Kludge • Walking through a Minefield • Cut-And-Paste Programming • Mushroom Management

5. جریان مواد مذاب • کد مرده یا طرح فراموش شده • هنگام ایجاد نرم افزار همه چیز مانند جریان مواد مذاب زنده و قابل تغییر است. • به مرور زمان کدها و طراحی ها اگر درست مستنتد سازی و مدیریت نشوند غیر قابل نگهداری می شوند.

6. دلایل • کدهای Research and Development بدون مدیریت در محصول نهایی قرار داده شده اند. • توسعه کنترل نشده کدی که هنوز تکمیل نشده است. • پیاده سازی چند روش آزمایشی برای پیاده سازی یک متد و حذف نکردن روش های آزمایشی نوشته شده. • گرگ تنها کدنویسی و پیاده سازی کرده باشد. • گرگ تنها فردی است که در تیم به تنهایی طراحی و پیاده سازی می کند و تنها خودش از کد و طراحی خودش سر در می آورد.

7. دلایل (ادامه) • نداشتن مدیریت پیکربندی مناسب • مدیریت پیکربندی در مهندسی نرم افزار، فرآیندی است که طی آن تغییرات دنبال و مدیریت می شوند. معمولا برای مدیریت پیکربندی به یک مخزن محصولات (مانند مخزن کد) نیاز داریم. • نداشتن یا نقص معماری برای طراحی و کدنویسی. • کد های قدیمی حذف نمی شود.

8. راه حل • اصلاح و بازرسی کد و طراحی به منظور بالا بردن کیفیت آن ها. • طراحی معماری مناسب برای کدها و طراحی های نرم افزار. • ایجاد مکانیزم مدیریت پیکربندی برای کنترل تغییرات و نسخه های نرم افزار. • مهندسی مجدد.

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

10. راه حل • سرمایه گذاری مناسب بر روی تست نرم افزار به منظور خطازدایی • استفاده از روش ایجاد مبتنی بر تست. • تولید موارد تست و اجرا و گزارش گیری از آن ها باید اتوماتیک انجام شود.

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

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

13. Architectural Antipatterns • Autogenerated Stovepipe • Stovepipe Enterprise • Jumble • Stovepipe System • Cover Your Assets • Vendor Lock-In • Wolf Ticket • Architecture By Implication • Warm Bodies • Design By Committee • Swiss Army Knife • Reinvent The Wheel • The Grand Old Duke of York

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

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

16. پادشاه قدیمی شهر یورک • تخصیص وزن یکسان به همه افراد تیم در تصمیم گیری ها • تقسیم بندی افراد تیم پروژه • افراد با دید انتزاعی (مناسب برای کشف نیازمندی ها، تحلیل و طراحی معماری) • افراد با دید پیاده سازی (مناسب برای پیاده سازی و تست) • راه حل: • تخصیص نقش های مختلف به افراد برای تصمیم گیری و وزن دهی بیشتر به افراد دارای دید انتزاعی

17. Management Antipatterns • Blowhard Jamboree • Analysis Paralysis • Viewgraph Engineering • Death By Planning • Fear of Success • Corncob • Intellectual Violence • Irrational Management • Smoke and Mirrors • Project Mismanagement • Throw It over the Wall • Fire Drill • The Feud • E-mail Is Dangerous

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

19. مرگ در برنامه ریزی • ادامه پروژه بعد از استخراج برنامه کامل • عدم تغییر برنامه در طول اجرای آن

20. راه حل • برنامه ریزی دقیق برای فاز فعلی و برنامه ریزی تقریبی برای فازهای بعدی • برنامه ریزی بر اساس محصول نه زمان. • بازنگری برنامه ها بر اساس سرعت تیم ایجاد • تعریف Milestone در میانه فازها • قانون اول پارکینسون: یک کار تا زمانی که به آن مهلت داده شود طول می کشد، یعنی زمان انجام یک کار با توجه به مهلت داده شده به آن کش می آید. برای رفع این مشکل کار را به چند قسمت شکسته و برای هر قسمت Milestone تعریف می کنیم.

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

22. ترس از پیروزی • ترس افراد تیم از پایان پروژه یا بخشی از آن. • راه حل: • تعیین مهلت برای هر بخش • مرخصی افراد تیم بعد از اتمام هر بخش

23. مرجع اصلی • Brown, W. J., Malveau, R. C., McCormick, H., Mowbray, T.,Antipatterns: Refactoring Software, Architectures, and Projects in Crisis. Wiley, 1998.

24. با سپاس پرسش و پاسخ