در قسمت اول مقاله آشنایی با متدولوژی XP (Extreme Programming) با تاریخچه، بنیانگذار، ارزش ها و نقش های متدولوژی XP آشنا شدیم. در ادامه قصد داریم تا با 12 عملیات اصلی متدولوژی XP آشنا شویم و همچنین اصول این روش را معرفی نماییم.
12 عملیات اصلی متدولوژی XP:
همانطور که در تصویر پایین مشاهده می نمایید، متد XP در هسته اصلی خود دارای 12 عملیات اصلی می باشد که برای پیاده سازی اصولی این متد با آنها آشنا باشیم.
1- برنامه ریزی بازی ها (Planning Games)
برنامه ریزی در متد XP، برنامه ریزی بازی نام دارد و شامل برنامه ریزی در دو سطح برنامه ریزی انتشار و برنامه ریزی تکرار شونده می باشد، که در هر دو سطح، سه مرحله وجود دارد: اکتشاف، تعهد و هدایت.
در برنامه ریزی انتشار، برنامه نویسان و مشتریان به صورت اشتراکی تصمیم گیری می نمایند که چه نیازمندی ها و الزاماتی را می تواند برای محصول ارائه نمود و این کار را در چه زمانی به صورت تخمینی می توان انجام داد. این مهم بر اساس برآوردها، در نظر گرفتن ریسک ها، اولویت ها و ظرفیت تیم برای ارائه تحویل شدنی ها، انجام می پذیرد. با این حال همانطور که اشاره شد این یک تخمین خام می باشد، بنابراین در ادامه برنامه بر اساس تغییرات، مجدد برنامه ریزی می گردد و یا اصطلاحا تنظیم می شود.
در برنامه ریزی تکرار شونده، اعضای تیم، با ارزش ترین User Story ها را از بک لاگ انتخاب نموده و سپس آن ها را به Task های مختلف تقسیم می نمایند و در ادامه آن ها را برآورد نموده و در نتیجه متعهد می شوند که چه ارزشی در طول تکرار می توانند به صورت بالقوه تحویل دهند.
2- طراحی ساده (Simple Design )
تیم های XP، طرح های بزرگ و معماری های چشمگیر را که ممکن است برای پروژه های بسیار پیچیده چالش باشند را خلق نمی کنند. آن ها با یک طراحی ساده شروع می نمایند و از طریق تکرارها، این طرح ساده را تکمیل می نمایند. همچنین با الزاماتی که دارای تغییرات سریع هستند، هم گام می شوند. در این متد کدها به جهت رهایی از بدهی فنی، بازنویسی می شوند.
حفظ طراحی ساده، گاها کار آسانی نیست. اغلب تیم با عدم اطمینان ها در گزینه های طراحی و پیاده سازی مواجه می شود، خصوصا اگر آن ها از تکنولوژی های جدید استفاده کنند و یا عدم قطعیت بالایی در حوزه تکنیکال داشته باشند. در این زمان، تیم XP یک آزمایش کوچک یا عملیات اثبات مفهوم به نام Spike انجام می دهد. نتیچه Spike در فهم صحت این فرضیه به تیم کمک می نماید. همچنین پیچیدگی راه حل را ارزیابی کرده و برای برآورد و تصمیم در خصوص توسعه یا عدم توسعه آن بر اساس نتایج آزمایش، تصمیم گیری خواهد شد.
3- توسعه آزمون محور (Test Driven Development – TDD)
در متد XP، قبل از تولید کد از عملیات نوشتن آزمون واحد (نوشتن تست) استفاده نمایند. این آزمون واحد، در مرحله ساخت و ادغام به یک شیوه خودکار انجام می شوند.
گام های این روش عبارتند از:
1- نوشتن آزمون واحد که با اجرای آن در شروع موفقیت آمیز نخواهد بود.
2- حداقل مقدار کد برای گذراندن آزمون را بنویسید.
3- حال در گام سوم اقدام به Refactor نمودن کد ها می نماییم و با افزودن کارکرد های مورد نیاز، کد را بازنویسی می نماییم. این گام در حالی انجام می شود که هموارده گذراندن آزمون را تضمین نماید.
مزیت اصلی TDD تضمین گذراندن آزمون می باشد و برنامه نویس می بایست دقیقا به میزانی کد بنویسد تا آزمون پاس شود. و لذا چیزی بیشتر که بی فایده نیز می باشد انجام نخواهد شد.
4- استانداردهای کد (Code Standards)
سازمان‌ها از برنامه‌نویسانشان می‌خواهند که برخی از سبک‌های استاندارد و توصیف‌شده کدنویسی به نام استانداردهای کدنویسی را رعایت کنند. این یک دستورالعمل برای تیم توسعه است، مانند XP. از آنجایی که چندین جفت برنامه نویسی در بازی وجود دارد، استانداردهای کدنویسی برای ایجاد ثبات در کد، سبک، تبدیل نام، مدیریت استثنا و استفاده از پارامترها بسیار مفید هستند.
این استانداردها باید قبل از اینکه تیم کدنویسی را شروع کند، تعریف و توافق شود.
این اصل سبب می شود درک کد ساده شده و به تشخیص سریع مشکل یا مشکلات کمک می کند و همچنین کارایی نرم افزار را افزایش می دهد.
5- بازنویسی کد (Refactoring)
همانطور که از کلمه پیداست، Refactoring بازسازی کدهای موجود است. در XP طی یک دوره زمانی، تیم کدهای کاری زیادی تولید می‌کند و این پیچیدگی را افزایش می‌دهد و باعث بدهی فنی می‌شود. برای جلوگیری از این امر، باید نکات زیر را در نظر بگیریم:
اطمینان حاصل کنید که کد یا توابع تکراری نیستند
از همه متغیرها در محدوده، تعریف شده و استفاده شده اطمینان حاصل کنید
از توابع اضافی یا روش های طولانی جلوگیری شود
حذف موارد و متغیرهای غیر ضروری
استفاده صحیح از اصلاح کننده های دسترسی و غیره
در Refactoring برنامه نویسان به دنبال بهبود کیفیت کلی کد و خوانایی آن بدون تغییر رفتار آن هستند.
6- آزمایشات مشتری (On-site Customer):
همانطور که قبلاً اشاره کردیم، طبق XP، مشتری نهایی باید به طور کامل در توسعه شرکت کند. مشتری باید همیشه برای پاسخ به سوالات تیم، تعیین اولویت ها و حل اختلافات در صورت لزوم حضور داشته باشد.
7- برنامه نویسی دو نفره (Pair Programming):
این عمل مستلزم آن است که دو برنامه نویس به طور مشترک روی یک کد کار کنند. در حالی که توسعه‌دهنده اول روی نوشتن تمرکز می‌کند، دیگری کد را بررسی می‌کند، پیشرفت‌هایی را پیشنهاد می‌کند و اشتباهات را در طول مسیر اصلاح می‌کند. چنین کار گروهی منجر به نرم افزار با کیفیت بالا و به اشتراک گذاری سریعتر دانش می شود، اما حدود 15 درصد زمان بیشتری را می طلبد. از این نظر، منطقی‌تر است که برنامه‌نویسی زوجی را برای پروژه‌های بلندمدت امتحان کنید.
8- یکپارچگی تکراری (Continuous Integration):
توسعه دهندگان همیشه سیستم را به طور کاملا یکپارچه نگه می دارند. تیم‌های XP توسعه تکراری را به سطح دیگری می‌برند زیرا چندین بار در روز کد را commit می‌کنند که به آن تحویل مداوم نیز می‌گویند. متخصصان XP اهمیت ارتباطات را درک می کنند. برنامه نویسان بحث می کنند که کدام بخش از کد را می توان دوباره استفاده کرد یا به اشتراک گذاشت. به این ترتیب، آنها دقیقا می دانند که چه عملکردی را باید توسعه دهند. خط مشی کد مشترک به حذف مشکلات یکپارچه سازی کمک می کند. علاوه بر این، تست خودکار به توسعه دهندگان اجازه می دهد تا قبل از استقرار خطاها را شناسایی و رفع کنند.
9- عرضه های خورد (Small Releases):
این روش پیشنهاد می‌کند که MVP را به سرعت منتشر کنید و محصول را با به‌روزرسانی‌های کوچک و تدریجی توسعه دهید. نسخه‌های کوچک به توسعه‌دهندگان این امکان را می‌دهند که مکرراً بازخورد دریافت کنند، باگ‌ها را زود تشخیص دهند و بر نحوه عملکرد محصول در تولید نظارت کنند. یکی از روش‌های انجام این کار، Continuous Integration است که قبلاً به آن اشاره کردیم.
10- مالکیت جمعی کد (Collective Code Ownership):
این عمل مسئولیت کل تیم را برای طراحی یک سیستم اعلام می کند. هر یک از اعضای تیم می تواند کد را بررسی و به روز کند. توسعه دهندگانی که به کد دسترسی دارند در موقعیتی قرار نخواهند گرفت که مکان مناسبی را برای افزودن یک ویژگی جدید ندانند. این Practice به جلوگیری از تکرار کد کمک می کند. پیاده‌سازی مالکیت کد جمعی (collective code ownership)، تیم را تشویق می‌کند تا بیشتر همکاری کند و در ارائه ایده‌های جدید احساس راحتی کند.
11- استعاده سیستم (System Metaphor):
استعاره سیستم یک داستان همه جانبه است که کل تیم می تواند با آن به منظور ارتباط ساده، طراحی یا معماری ارتباط برقرار کند. در ابتدا طرح و ساختار آن باید برای افراد جدید قابل درک باشد. آنها باید بتوانند بدون صرف زمان زیاد برای بررسی مشخصات، کار روی آن را شروع کنند. دوم، نامگذاری کلاس‌ها و متدها باید منسجم باشد. هدف توسعه دهندگان باید نامگذاری یک شی به گونه ای باشد که گویی از قبل وجود داشته است، که طراحی کلی سیستم را قابل درک می کند. برای درکی بیشتر از از مطلب، استعاره سیستم می تواند یک توافق نام گذاری که در طراحی و کد استفاده می شود نیز باشد، این امر کار را برای هر فردی در تیم راحت می کند و در نتیجه تنها با نگاه کردن به نام یک مولفه‌ی خاص، با کارکرد آن ارتباط بر قرار می شود. به‌عنوان مثال، با نگاه کردن به نام تابع debit_customer_account () می توان حدس زد که از تابع انتظار می رود چه کاری انجام دهد.
12- سرعت قابل تحمل (Sustainable pace) 40-Hour Week
پروژه های XP به توسعه دهندگان نیاز دارند که سریع کار کنند، کارآمد باشند و کیفیت محصول را حفظ کنند. برای رعایت این الزامات، آنها باید احساس خوبی داشته باشند و استراحت کنند. حفظ تعادل بین کار و زندگی از فرسودگی شغلی حرفه ای ها جلوگیری می کند. در XP، تعداد بهینه ساعات کار نباید بیش از 45 ساعت در هفته باشد. یک اضافه کاری در هفته فقط در صورتی امکان پذیر است که هفته بعد وجود نداشته باشد.
هر شرکتی می تواند از اصول XP در پروژه های خود استفاده کند. با این حال، درک هر دو طرف خوب و بد مهم است. در ادامه بخوانید تا متوجه شوید که XP چه تفاوتی با سایر متدولوژی ها دارد و زمانی که استفاده از تکنیک های آن بهترین انتخاب خواهد بود.
پایان مقاله دو قسمتی آشنایی با متدولوژی XP (Extreme Programming)
برای ارتباط با من می توانید در صفحه لینکدین محمد حمیدی پیام بگذارید.
چابک باشید
