اين موضوع، عنوان مقاله‏ای از مارتين فاولر به سال 2004 است. مشغول بررسی مطلبی بودم که آن را مجدداً خواندم. در اصل اين مقاله همان طور که خود فاولر ذکر کرده، به بررسی نقدی که به روس اکس-پی وارد شده پرداخته است. هر چند که اين بررسی بسيار آموزنده و مفيد است، اما بخش اول آن که بررسی دو روش طراحی برنامه‏ريزی شده و طراحی تکاملی می‏پردازد، نکات ظريفی را بيان داشته که هر روز با آن مواجه هستيم و حتی هر يک از ما برای دوری از آن، روشهایی نيز به تجربه برای خود تبیین کرده‏ايم. به لحاظ اهميت اين نکات، بخش اول مقاله را به همان صورت در زير آورده و آدرس مقاله را نيز در ادامه ذکر کرده‏ام.

Planned and Evolutionary Design

For this paper I’m going to describe two styles how design is done in software development. Perhaps the most common is evolutionary design. Essentially evolutionary design means that the design of the system grows as the system is implemented. Design is part of the programming processes and as the program evolves the design changes.

In its common usage, evolutionary design is a disaster. The design ends up being the aggregation of a bunch of ad-hoc tactical decisions, each of which makes the code harder to alter. In many ways you might argue this is no design, certainly it usually leads to a poor design. As Kent puts it, design is there to enable you to keep changing the software easily in the long term. As design deteriorates, so does your ability to make changes effectively. You have the state of software entropy, over time the design gets worse and worse. Not only does this make the software harder to change, it also makes bugs both easier to breed and harder to find and safely kill. This is the “code and fix” nightmare, where the bugs become exponentially more expensive to fix as the project goes on.

Planned Design is a counter to this, and contains a notion born from other branches of engineering. If you want to build a doghouse, you can just get some wood together and get a rough shape. However if you want to build a skyscraper, you can’t work that way – it’ll just collapse before you even get half way up. So you begin with engineering drawings, done in an engineering office like the one my wife works at in downtown Boston. As she does the design she figures out all the issues, partly by mathematical analysis, but mostly by using building codes. Building codes are rules about how you design structures based on experience of what works (and some underlying math). Once the design is done, then her engineering company can hand the design off to another company that builds it.

Planned design in software should work the same way. Designers think out the big issues in advance. They don’t need to write code because they aren’t building the software, they are designing it. So they can use a design technique like the UML that gets away from some of the details of programming and allows the designers to work at a more abstract level. Once the design is done they can hand it off to a separate group (or even a separate company) to build. Since the designers are thinking on a larger scale, they can avoid the series of tactical decisions that lead to software entropy. The programmers can follow the direction of the design and, providing they follow the design, have a well built system

Now the planned design approach has been around since the 70s, and lots of people have used it. It is better in many ways than code and fix evolutionary design. But it has some faults. The first fault is that it’s impossible to think through all the issues that you need to deal with when you are programming. So it’s inevitable that when programming you will find things that question the design. However if the designers are done, moved onto another project, what happens? The programmers start coding around the design and entropy sets in. Even if the designer isn’t gone, it takes time to sort out the design issues, change the drawings, and then alter the code. There’s usually a quicker fix and time pressure. Hence entropy (again).

Furthermore there’s often a cultural problem. Designers are made designers due to skill and experience, but they are so busy working on designs they don’t get much time to code any more. However the tools and materials of software development change at a rapid rate. When you no longer code not just can you miss out on changes that occur with this technological flux, you also lose the respect of those who do code.

This tension between builders and designers happens in building too, but it’s more intense in software. It’s intense because there is a key difference. In building there is a clearer division in skills between those who design and those who build, but in software that’s less the case. Any programmer working in high design environments needs to be very skilled. Skilled enough to question the designer’s designs, especially when the designer is less knowledgeable about the day to day realities of the development platform.

Now these issues could be fixed. Maybe we can deal with the human tension. Maybe we can get designers skillful enough to deal with most issues and have a process disciplined enough to change the drawings. There’s still another problem: changing requirements. Changing requirements are the number one big issue that causes headaches in software projects that I run into.

One way to deal with changing requirements is to build flexibility into the design so that you can easily change it as the requirements change. However this requires insight into what kind of changes you expect. A design can be planned to deal with areas of volatility, but while that will help for foreseen requirements changes, it won’t help (and can hurt) for unforeseen changes. So you have to understand the requirements well enough to separate the volatile areas, and my observation is that this is very hard.

Now some of these requirements problems are due to not understanding requirements clearly enough. So a lot of people focus on requirements engineering processes to get better requirements in the hope that this will prevent the need to change the design later on. But even this direction is one that may not lead to a cure. Many unforeseen requirements changes occur due to changes in the business. Those can’t be prevented, however careful your requirements engineering process.

