يكي از مهمترين نكاتي كه متد XP در طراحي مطرح مي كند اين است كه بخش هايي را كه امروز به آن نيازي نداريد طراحي نكنيد و اينكه اگر بخشي از طراحي پيچيده بود آن را با يك طراحي ساده تر جايگزين كنيد.
مزيت استفاده از روش پيشنهادي XP ، يعني كارتهاي CRC اين است كه باعث مي شود كه افراد از تفكر رويه اي خارج شده و بيشتر به صورت شيء گرا به سيستم نگاه كنند. از كارتهاي CRC براي نمايش يك شيء در سيستم استفاده مي شود. اسم كلاس اين شيء بايد در بالاي كارت نوشته شود. وظايف كلاس در زير و سمت چپ ليست مي شود و كلاس هاي مرتبط با آن نيز در سمت راست كارت نوشته مي شود.
در هنگام تهيه كارتهاي CRC يك نفر سيستم را با حرف زدن راجع به اشياء و ارتباط آنها و با هم شبيه سازي مي كند. در اين ميان اشياء سيستم و ارتباط آنها با هم نمايان مي شود، همچنين وجود نقص و مشكل در فرآيند نيز از اين طريق ملموس تر مي گردد.
در انتخاب نام ها بايد از استعاره هاي سيستم استفاده كرد و تمام نام هايي كه در كارتهاي CRC قرار مي گيرند بايد در استعاره سيستم باشند در غير انيصورت بايد آن را به استعاره سيستم اضافه كرد.
3- كد نويسي [18]
3-1- نوشتن كد تست در ابتدا
وقتي شما پيش از نوشتن كد، تست برنامه را بنويسيد، نوشتن كد بسيار ساده تر و سريعتر خواهد شد. نوشتن كد تست واحد پيش از نوشتن كد برنامه به برنامه نويس كمك مي كند تا دقيقا بداند كه چه كاري بايد انجام دهد.همچنين اين كار باعث مي شود كه به محض اتمام كد شما بازخورد كد را متوجه شويد. همچنين وقتي ما تست را در ابتدا بنويسيم، آنگاه مي توانيم متوجه شويم كه چه موقع كار تمام شده است، كد زماني تكميل است كه تست واحد آن ر 100% تاييد كند. شما ابتدا تست را مي نويسد و سپس كدي مي نويسيد كه اين تست آن 100% جواب بدهد و اين كار را تا زماني انجام مي دهيد كه چيزي براي تست كردن وجود نداشته باشد.
اين كار همچنين كمك مي كند كه شما عملكردهاي اضافي در كد قرار ندهيد و بايد كد را به گونه اي بنويسيد كه تست را 100% قبول كند، اين باعث مي شود كه كد شما كاملاٌ ساده باشد.
3-2- جفت برنامه نويسي [19]
در روش XP هر كدام از كد ها بايد توسط جفت برنامه نويساني كه همراه با هم بر روي يك دستگاه روي كد كار مي كنند توليد شود. تحقيقات تجربي زيادي نشان داده است كه جفت برنامه نويسي منجر به توليد نرم افزار بهتر و يا مشابه ولي با هزينه كمتر نسبت به زماني است كه يك برنامه نويس به تنهايي كد را بنويسد.
جفت برنامه نويسي همچنين باعث مي شود كه كد ها به طور همزمان مرور شوند. همچنين وقتي برنامه نويس حس كند يكي در بالاي سرش كدش را مرور مي كند بيشتر سعي مي كند تا كدش را ابتدا تست كند و به صورت استاندارد بنويسد.
اما در حقيقت برنامه نويسي جفت كار بسيار سختي است، و گزارش ها نشان داده اند كه برنامه نويسان بيشتر از 6 ساعت نمي توانند به صورت جفت برنامه نويسي كنند. اما كاري كه در اين 6 ساعت انجام مي شود داراي كيفيت و راندمان بسيار بالايي نسبت به وقتي است كه دو برنامه نويس به طور همزمان در همان شرايط كار كنند.
3-3- بازتوليد [20]
بازتوليد تكنيكي است براي تغيير ساختار داخلي يك كد، بدون آنكه تاثيري در خروجي آن داشته باشد. در طول چرخه توليد برنامه شايد نياز باشد كه در كدهاي قبلي تغييراتي را به وجود اوريم اين تغييرات مي تواند شامل حذف كد هاي تكراري، ساده سازي كد، حذف توابع غير ضروري و يا تغيير الگوريتم هايي كه قديمي شده و روش هاي جديدي براي آن ايجاد كرده ايم، باشد. اين تغييرات در واقع باعث مي شوند كه برنامه باز توليد شود و ساختار آن تغيير كند اگر چه اين تغيير ساختار تاثيري در عملكرد آن نخواهد داشت. بازتوليد باعث مي شود كه طراحي و كد تا اندازه ممكن ساده بوده و باعث تميز ماندن كدها مي شود تا راحتتر قابل فهم و توسعه باشند.
3-4- يكپارچه سازي كد به طور مداوم و توسط يك جفت برنامه نويس
يكپارچه سازي به هم پيوند دادن كدها و قابليت هاي سيستم براي رسيدن به نسخه نهايي است. در هر مرتبه از يكپارچه سازي نرم افزار به شكل نهايي خو بيشتر نزديك مي شود. فرآيند يكپارچه سازي نيز نيازمند تست واحد است، اين تست قبل و بعد از يكپارچه سازي بايد انجام شود. پيش از يكپارچه سازي براي آنكه از صحت كدهايي كه قرار است يكپارچه شوند اطلاع حاصل كنيم و پس از آن براي انكه از صحت آنها واينكه آيا كدها در كنار هم درست كار خواهند كرد. همچنين در اين مرحله بايد تست مقبوليت نيز انجام شود تا مطمئن شويم سيستم وظايفي را كه بايد در اين مرحله انجام دهد به طور كامل مي تواند انجام دهد. بدون اين كنترل و تست ها ممكن است به مشكلات عديده اي در نرم افزار برخورد كنيم،چرا كه به دليل يكپارچه سازي موازي كدها، تركيبي از كدها به وجود مي آيد كه پيش از اين تست نشده اند.
برنامه نويسان موظفند كه به طور مداوم (بهتر است هر چند ساعت)، و هر وقت كه ممكن بود كدهاي خود را يكپارچه كرده و در منبع كدها قرار دهند. هر جفت برنامه نويس مسئول يكپارچه سازي كد هاي خود هستند. يكپارچه سازي بايد در زماني كه تست واحد 100% تاييد شد و يا در زماني كه بخشي از عملكرد سيستم در برنامه به اتمام رسيد انجام شود. پس از اتمام يكپارچه سازي هر بخش بايد تست واحد مربوطه نيز اجرا گردد تا از صحت يكپارچه سازي و سازش كدها اطمينان حاصل شود.
يكپارچه سازي به طور مداوم از بروز مشكلات عدم سازش كدها جلوگيري مي كند و يا اگر چنين مشكلي وجو داشته باشد كمك مي كند تا سريعتر آن را تشخيص بدهيم.
برنامه نويسان بايد تغييرات را روي آخرين نسخه هر كد بدهند و تغيير بر روي كدهاي كهنه باعث مشكل در يكپارچه سازي مي شود. به همين دليل بهتر است كه در هر لحظه فقط يك جفت برنامه نويس در حال يكپارچه كردن كد هايشان با سيستم باشند اين كار باعث جلوگيري از ناسازگاري در سيستم مي شود.به همين منظور XP پيشنهاد مي كند كه عمل يكپارچه سازي بر روي يك دستگاه كامپيوتر مستقل انجام شود. هر جفت برنامه نويسي كه قصد يكپارچه كردن كد هايشان را با سيستم دارند بر روي آن دستگاه اين كار را انجام دهند و در همانجا تست واحد و مقبوليت را نيز اجرا كرده و اگر به طور 100% تاييد شد، آنگاه تغييرات را نهايي كنند و در غير اينصورت در همانجا رفع عيب كرده و يا كد را براي اصلاح به كامپيوتر خود منتقل كنند. اين كار همچنين كمك مي كند كه بدانيم كدام تيم برنامه نويس در چه زماني كار يكپارچه سازي كدهايش با سيستم را انجام داده است.
3-5- مالكيت جمعي [21]
منظور از مالكيت جمعي اين است كه همه كد ها متعلق به همه تيم برنامه نويسي است. اين امر به تيم كمك مي كند كه با سرعت بيشتري بتواند كارهايش را به پيش ببرد، چرا كه وقتي چيزي نياز به تغيير داشته باشد بدون هيچ تاخيري مي توان آن تغيير را در كد ايجاد كرد.يكي ديگر از مزيت هاي مالكيت جمعي، تقسيم دانش در بين اعضاي گروه است، در اين صورت اگر فردي تيم را ترك كنند، خللي در دانش تيم ايجاد نمي شود.
همچنين هر برنامه نويس مي تواند ايده هاي خود را در مورد هر خط از هر كدام از كدها مطرح كند و تغييرات لازم را روي هر كدي بدهد.
هر برنامه نويس زماني كه كد خود را مي نويسد به همراه آن تست آن واحد را نيز در مخزن كدها اضافه مي كند. مخزن كد ها در اختيار همه برنامه نويسان قرار دارد و همه مي توانند كدهاي ديگران را خوانده و در ساختار كلاس ها و الگوريتم آن تغييراتي را اعمل كنند. در زماني كه مرحله يكپارچه كردن كدها آغاز مي شود، برنامه نويس بايد تغيير در يك كد را اعلام كند.
مالكيت جمعي كدها بدين معناست كه همه برنامه نويسان در مقابل كدها مسئول هستند. در اين صورت همه علاوه بر آنكه در مقابل برنامه مسئوليت دارند نسبت به كل سيستم نيز آگاهي لازم را بدست مي آورند.
يكي از مهمترين كارهايي كه در راستاي مالكيت جمعي در XP انجام مي شود برنامه نويسي جفت است، اما اين كار به تنهايي كافي نيست. تغيير مداوم و زود جفت هاي برنامه نويسي و تغيير تركيب گروه ها ( چند بار در روز اگر امكانش باشد ) يكي ديگر از كارهاي لازم براي كمك به مالكيت جمعي است همچنين دانش و تخصص را به طور يكنواخت در اعضاي تيم بالا مي برد. مالكيت جمعي همچنين باعث مي شود كه يك برنامه نويس در روز فقط بر روي يك بخش كار نكند و اينكار مانع از خسته شدن وي خواهد شد. اين امر كه همه تمام كدها را بدانند باعث مي شود كه مشكلات به وجود آمده در كد نويسي به راحتي قابل حل باشد.
4- تست
4-1- تست واحد [22]
تست واحد يكي از مهمترين اجزاء روش XP است. در تست واحد در روش XP شما بايد چهار چوب تست واحد را ايجاد كرده (و يا آن را دانلود كنيد) در اين صورت قادر خواهيد بود كه مجموعه تست هاي واحد را ايجاد كنيد. سپس شما بايد تمام كلاس هاي موجود در سيستم را تست كنيد و پس از آن كد تست بخش هاي برنامه را بنويسيد تا از روي آن كد بخش مربوطه توليد شود.
تست واحد نيز همراه كد در مخزن كد منتشر مي شود، تا بتوان با آن كد توليد شده را تست كرد. كدي كه تست همراه آن نيست اجازه انتشار ندارد و بايد به سرعت تست مربوط به آن ساخته شود. ساختن تست اتوماتيك در طول پروژه در زمان شما صرفه جويي مي كند و ديگر نيازي نيست كه براي پيدا كردن باگ ها و مشكلات كد ساعت ها وقت صرف كنيد.
تست واحد به مالكيت جمعي كمك مي كند، بدين ترتيب كه وقتي كه كد شما داراي تست واحد مربوط به خودش باشد، ديگر كسي نمي تواند به گونه اي در آن تغيير ايجاد كند، كه در عملكرد كد تاثيري داشته باشد، يعني هر تغيير در كد توسط سايرين بايد به گونه اي باشد كه كد بازهم تست واحدش 100% موفقيت آميز باشد. تست واحد در واقع از كدها محافظت مي كند، و ديگر كدها نيازي به مالك براي محافظت از انها ندارند.
همچنين تست واحد در هنگام بازتوليد كد، كمك مي كند، كه بدانيم تغيير ساختار تاثيري در كارآئي سيستم نداشته باشد. همچنين تست واحد كمك مي كند كه پس از اتمام كد و در صورتي كه تست آن 100% موفق بود، به سرعت آن را با بقيه سيستم يكپارچه كنيم.
گاهي اوقات تغيير در كد، باعث مي شود كه كد تست واحد را نيز تغيير دهيم. اگر اينكار انجام نشود ممكن است كه كد برنامه درست باشد ولي به دليل اشتباه بودن كد تست، و تغيير ندادن آن باعث شود كه تست آن رد شود.
4-2- تست مقبوليت يا تست كارآئي [23]
تست مقبوليت براي اين انجام مي شود كه بدانيم آيا يك سيستم همانطور كه بايد كار مي كند. اگر تست مقبوليت جوابش مثبت باشد در اين صورت نرم افزار شرح كاربري ها را به درستي انجام مي دهد. تست مقبوليت براي تعيين ميزان صحت و دقت و كامل بودن نرم افزار نسبت به آنچيزي است كه در شرح كاربري توضيح داده شده است و توسط سناريوي آن توسط خود مشتري نوشته مي شود و همراه با شرح كاربري ها به برنامه نويس رائه مي گردد.
يك شرح كاربري ممكن است يك يا چند تست مقبوليت داشته باشد. تست مقبوليت نوعي تست جعبه سياه [24] است. هر تست انتظار پاسخ هاي مشخصي را از سيستم دارد. مشتري در قبال صحت و كامل بودن اين تست ها مسئول است و موظف است.
تست هاي مقبوليت، پس از آنكه سناريوي آنها توسط مشتري نوشته شد بايد توسط برنامه نويسان به كد هاي تست اتوماتيك تبديل شوند ، تا بتوان آنها را هر موقع نياز بود به سرعت اجرا كرد. نتيجه تست مقبوليت به تيم ارائه مي شود و تيم موظف است كه براي رفع ان زمانبندي كند.
تضمين كيفيت [25] يكي از مهمترين اجزاء روش XP است. در برخي از پروژه ها يك تيم جدا و مستقل مسئول تضمين كيفيت هستند و در برخي ديگر اينكار بر عهده خود تيم توسعه نرم فزار است. در هر صورت در روش XP بهتر است كه اعضاي تيم در مورد تضمين كيفيت اطلاعات لازم را داشته باشند.
|