در ادامه مبحث Agile Software Development يا برنامهنويسي چابكانه كه در شماره قبل (شماره73) به آن اشاره كوتاهي شد، در اين يادداشت مبحث اكسپي كه يكي از روشهاي قدرتمند اين نوع برنامهنويسي است، مورد بررسي قرار ميگيرد. اشتباه نكنيد! منظور از اكسپي ويندوز اكسپي نيست. اكسپي مخفف Extreme Programming يا برنامهنويسي سريع است كه مانند Scrum روشي هوشمند در توليد نرمافزار است. اكسپي شامل يك سري تمرينات ساده و اصول مرتبط به هم است كه وقتي آنها را اجرا و رعايت كنيم، روش اكسپي را انجام دادهايم. شكل 1 اين اصول را نشان ميدهد.
اعضاي تيم در پروژه
در روش اكسپي مشتري نرمافزار بايد جزئي از تيم اجرايي پروژه باشد و برنامهنويس و مشتري بايد با هم كار كنند و از مشكلات و نيازهاي هم مطلع باشند. در اكسپي مشتري به كسي يا گروهي گفته ميشود كه نيازهاي برنامه و اولويتهاي آن نيازها را خوب ميداند. در اين روش مشتري و برنامهنويسان بايد در يك اتاق كار كنند (البته تبصرهاي نيز در اين قسمت وجود دارد كه ميگويد مشتري ميتواند تا حداكثر پنجاه متر از برنامهنويسان دور باشد).
داستانهاي كاربران يا User Stories
براي اينكه بتوانيم براي پروژهاي برنامهريزي كنيم، بايد از نيازهاي كاربران مطلع باشيم. البته نيازي نيست كه همه چيز را از همان اول بدانيم و از جزئيات نيازهاي كاربران اطلاعاتي كسب كنيم؛ زيرا آن جزئيات به احتمال زياد در طول پروژه تغيير پيدا ميكنند. در اكسپي بايد در مورد هر نياز كاربر يا Requirement مقداري با مشتري صحبت كنيم و از مشتري بخواهيم چند كلمهاي در مورد هر يك از نيازها روي فيش يا كاغذهاي يادداشت چسبدار (Post-it) بنويسد. همزمان برنامهنويس نيز ميتواند برداشت خود را از آن موضوع روي كاغذي مشابه بنويسد و هر دو برگه را روي ديوار اتاق بچسبانند. اين برگهها ميتوانند باعث يادآوري اعضاي تيم از نيازهاي اوليه و همچنين سهولت در تخمين زمان و هزينه پروژه شوند.
دورههاي زماني كوتاه
پروژه اكسپي هر دوهفته يك بار يك قسمت از نرمافزار كه كارايي بالايي دارد و قسمتي از نيازهاي اوليه مشتري بوده است را تحويل ميدهد و از مشتري در مورد آن قسمت نظرخواهي ميشود و اگر نياز بود، نظر مشتري سريعاً اعمال ميگردد. به اين دوره دو هفتهاي Iteration نيز ميگويند. هر Iteration قسمتي از نرمافزار را با توجه به User Storiesها توليد ميكند كه چند نياز كاربر را برآورده ميسازد. وقتي يك Iteration شروع شد، ديگر مشتري حق عوض كردن نيازهايي كه بر سر آنها توافق كرده است را ندارد.
تست هاي قبول شده
جزئيات نيازهاي كاربران كه در User Stories وجود دارد، در قالب Acceptance Tests) AT) كه مشتري تعيين ميكند برداشت ميشود. اين تست همزمان با Iteration ميتواند انجام گردد و در قالب زبانهاي اسكريپتي نوشته ميشود تا بتوان آن را چندين بار تكرار كرد. هدف اصلي ATها تست كردن برنامه و حصول اطمينان از اين است كه آن قسمت از برنامه نوشته ميشود كه صددرصد نياز مشتري را برآورده ميسازد.
اين تستها هر وقت كه قسمت جديدي به برنامه اضافه ميشود و برنامه كامپايل ميگردد، دوباره اجرا ميشوند و اگر اشكالي داشته باشند، پيغام خطا ميدهند. در نتيجه وقتي سيستم به اتمام رسيد، ميتوان مطمئن بود كه سيستم بدون خطا است.
به علاوه، در اكسپي تمامي كدها به روش Test-Driven Development توليد ميشوند. يعني قبل از نوشتن هر قطعه كد، بايد تست آن توليد شود و كاري كرد كه كد در پاس كردن Unit Test ناتوان باشد. بدينمعني كه اول يك قطعه كد مثلاً براي افزودن دانشجوي جديد به فهرست دانشجويان مينويسيم، ولي چون در آن كد قطعهاي از كد كلاسي كه insert را انجام ميدهد وجود ندارد، برنامه اشكال ميگيرد. حال كار گروه اكسپي اين است كه برنامه را طوري درست كنند كه اين تست پاس شود و به قدري روي برنامه كار كنند تا برنامه دلخواه به دست آيد.
برنامه نويسي دوتايي (Pair Programming)
معمولاً در اكسپي برنامهنويسان در گروههاي دوتايي قرار ميگيرند و وظيفه تكميل قسمتي از برنامه را به عهده ميگيرند. هر دو برنامهنويس در مورد هر كدام از نيازهاي كاربران با هم بحث ميكنند و قدم به قدم كلاسهاي برنامه را آماده ميكنند. بدين ترتيب كه در ابتدا كلاسي را به صورت خيلي ابتدايي و بدون هيچ طراحي اوليه به وجود ميآورند و اين كلاس را امتحان مي كنند و در صورتي كه اين كلاس فاقد هر گونه اشكال باشد، كد اصلي برنامه را بر اساس اين امتحان كلاس مينويسند. وقتي يكي از برنامهنويسان مشغول نوشتن قسمتي از برنامه است، برنامهنويس ديگر وظيفه كنترل صحت اين كدها را عهدهدار است و در صورت مشاهده هر گونه اشكال، نويسنده كد را مطلع مي كند.