So all this makes planned design sound impossible. Certainly they are big challenges. But I’m not inclined to claim that planned design is worse than evolutionary design as it is most commonly practiced in a “code and fix” manner. Indeed I prefer planned design to “code and fix”. However I’m aware of the problems of planned design and am seeking a new direction.

آدرس مقاله:

http://martinfowler.com/articles/designDead.html

گزیده:

She said that she usually cried at least once each day not because she was sad but because the world was so beautiful and life was so short.
Brian Andreas – Reference: Booch Blog

حکایت زير را دوست خوبم، آرش، برايم فرستاده که بسيار آموزنده است. حيفم آمد، در اينجا نياورمش.

روزي روزگاري يه خري افتاد توي يه چاه و شروع کرد به عرعر کردن که منو در بيارين ..يالا. کشاورزي که صاحب اين خر عرعرو بود، خيلي سعي کرد که يه کاري بکنه . ولي نشد که نشد . خره رفته بود ته چاه و در نمي يومد . عرعرش هم قطع نميشد . آقا کشاورزه با خودش فکر کرد که خوب اين چاهه رو خيلي وقته که ميخوام پٌٍرش کنم ، خره هم که پيره و ارزش اين که بخوام بيارم بيرون و دوا درمونش کنم نداره، پس بيخيال خر. کشاورزه از همه همسايه هاش خواست که بيان و بهش کمک کنن . اونام هر کدوم يه بيل آوردن و شروع کردن خاک ريختن تو چاه. خره که فهميده بود چه بلايي داره به سرش مياد.شروع کردعرعرهاي جانسوز سر دادن. از همون هايي که دل هر خري کباب ميشد از شنيدنش . پس از يه مدت کوتاهي يهو ساکت شد جوري که همه تعجب کردند. ولي بازم چند تا بيل ديگه خاک ريختن و ديدن نخير صدا از ديوار در مياد ولي از آقا(يا خانوم) خره نه. کشاورزه يه نيگاهي تو چاه کرد ببينه چي شده که هيچ خبري از عرعره خره نيست که ديد . عجب خر پر آي _کيويي بوده . اين خره و تا حالا استعدادش کشف نشده بوده. هر بيل خاکي که تو چاه ريخته ميشده . مي ريخته پشت کمر خره . اونم خودشو مي تکونده و ميرفته روش مي ايستاده مث پله.هر چي کشاورز و همسايه هاش خا ک مي ريختن تو چاه، خره خودشو تکون ميداده و مي رفته روشون مي ايستاده و هي يه پله بالا ميومده تا اين که رسيد به سر چاه و يه جفتکي زد و خندون شروع کرد يورتمه رفتن. به اين ميگن خر.

زندگي هر روز ممکنه خيلي مشکلات براي شما به همراه داشته باشه مث همون بيل هاي خاک . مصائب از همه طرف رو سرتون هوار بشه . ولي اين که بتونين پيروز از تو چاه مشکلات در بياين که مشکلات رئ سعي کنين از رو دوشتون بر دارين و يه قدم و پله بياين بالاتر.
ما ميتونيم از عميق ترين چاه هاي زندگي هم به سلامت خارج بشيم به شرطي که از هر مشکلي يه تجربه و نردبون بسازيم براي پيشرفت و شکوفايي. هر کدوم از مسائل زندگي ميتونه به مثابه يه پله و وسيله اي براي رسيدن به هدف نهايي ما باشه. فقط نا اميد نشو و از تلاش دست بر ندار . خودتو بتکون و يه پله برو بالاش.

گزيده:
آدم مؤفق کسی است که با تکه آجرهايی که به سمتش پرتاب می‏شود، خانه‏ای برای خود می‏سازد.

ماهنامه Rational Edge مقاله نسبتاً جالبی در مورد نحوه تحقق‏بخشی موارد کاربرد در شماره اخير آورده است. مهمترين بخش آن آورده Best Practice هايی در اين مورد است که عبارتند از:

* Design use-case realizations in team sessions.
* Communicate design ideas using interaction diagrams.
* Apply design and responsibility patterns.
* Code responsibility abstractions during design sessions.
* Get clearance before making major design changes.
* Audit changes that occurred during design implementations.

آدرس مقاله به شرح ذيل است. http://www.ibm.com/developerworks/rational/library/jun07/cuellar/index.html

گزیده:

Sometimes i wish that i had never met you, so i could go to sleep at night not knowing there was someone like you out there.
– from Good Will Hunting movie

