مشاهده نسخه کامل
: B O L O T
04-06-2007, 22:20
تصور كنيد كه مدير شما صبح روز شنبه به دفترتان ميآيد و از شما مي خواهد برنامه‌اي ساده بنويسيد كه بتواند كاراكترها را از صفحه‌كليد به چاپگر كپي كند. تصور شما از اين برنامه ساده اين است كه مي توانيد آن را در عرض يك ساعت يا كمتر و با حداكثر ده خط كد بنويسيد، ولي ممكن است مسئوليت‌هاي ديگري جز اين كار داشته باشيد.
پس به مدير خود مي‌گوييد طي حدود دو هفته اين كار تمام خواهد شد. اولين كاري كه انجام مي‌دهيد اين است كه طرح اوليه اين برنامه ساده را ترسيم كنيد.
به نظر ميآيد اين برنامه از سه قسمت تشكيل شده باشد: ماجول Copy كه دو ماجول ديگر را فراخواني مي‌كند. اين ماجول كاراكترها را از ماجول ReadKeyboard مي‌گيرد و آن‌ها را به ماجول WritePrinter مي‌فرستد. وقتي اين طرح را ترسيم كرديد، خيالتان راحت مي‌شود و به خود مي‌گوييد: اين برنامه خيلي ساده است و آن را حتي مي‌توانيد سريع به اتمام برسانيد و تحويل مديرتان بدهيد. همان موقع شروع به نوشتن ماجول Copy مي‌كنيد و
پس از نوشتن اين كدها، آن را كامپايل مي‌كنيد و متوجه مي‌شويد كه با موفقيت كامپايل مي‌شود. برنامه را آماده و در محلي ذخيره مي‌كنيد كه آخرين روز هفته به مدير خود تحويل دهيد و به او بگوييد: حتي يك هفته قبل از موعد برنامه آماده شده است. تا اينجا همه چيز به خوبي پيش رفته است.
بعد از چند هفته مدير به شما مراجعه مي كند و از شما مي‌خواهد برنامه كپي را تغيير دهيد. به نحوي كه بتواند اطلاعات را از Paper Tape Reader بخواند. عكس‌العمل شما نسبت به اين تغيير طبيعتاً اين خواهد بود كه اين كار وقت زيادي مي‌برد و در برنامه اوليه اين نياز كاربر در نظر گرفته نشده بود، ولي گريزي نيست و بايد اين كار انجام شود. پس يك آرگومان Boolean به ماجول Copy خود اضافه مي‌كنيم و به برنامه مي‌گوييم اگر اين مقدار صحيح بود، اطلاعات را از Paper Tape Reader بخواند وگرنه، مانند كد 1 از صفحه‌كليد بخواند.
كدهاي 2 قسمت اول، نتيجه اين تغييرات خواهند بود. پس از اعمال تغييرات اين كدها را كامپايل مي‌كنيد و به مدير خود تحويل مي‌دهيد. همه چيز به خوبي پيش مي‌رود، ولي چند هفته بعد باز مدير از شما مي‌خواهد كه برنامه را تغيير دهيد و كاري كنيد كه برنامه كپي خروجي خود را به Paper Tape Punch بفرستد. جواب احتمالي شما به مدير اين خواهد بود كه اين همه تغييرات روي طراحي تأثير خواهد گذاشت و باعث مي‌شود كار نگهداري نرم‌افزار با مشكل روبه‌رو شود، ولي آيا فكر مي‌كنيد اين استدلا‌ل براي مديرتان اهميت دارد؟
خير. از اين رو بايد همان چيزي را كه او مي‌خواهد آماده كنيد. در غير اين صورت، اين مسئوليت به فرد ديگري واگذار خواهد شد. از اين رو باز برنامه را تغيير مي‌دهيم
اگر به ياد داشته باشيد در ابتداي اين نوشته اشكالاتي كه ممكن است در طراحي نرم‌افزار با آن روبه‌رو شويد ذكر شد. آيا فكر نمي كنيد كه برنامه Copy كه در مورد آن صحبت شد، از آن‌گونه نرم‌افزارها باشد؟
حال بياييم با توجه به اصول مدل نرم‌افزاري چابكانه برنامه Copy را بنويسيم. در طراحي چابكانه ممكن است اولين قدم نوشتن كدهاي 1 باشد (البته با استفاده از روش Test Driven Development)، ولي وقتي مدير از شما مي‌خواهد كه برنامه را طوري تنظيم كنيد كه بتواند از Paper Tape Reader بخواند بايد ابتدا طرح خود را با توجه به تغييري كه در نياز كاربر داده شده است، تغيير دهيد.
كد 3 برنامه كپي را با استفاده از مدل چابكانه نشان داده است. به جاي اين‌كه بخواهيم طرح خود را وصله‌كاري كنيم، تا نيازهاي جديد كاربر را تأمين نمايد، تيم برنامه‌نويس بايد طرح خود را به نحوي تنظيم كند كه اين قابليت و امكان را داشته باشد كه در آينده، در صورت نياز، تغيير كند.
طرح اوليه برنامه كه در شكل 1 نشان داده شده است، طرح قابل انعطافي نيست. چون كلاس‌ها مستقل نيستند و كلاس اصلي برنامه به كلاس‌هاي KeyboardReader و PrinterWriter وابسته است. با استفاده از مدل‌هاي Agile بايد اين وابستگي از ميان برداشته شود و در نتيجه تغييرات نتواند بر كلاس Copy تأثيرگذار باشد.
با استفاده از اصولي مانندOpen-Closed Principle) OCP، كه در قسمت‌هاي بعدي كدنبشتهها در مورد آن بحث خواهد شد)، مي‌توانيد طرح خود را به نحوي تنظيم كنيد كه تغييرات روي طرح شما تأثيري نداشته باشد. همان‌طور كه در كد 3 مشاهده مي‌كنيد، براي اين‌كه كلاس خود را در مقابل تغييرات مقاوم سازيم، از كلاس abstract استفاده كرده‌ايم و از الگوهاي Strategy نيز بهره جسته‌ايم.
كد 3
در واقع طراحي چابكانه رويه‌اي است كه با استفاده از الگوها و اصول Agile Development ساختار برنامه را به نحوي طراحي مي‌كند كه برنامه در عين سادگي بتواند قابليت تغييرات احتمالي را نيز داشته باشد. در قسمت‌هاي بعدي كدنبشتهها اين اصول و الگوها مورد بررسي دقيق‌تر قرار خواهد گ
پس به مدير خود مي‌گوييد طي حدود دو هفته اين كار تمام خواهد شد. اولين كاري كه انجام مي‌دهيد اين است كه طرح اوليه اين برنامه ساده را ترسيم كنيد.
به نظر ميآيد اين برنامه از سه قسمت تشكيل شده باشد: ماجول Copy كه دو ماجول ديگر را فراخواني مي‌كند. اين ماجول كاراكترها را از ماجول ReadKeyboard مي‌گيرد و آن‌ها را به ماجول WritePrinter مي‌فرستد. وقتي اين طرح را ترسيم كرديد، خيالتان راحت مي‌شود و به خود مي‌گوييد: اين برنامه خيلي ساده است و آن را حتي مي‌توانيد سريع به اتمام برسانيد و تحويل مديرتان بدهيد. همان موقع شروع به نوشتن ماجول Copy مي‌كنيد و
پس از نوشتن اين كدها، آن را كامپايل مي‌كنيد و متوجه مي‌شويد كه با موفقيت كامپايل مي‌شود. برنامه را آماده و در محلي ذخيره مي‌كنيد كه آخرين روز هفته به مدير خود تحويل دهيد و به او بگوييد: حتي يك هفته قبل از موعد برنامه آماده شده است. تا اينجا همه چيز به خوبي پيش رفته است.
بعد از چند هفته مدير به شما مراجعه مي كند و از شما مي‌خواهد برنامه كپي را تغيير دهيد. به نحوي كه بتواند اطلاعات را از Paper Tape Reader بخواند. عكس‌العمل شما نسبت به اين تغيير طبيعتاً اين خواهد بود كه اين كار وقت زيادي مي‌برد و در برنامه اوليه اين نياز كاربر در نظر گرفته نشده بود، ولي گريزي نيست و بايد اين كار انجام شود. پس يك آرگومان Boolean به ماجول Copy خود اضافه مي‌كنيم و به برنامه مي‌گوييم اگر اين مقدار صحيح بود، اطلاعات را از Paper Tape Reader بخواند وگرنه، مانند كد 1 از صفحه‌كليد بخواند.
كدهاي 2 قسمت اول، نتيجه اين تغييرات خواهند بود. پس از اعمال تغييرات اين كدها را كامپايل مي‌كنيد و به مدير خود تحويل مي‌دهيد. همه چيز به خوبي پيش مي‌رود، ولي چند هفته بعد باز مدير از شما مي‌خواهد كه برنامه را تغيير دهيد و كاري كنيد كه برنامه كپي خروجي خود را به Paper Tape Punch بفرستد. جواب احتمالي شما به مدير اين خواهد بود كه اين همه تغييرات روي طراحي تأثير خواهد گذاشت و باعث مي‌شود كار نگهداري نرم‌افزار با مشكل روبه‌رو شود، ولي آيا فكر مي‌كنيد اين استدلا‌ل براي مديرتان اهميت دارد؟
خير. از اين رو بايد همان چيزي را كه او مي‌خواهد آماده كنيد. در غير اين صورت، اين مسئوليت به فرد ديگري واگذار خواهد شد. از اين رو باز برنامه را تغيير مي‌دهيم
اگر به ياد داشته باشيد در ابتداي اين نوشته اشكالاتي كه ممكن است در طراحي نرم‌افزار با آن روبه‌رو شويد ذكر شد. آيا فكر نمي كنيد كه برنامه Copy كه در مورد آن صحبت شد، از آن‌گونه نرم‌افزارها باشد؟
حال بياييم با توجه به اصول مدل نرم‌افزاري چابكانه برنامه Copy را بنويسيم. در طراحي چابكانه ممكن است اولين قدم نوشتن كدهاي 1 باشد (البته با استفاده از روش Test Driven Development)، ولي وقتي مدير از شما مي‌خواهد كه برنامه را طوري تنظيم كنيد كه بتواند از Paper Tape Reader بخواند بايد ابتدا طرح خود را با توجه به تغييري كه در نياز كاربر داده شده است، تغيير دهيد.
كد 3 برنامه كپي را با استفاده از مدل چابكانه نشان داده است. به جاي اين‌كه بخواهيم طرح خود را وصله‌كاري كنيم، تا نيازهاي جديد كاربر را تأمين نمايد، تيم برنامه‌نويس بايد طرح خود را به نحوي تنظيم كند كه اين قابليت و امكان را داشته باشد كه در آينده، در صورت نياز، تغيير كند.
طرح اوليه برنامه كه در شكل 1 نشان داده شده است، طرح قابل انعطافي نيست. چون كلاس‌ها مستقل نيستند و كلاس اصلي برنامه به كلاس‌هاي KeyboardReader و PrinterWriter وابسته است. با استفاده از مدل‌هاي Agile بايد اين وابستگي از ميان برداشته شود و در نتيجه تغييرات نتواند بر كلاس Copy تأثيرگذار باشد.
با استفاده از اصولي مانندOpen-Closed Principle) OCP، كه در قسمت‌هاي بعدي كدنبشتهها در مورد آن بحث خواهد شد)، مي‌توانيد طرح خود را به نحوي تنظيم كنيد كه تغييرات روي طرح شما تأثيري نداشته باشد. همان‌طور كه در كد 3 مشاهده مي‌كنيد، براي اين‌كه كلاس خود را در مقابل تغييرات مقاوم سازيم، از كلاس abstract استفاده كرده‌ايم و از الگوهاي Strategy نيز بهره جسته‌ايم.
كد 3
در واقع طراحي چابكانه رويه‌اي است كه با استفاده از الگوها و اصول Agile Development ساختار برنامه را به نحوي طراحي مي‌كند كه برنامه در عين سادگي بتواند قابليت تغييرات احتمالي را نيز داشته باشد. در قسمت‌هاي بعدي كدنبشتهها اين اصول و الگوها مورد بررسي دقيق‌تر قرار خواهد گ