بالاخره ويرايش سوم کتاب “تحليل و طراحی شیءگرا با کاربردها” از پير دنيای مهندسی نرم‏افزار، گريدی بوچ به بازار آمد. واقعاً بيراه نگفته‏ام، که اين کتاب، کتاب مقدس علاقمندان به شیءگرايی در دهه آخر قرن بیستم و حتی بعد از آن بود. نسخه اول آن سال 1991 و ويرايش دوم آن در سال 1994 به بازار آمد. نسخه اول آن را از آقای مهندس رامين عرفانيان دريافت کردم. فوق‏العاده پرمحتوا، سخت و جذاب.
ويرايش جديد آن با اضافاتی که در پايين آمده، همراه بوده است. خبر نسخه جديد آن را اولين بار در وبلاگ دوست عزيز، آقای مهدی خواجه ديدم و فی‏الفور آن را تهيه و مطالعه کردم. مطالعه آن را از دست ندهيد.

• An introduction to the new UML 2.0, including the notation’s most fundamental and advanced elements with an emphasis on key changes

Aspect Oriented شايد يکی از قشنگترين بحثهای نسبتاً جديدی است که در حوزه مهندسی نرم‏افزار ارائه شده است. هر چند نمی‏توان در اينجا خيلی درباره آن صحبت کرد، ولی ذکر مثال ساده‏ای از آن خالی از لطف نيست.

اگر خيلی ساده بخواهم آن را توضيح دهم شايد بهتر است بگويم که در دنيای شیءگرايی، اشيا به صورت ايستا همديگر و محيطشان را می‏شناسند. يکی از عوامل تغيير نرم‏افزار تغيير اين ساختار ايستا مثلاً محيط است. می‏خواهيم با اين رويکرد کاری کنيم که اشيای نرم‏افزاری از محيطی که در آن استقرار می‏يابند، بی‏اطلاع باشند.

چون نتوانستم کد مثال را در اينجا قرار دهم، دو آدرس زير را از اينترنت پيدا کرده و در زير آورده‏ام.

Developing a Simple Aspect

Hello World (AspectJ) –

نکته: حتی اشيا هم دارند ياد می‏گيرند که جنبه داشته باشند.
گزيده:

“Oh yes, the past can hurt. But, you can either run from it or, learn from it.”

– from The Lion King

بعضی اوقات در زندگی اتفاقاتی می‏افتد که مفاهيم رنگ کاربرد به خود می‏گيرند و آنگاه است که مفاهيم بازتعريف می‏شوند.
يادم است زمان دانشجويی‏، جزوه گرفتن از همکلاسی، عبارت بود از به امانت گرفتن جزوه، کپی‏برداری يا تصحيح جزوه شخصی از روی آن. اواخر ترم جاری ايميلی روی گروهی که دانشجويان درس شیءگرایی، آقای صبوريان و من عضو آن هستيم، ارسال شده بود که عنوان آن “جزوه” بود. ايميل شامل فايل pdf که اسکن شده جزوه يکی از دانشجويان بود که برای ساير دانشجويان ارسال کرده بود. باور کنيد آن قدر موضوع برايم جالب بود که مدت زيادی به اين موضوع فکر کردم که چگونه تکنولوژی و ابتکار، مفاهيم را بازتعريف و مسائل را به شکل ديگری حل می‏کنند و چقدر ما به دليل “شرطی شدنمان” قدرت ابتکارمان را از دست داده‏ایم.

گزیده:

Worrying is like a rocking chair it gives you something to do, but doesn’t get you anywhere.

– Van Wilder

روزی با يکی از دوستانم قرار داشتم. قرارمان عصر بود. دوستم با يک ساعت تأخير آمد. گفتم چطور شد که دير کردی؟ گفت صبح يک ساعت ديرتر از منزل بيرون آمدم، تمامی کارهای من از صبح به اندازه يک ساعت با تأخير شروع شده است.
حکايت من هم در اين دو هفته همين بود. برای انجام کاری، دو روز روال عادی زندگی، دستخوش تغيير شد. به مدت دو هفته، به دنبال اين بودم که چرخ‏دنده‏ها به جای اولشان برگردند! نمی‏دانم چقدر با نظريه آشوب (Chaos) آشنا هستيد. می‏گويند قرن بيستم تحت تأثير سه نظريه بوده است. نظريه نسبيت انشتين، نظريه عدم قطعيت هايزنبرگ و نظريه آشوب. طبق اين نظريه، همه چيز در آشوب است. بنابراين دنبال تعادل گشتن، خيلی منطقی نيست. اما اين گونه سيستمهای دارای الگوهای خودمانا هستند، بنابراين تنها کاری که بايد انجام داد، اين است که الگوها را در آن بيابيم و ديگر هيچ.

گزيده:

Life moves pretty fast. If you don’t stop and look around once in a while, you could miss it.

– from Ferris Bueller’s Day Off