دسته: Agile

Many Eyes

When the Declaration of Independence was still a draft, Benjamin Franklin, sitting beside Thomas Jefferson, revised Jefferson’s wording of “We hold these truths to be sacred and undeniable” to the now-famous phrase, “We hold these truths to be self-evident.” According to biographer Walter Isaacson, Jefferson was distraught by Franklin’s edits. So Franklin, aware of his friend’s state, sought to console Jefferson by telling him the tale of his friend John Thompson.

John had just started out in the hat-making business and wanted a sign for his shop. He composed his sign like so:

Before using the new sign, John decided to show it to some friends to seek their feedback. The first friend thought that the word “hatter” was repetitive and unnecessary because it was followed by the words “makes . . . hats,” which showed that John was a hatter. The word “hatter” was struck out. The next friend observed that the word “makes” could be removed because his customers would not care who made the hats. So “makes” was struck out. A third friend said he thought the words “for ready money” were useless, as it was not the custom to sell hats on credit. People were expected to purchase hats with money. So those words were omitted.

The sign now read, “John Thompson sells hats.”

“Sells hats!” said his next friend. “Why, nobody will expect you to give them away. What then is the use of that word?” “Sells” was stricken. At this point there was no use for the word “hats” since a picture of one was painted on the sign. So the sign was ultimately reduced to:

In his book Simple and Direct, Jacques Barzun explains that all good writing is based upon revision [Barzun]. Revision, he points out, means to re-see. John Thompson’s sign was gradually revised by his friends, who helped him remove duplicate words, simplify his language, and clarify his intent. Jefferson’s words were revised by Franklin, who saw a simpler, better way to express Jefferson’s intent. In both cases, having many eyes revise one individual’s work helped produce dramatic improvements.

The same is true of code. To get the best refactoring results, you’ll want the help of many eyes. This is one reason why extreme programming suggests the practices of pair-programming and collective code ownership [Beck, XP].

Refactoring to Patternsمنبع :

“brown-bag session” – روز آزاد


“Don’t share what you know—keep it to yourself. It’s to your advantage to be the Smart One on the team. As long as you’re smart, you can forget about those other losers.”


Your team has developers with different capabilities, experience, and skills. Each person has different strengths and expertise. That mix of diverse talents and backgrounds makes it an ideal environment for learning.

On a team, it’s not enough if you personally know a lot. If other members of your team are not as knowledgeable, the team isn’t as effective as it could be: a well-educated team is a better team.

While working on projects, you need to use terms and metaphors to clearly communicate your design concepts and intent. If most members of your team are not familiar with these ideas, it will be hard for you to be effective. Also, suppose you’ve taken a course or gone to a symposium. You generally lose what you don’t use. You need to bring what you have learned into your team. Share it with the rest of the team when you get back.

Find areas where you, or someone in your team who is knowledgeable, can help the rest of the team come up to speed (this has the added advantage that you can discuss how topics apply specifically to your applications or projects).

A “brown-bag session” is a great way to share knowledge in a team. Pick a day of the week, for instance Wednesday (generally any day other than Monday and Friday works well). Plan to get together over lunch so you don’t have to worry about running into other meetings or getting special permission. Keep the cost low by having folks bring their own lunch (in a brown bag, of course).

Each week, ask one member of your team to lead the discussion. He or she will present some concepts, demo a tool, or do just about anything that’s of interest to the team. You can pick a book and go through some specific sections, items, or practices from it.2 Do whatever works.


Is Everyone Better Than You? Good!

Legendary jazz guitarist Pat Methany offers this advice: “Always be the worst guy in every band you’re in. If you’re the best guy there, you need to be in a different band. And I think that works for almost everything that’s out there as well.”

Why is that? If you’re the best on the team, you have little incentive to continue to invest in yourself. But if everyone around you is better than you are, you’ll be keenly motivated to catch up. You’ll be on top of your game.

 Plan to start with the person leading the session that week speaking for fifteen minutes or so. Then you can open the topic for discussion so everyone can present their ideas and discuss how the topic might be relevant to your projects. Discuss benefits, provide examples from your own applications, and plan to get follow-up information.

These brown-bag sessions can be very valuable. It raises the industry awareness of the whole team, and you can personally learn a lot from them as well. Wise managers tend to value team members who raise the value of other members, so presenting can directly help your career, as well.


Raise the bar for you and your team. Use brown-bag sessions to increase everyone’s knowledge and skills and help bring people together. Get the team excited about technologies or techniques that will benefit your project.

 What It Feels Like

It feels like everyone is getting smarter. The whole team is aware of new technology and starts pointing out how to apply it or points out pitfalls to watch for.

Keeping Your Balance

• Reading groups that go through a book chapter by chapter are very helpful, but pick good books. Learning XYZ in 7 Days with Patterns and UML is probably not a good book.

• Not all the topics will be winners or even seem appropriate at the moment. Pay attention anyway; it wasn’t raining when Noah built the ark.

• Try to keep it in the team. A catered lunch in the auditorium with PowerPoint slides loses some of the intimacy and discussion opportunities.

• Stick to a regular schedule. Constant, small exposure is agile. Infrequent, long, and drawn-out sessions are not.

If some team members balk at coming to the lunch, bribe them with pizza.

• Stretch beyond purely technical books and topics; pertinent nontechnical topics (project estimation, communication skills, etc.) will help the team as well.

• Brown-bag sessions aren’t design meetings. Overall, you want to focus on discussing general topics that are relevant to your application. Solving specific issues is usually better left to a design meeting.

brown-bag session” با نام های مختلف در منابع مختلف آورد شده است، اما نامی که من خودم آنرا دوست دارم و در بعضی ار منابع نیز ذکر شده است، “روز آزاد ” می باشد. البته می توان روز آزاد را به دو قسمت تقسیم کرد، نیمه اول روز را برای مباحث علمی و جدید اختصاص داد، که هدفش بالا بردن سطح دانش تیمی و به اشتراک گذاشتن دانش بین اعضاء تیم می باشد. و نیمه دوم روز را برای تفریح و سرگرمی، که می تواند هدفش بالا بردن سطح روحیه و نشاط افراد تیم باشد. نظر شما درباره روز آزاد چیست؟ آیا یک چنین روزی می تواند در فرهنگ ما جا باز کند یا نه؟ 

(رنگ قرمز در متن شخصیت منفی، رنگ سبز در متن شخصیت مثبت)

مالکیت جمعی (Collective Ownership)

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

مالکیت جمعی! با شنیدن این اصطلاح چیز خاصی به ذهن شما راه می یابد، یا نه؟  اولین باری که در مورد این موضوع بحث می کردیم اولین چیزی که به ذهن من راه یافت، سایت ویکی پدیا بود. تصور کنید که شما می خواهید روی موضوع خاصی تحقیق کنید وارد این سایت می شود، یک جستجو روی سایت انجام می دهید و وارد یکی از صفحاتی که در لیست جستجو وجود دارد می شوید، حال شما می توانید صفحه مورد نظر را مطالعه کنید، ویرایش کنید مانند آنکه سایت یا وبلاک خودتون را ویرایش می کنید، شما مالک آن صفحه هستید، نه تنها شما بلکه من و هر کس دیگری نیز به اندازه شما مالک آن صفحه است و حق دارد صفحه مورد نظر خود را اصلاح کند یا صفحه ای جدید به آن بیافزاید. اما شما فقط مالکیت آن صفحه را ندارید، با ویرایش آن صفحه، شما دانش خود را با دیگران به اشتراک می گذارید و با دیگران شریک می شوید همانگونه که دیگران اینکار را انجام می دهند. این یعنی مالکیت جمعی، یعنی توزیع دانش با کمترین هزینه و توسط تمام افراد.

این قسمت از این کد را من ننوشتم کار بهروز است. این جمله یا مشابه آنرا احتمالا هنگامیکه یک خطا در کد سیستم آشکار می شود زیاد شنیدید. شاید بعد از ساعت ها بحث هیچ کس مسئولیت نوشتن آن کد را قبول نکند. یا فکر کنید که قسمتی از کد برنامه توسط کسی نوشته شده است و آن فرد الان شرکت را ترک کرده است و نمی توانید به آن دسترسی پیدا کنید و نیاز هست که در قسمتی از آن کد تغییراتی داده شود، و دیگر برنامه نویس ها می گویند که ما اصلاً از شیوه کار این آقا سر در نمی آوریم. حالا باید چیکار کنم آن قسمت از کد را از اول باید نوشت. نه، باید به دنبال یک فکر اساسی بود تا دیگر با چنین مشکلاتی برخورد نکنیم. مالکیت جمعی پاسخ مشکل ما است.

در مالکیت جمعی تمامی کدها متعلق به کل تیم برنامه نویسی است، و هر کس می تواند هر قسمتی از کد را در هر زمانی که نیاز باشد تغییر دهد، این تغییر می تواند به دلیل بهبود کیفیت کد باشد یا به خاطر یک خطا در برنامه یا تغییر در سیستم.  اینکار باعث افزایش سرعت توسعه سیستم خواهد شد، برای نمونه یک قسمت از کد نیاز به تغییر دارد، و برنامه نویس آن کد در دسترس نیست و یا در برابر تغییرات مقاومت می کند، شما اگر از مالکیت جمعی استفاده کنید به آسادگی هر عضو دیگری از تیم می تواند آن تغییرات را اعمال کند. اگر ما از برنامه نویسی دونفره (برنامه نویسی جفتی) استفاده کنیم، و زوج ها متناوبا تغییر کنند، این باعث خواهد شد که دانش در کل تیم منتشر شود و همه می توانند با کل سیستم آشنا شوند، حالا اگر یک نفر برای همشه تیم را ترک کند مشکلی نخواهد بود چون هر عضو تیم مالک کل کدها است و با نحوه کار همه افراد تیم آشنایی دارد. یکی از روشهای افزایش کارائی تیم ها متنوع کردن فعالیت های اعضاء تیم می باشد، شما با برنامه نویسی دونفره و مالکیت جمعی می توانید روی قسمت مختلف کار کنید. این باعث متنوع شدن فعالیت های شما می شود و باعث افزایش کارائی و نشاط در تیم می شود. اینها نمونه های از مزیت های مالکیت جمعی بودند، شما هم می توانید نظرات خودتون را در این مورد بنویسید، تا دیگران را در آنها شریک کنید.

برنامه نویسی دونفره (pair programing)

شاید شما هم یک یا چند دوست صمیمی داشتید یا دارید که با هم پشت یک کامپیوتر نشستید و برنامه های متنوعی را نوشتید، و از این کار لذت برده اید، اما شاید در آن لحظات متوجه نشده اید که شما در حال یکی از تکنیک های XP به نام برنامه نویسی دو نفره هستید.

برنامه نویسی دونفره، نوعی از برنامه نویسی است که دو برنامه نویس باهم و در کنار هم پشت یک کامپیوتر می نشینند و بر روی یک قسمت از کد برنامه، طراحی و یا تست نرم افزار کار می کنند. یکی از جفت ها که کد برنامه را تایپ می کند یا مستندات مربوط به طراحی را می نویسد را راننده (driver) می نامند. فرد دیگر را هدایت کننده (navigator) می نامند که کارهای راننده را نظارت می کند و سعی می کند اشکلات او را کشف کند. خطاهای مانند syntax errors، فراخوانی یک تابع به صورت اشتباه، پیاده سازی یک الگوریتم به شیوه ناکارا و ….  در واقع از بعد دیگر می توان گفت  در برنامه نویسی دو نفره، افراد مختلف با دانش ها و مهارت ها مختلف می توانند مهارتشان را ترکیب کنند تا یک مسئله مشکل را حل کنند. فرض کنید شما کسی هستید که مهارتتان در پایگاه داده در سطح عالی هست و دوست شما کسی که در برنامه نویسی شی گرا مهارت خیلی زیادی دارد در اینصورت شما می توانید کدی را بنویسید که به صورت بهینه و کارا به پایگاه داده دسترسی پیدا کند.

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

1.       کیفیت: در این شیوه ما کدی با کیفیت بالا خواهیم داشت چون اکثر خطاها و اشتباهات در همان مرحله اول تشحیص داده می شود.

2.       صرفه جویی در زمان: چون ما کدی با کیفیت بالا خواهیم داشت، زمان تست و تغییرات در سیستم کاهش خواهد یافت.

3.       افراد شاد: برنامه نویس های که با این تکنیک کار می کنند، اکثرا خوشحالتر و شادتر از زمانی هستند که به تنهایی کار می کنند. برای نمونه شما فشار کمتر را تحمل می کند چون همیشه کسی را در کنار خود دارید که به شما کمک کند و این باعث می شود که شما خیلی خوشحالتر باشید.

4.       اعتماد و روحیه همکاری بالا: در این شیوه شما تک و تک افراد تیم خود را به خوبی خواهید شناخت و باعث می شود که شما به آنها اعتماد کند و روح همکاری بخاطر شناخت عمق افراد بالا برود.

5.       دو نفر همیشه بهتر از یک نفر است.

6.       یادگیری و انتقال دانش : فرضی کنید شما دیروز در مورد یک موضوع جدید چیزهای را یاد گرفته اید، امروز صبح به زوجتان آن مورد را توضیخ می دهید و او را نیز با موضوع آشنا می کنید، سپس زمانیکه زوج ها بعد از مدتی عوض می شوند، شما به آن فرد جدید، و زوج قبلی شما به زوج جدیدش آنرا توضیح می دهد و شما هنگام ناهار خواهید دید که کل تیم شما با موضوع جدید آشنا شده است. واقعاً جالب نیست.

7.       مالکیت جمعی (این گزینه یکی از نقاط مورد علاقه من است و بعداً در یک پست مجزا آنرا بررسی خواهیم کرد.)


(بقیه برای قسمت دوم، انگیزه من برای نوشتن این مطلب حضور یکی از دوست های خوبم در شرکت بود که مرا به یاد ترم های اول دانشگاه و برنامه های که با هم پشت یک کامپیوتر نوشتیم انداخت  ولی من هنوزم آرزو کار مشترک با ایشان را دارم. ولی فکر کنم باید این مطلب را یک ویرایش اساسی کنم و دوباره پست کنم. موفق باشید.)

حق با مشتری است یا نه؟

کاربران نرم افزار واقعاً افراد مبتدی هستند، آنها هیچ اطلاعات در مورد نرم افزار ندارند، تمام اعتراضات آنها بخاطر عدم دانش و … کاربران هست و سیستم عملکرد درستی دارد. جملاتی مانند جملات بالا و حتی بدتر از آنها را بارها در محیط کار خود شنیده و یا به زبان آوردیم. ولی واقعا اینگونه است یا نه؟ ما چقدر باید به اعتراضات کاربران خود گوش دهیم؟

چند روز قبل برای رفع مشکل در سیستم نرم افزاری یکی از مشتریان به شرکت آنها رفته بودم، تقریبا اولین باری بود که بخاطر اینکار به یک شرکت مراجعه می کردم، و همین کار دلیلی برای نوشتن این مطلب شد. شرکت مورد نظر فکر کنم تقریبا همزمان با ورود من به رشته نرم افزار، از نرم افزار مورد نظر استفاده می کند یعنی چیزی نزدیگ به 5 سال. ولی چیزی که برای من جالب بود، سوالات بسیار ساده و پیش پا افتاده آنها در مورد نرم افزار بود که از من می پرسیدند. سوالاتی که فکر می کردم هر کسی بعد از چند ماه استفاده از نرم افزار باید خودش در جواب دادن به آنها استاد باشد (کاربران نرم افزار مورد نظر در طول این چند سال تغییر نکرده اند.!). گفتم حق با نرم افزاریها است که اغلب اعتراضات کاربران را نادیده می گیرند(حداقل در گروههای که من از نزدیگ آنها رادیده ام). ولی یک چیز باعث شد که فورا تغییر عقیده بدهم. یک متن که تازه توی یک EBook خوانده بودم، سعی می کنم بعد از این  همیشه با این موضوع به این صورت برخورد کنم. متنی را که گفتم در کتاب Practices of an Agile Developer خوانده بودم که در پایین عین متن را آوردم. فقط چند قسمت از این کتاب را مطالعه کردم کتاب بسیار جالبی بود، و از همه زیباتر شیوه نگارش کتاب بود، در کل کتاب از دو شخصیت استفاده شده است چیزی شبیه سوژه های کارتونی یک شخصیت مثبت (یک فرشته که شیوه صحیح را نشان می دهد) و یک شخصیت منفی که شیوه اشتباه برخورد با مسئله را نشان می دهد.(جملات قرمز توصیه شخصیت منفی است و جملات سبز توصیه شخصیت مثبت است).

Listen to Users


Users are always complaining. It’s not your fault; they’re just too stupid to read the stinkin’ manual. It’s not a bug; they just don’t understand. They should know better.”

Andy once worked for a large company that developed products for high-end Unix workstations. This wasn’t the sort of environment where you could just run setup.exe or pkgadd to install the software. You had to copy files and tune various settings on your workstation.

Andy and his team thought everything was going well, until one day Andy was walking past the tech support area and overheard a support engineer laughing loudly into the phone: “Oh, it’s not a bug; you made the same mistake everyone does.” And it wasn’t just this one engineer.

The whole department was chuckling at the poor, naïve, stupid customers.

Apparently there was a situation where you, the hapless customer, had to go tweak some obscure system file to contain a magic value, or otherwise the application would not run at all. No error message, no crash, just a big black screen followed by an abrupt exit. Granted, a line in the installation instructions mentioned this fact, but apparently some 80% of the customers missed that fact and had to instead submit to abuse via the company’s tech support line.

Whether it’s a bug in the product, a bug in the documentation, or a bug in our understanding of the user community, it’s still the team’s problem, not the user’s.

Then there was the case of the expensive manufacturing shop-floor control system that none of the users would use. It seems the first step to using the system was to log on with their name and password, and the majority of the workers in this plant were illiterate. No one have ever bothered to ask them or get their feedback, so a completely useless system was installed. (The developers in question had to retool the entire GUI to be picture-based at huge expense.)

We go to great lengths to get feedback from code using unit tests and such, but it’s all too easy to ignore the feedback from users. So not only do you need to talk to real users (not their managers or a surrogate

such as a business analyst), you need to listen to them.

Even if they sound stupid.

Every complaint holds a truth. Find the truth, and fix the real problem.

What It Feels Like

You don’t get irate or dismissive of stupid complaints; you can look past that and see the real, underlying problem.

Keeping Your Balance

• There is no such thing as a stupid user.

• There is such a thing as a stupid, arrogant developer.

• “That’s just the way it is” is not an answer.

• If the code can’t be fixed, perhaps the documentation and training

can be.

• Your users may have read all the documentation and will remember everything about your application all the time.

But probably not.

در پایان از همه دوستان بخاطر دیر به دیر آپ دیت شدن معذرت می خام، واقعا باور کنید فشار کار خیلی زیاد است و دلیلش هم خیلی ساده است: عدم رعایت زمانبندی، مدیریت اشتباه و …. از طرف دیگر فقط 2 ماه به کنکور مانده و من تازه می خام شروع به خواندن کنم و از همه اینها بدتر فقط یک ماه از فرجه 6 ماه مانده و احتمالا تا چند ماه بعد باید برم خدمت مثلا مقدس سربازی. از همه بدتر قضیه دنبال دار پروژه … می باشد، که واقعا نمی دانم دیگر باهاش چیکار کنم و تقریبا وقتی یادم می افته یا از طرف آنها تماس می گیرند کلاً انرژیم تخلیه می شه (نمی دانم یک پروژه مگه می تونه چقدر از زمانبندی عقب بیفته  چند هفنه، چند ماه، یک سال و چند ماه !!!!). دعا کنید ….

اصل (DRY (Don’t Repeat Yourself

داشتم برنامه را برای اصلاحات نهایی مرور می کردم، یک چیز جالب توجهم را به سوی خودش جلب می کند، بعضی از قسمت های برنامه ها (کد برنامه) به طور تکراری در چند جا وجود دارد بدون هیچ دلیل منطقی و توجیه پذیر. کمی فکر می کنم و به بررسی قضیه می پردازم قضیه از این هم بدتر است خیلی موارد دیگر نیز وجود دارد که به صورت تکراری در مستندات و موارد دیگری مربوط به پروژه وجود دارد. به دنبال دلیلی برای این کار می گردم اولین دلیلی که به ذهنم می رسد و تا حد زیادی قابل قبول هست تنبلی هست زمانهای زیادی وجود دارد که می خواهیم کار را در حداقل زمان ممکن انجام دهیم یا در یک بازه زمانی کم که ممکن است دلایل زیاد داشته باشد می خواهیم کار را به پایان برسانیم و با کپی یک قسمت موجود از کد برنامه و یا هر منبع دیگر و با دستکاری کمی در آن به هدف خود می رسیم و در آن لحظه احساس رضایت و خوشحالی می کنیم  ولی بعد از مدتی یک تغییر همه چیز را به هم می زند و ممکن تک تک قسمت های کپی شده را تغییر دهیم و اینجاست که باید دوباره دوباره احساسمان را بپرسند.

یک دلیل دیگر که می تواند قابل قبول باشد این هست که در یک پروژه چندین نفر بر  روی قسمت های مختلف نرم افزار کار می کنند و تکرارهای فرضا در کد برنامه به صورت غیر عمدی رخ می دهد که بسته به نوع تیم نرم افزاری می تواند کشف این افزونگی سخت یا آسان باشد. فرض کنید که ما از تکنیک های برنامه نویسی XP استفاده می کنیم و تیم های دو نفره تشکیل داده ایم که افراد در تیم ها به طور مستمر با هم تعویض می شوند و شاید در یک تیم تقریبا متوسط در پایان روز همه افراد تجربه کار را با یکدیگر خواهند داشت در این حالت احتمال کشف تکرارها به سادگی و شاید در حداقل زمان ممکن وجود داشته باشد(اتفاقی که خیلی برای خودم  رخ می دهد). اما فرض کنید در یک ترکیب تیمی که افراد تعامل کمی با هم دارند و هر کس وظیفه خاص را دارد در اینصورت کشف تکرارها به احتمال زیاد مدت زمان زیادی را می خواهد.

 اما یک دلیل که فکر کنم ریشه روانشناسی هم داشته باشد در سالهای اول دانشگاه بوجود می آید و بعدها بعضی ها نمی توانند ترک کنند. شاید جملاتی مانند این که پروژه من چند هزار سطر شد و یا شبیه آن برای خیلی از دوستان آشنا باشد. جملاتی که در ترمهای اول دانشگاه تکرار می شود و تعداد سطرها بدون توجه به هر اصل دیگر، عامل اصلی برتری یک پروژه در بین گروه خاص از دانشجویان می شود. و سپس بعضی از دوستان نمی توانند از دام این عامل برتری خلاص شوند. و اغلب مشکلاتی که بخاطر این مسئله در برنامه هایشان بوجود می آید را با جملاتی مانند اینکه پروژه در این حجم (از لحاظ تعداد سطرها) نگهداریش واقعا مشکل و کار هر کسی نیست و … را تکرار می کنند. و صدها دلیل کوچک و بزرگ می توان پیدا کرد که می تواند عامل مشکل بالا باشد. اما برای رفع این مشکل بد نیست که یک اصل را به نام DRY (Don’t Repeat Yourself ) را مرور کنیم.

تعریف اصلی DRY

DRY: Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.

ترجمه جمله بالا به عهده دوستان، چون هر چقدر زور زدم یک جمله خوب که مفهوم را به طور کامل در داخل خودش داشته باش بسازم دیدم با یک جمله نمی شه.

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

class Line {


Point start;

Point end;

double length;


تکه کد بالا را در نظر بگیرید، فکر می کنید مشکلی روی این کد وجود دارد یا نه. شاید در نگاه اول این کد مشکل نداشته باشد اما در این تکه کد اصل DRY رعایت نشده است. صفت length را در نظر بگیرید، مقدار این صفت با توجه به مقادیر start و end محاسبه می شود و با تغییر هر کدام از این صفات، آن نیز تغییر می کند (همیشه این نوع تکرار کد را با افزونگی در پایگاه داده مقایسه می کنم و می کویم صفتی که  قابل محاسبه از روی صفات دیگر باشد، نیازی به ذخیره سازی ندارد. می شود نرمالسازی در پایگاه داده را مفهومی مشابه این اصل دانست). پس بهتر است این تکه کد به صورت زیر تغییر کند.

class Line {


Point start;

Point end;

double length() { return start.distanceTo(end); }



می توانیم به سادگی راه حل های زیادی برای رهایی از این دام پیدا کنیم و فکر می کنم نیاز زیادی به بحث روی این موضوع نیست، البته پیشگیری مثل همیشه بهترین شیوه درمان است. اما دوست دارم ادعای جالبی که آقایان  Andy Hunt و  Dave Thomas(اصل DRY، برای اولین با توسط این دو نفر ارائه شده است.) رابیان کنم و دوست دارم نظر شما را در مورد این ادعا بدانم. به نظر شما مرحله نگهداری یک برنامه  از چه زمانی شروع می شود؟ نمی دانم دقیقا پاسخ شما چیست، اما پاسخ دو نفر بالا به این صورت است که برنامه نویسان همیشه در مرحله نگهداری هستند.  و تنها در 10 دقیقه اول یعنی زمانیکه شما برای اولین با یک تکه کد را تایپ می کنید در مرحله نگهداری قرار ندارید و سپس شما بارها و بارها یک تکه کد را تغییر می دهید تا به هدف خود برسد و اینها جزء مرحله نگهداری هستند. حال نظر شما چیست؟


اصل open-closed

یک توسعه دهنده نرم افزار باید همیشه یک چیز را در ذهنش داشته باشد، در غیر اینصورت باید هزینه زیادی را متحمل شود یا حتی بدتر، باید شاهد مرگ محصولش باشد. تغییر.

مهم نیست که شما کجا کار می کنید، روی چه محصولی کار می کنید و با کدام زبان برنامه نویسی، برنامه نویسی می کنید. یک چیز، همیشه می تواند رخ بدهد. تغییر.

تنها یک چیز تغییر نمی کند. تغییر.

تغییر در کل چرخه حیات نرم افزار با ما خواهد بود. حتی می توان گفت که تغییر است که باعث تولد و مرگ  یک نرم افزار می شود. پس نرم افزاری که ما باید طراحی و پیاده سازی کنیم، باید در مقابل تغییرات، دارای انعطاف زیادی باشد. و برای اینکار ما باید از همان ابتدای چرخه حیات مراقب و آگاه باشم تا طراحی خود را به شیوه ای انجام دهم تا در مقابل تغییرات کمترین هزینه سربار را متحمل شویم. یکی از اصول که می تواند ما را در این کار کمک کند و به بررسی آن خواهیم پرداخت، اصل open-closed می باشد. تقریبا کل این اصل بر تغییر تکیه دارد، اما تغییری که، نیاز به دستکاری کد موجود ندارد. اما چگونه در پایین به بررسی این موضوع خواهیم پرداخت.

اصل open-closed

موجودیت های نرم افزاری برای نمونه کلاس ها، توابع و پیمانه ها باید برای توسعه باز باشند(اجازه داشته باشند)، اما برای تغییر باید بسته باشند(اجازه تغییر را ندارند).

یک تشبیه زیبا(فکر می کنم به زبان اصلی خیلی زیباتر است.)

Code should be closed(to change) like the lotus in the evening. Yet open(to extension) like the lotus flower in the morning.

ما گفتیم که سیستم ها تغییر می کنند، ولی می خواهیم که کدهای نوشته شده خود را در برابر این تغییرات محافظت کنیم، و همچنین سیستم نرم افزاری خود را کسترش دهیم، شاید در ابتدا دو چیر کاملا مغایر به نظر رسید. اما ما به هر دو مورد نیاز داریم. تصور کنید که مشغول حل یک مسئله هستید، آیا می توانید تمام موارد جزئی و کلی آن را به طور کامل در نظر بگیرید، نیازمندیهای متفاوت مشتری ها و تغییرات نیازمندیها را به طور کامل پیش بینی کنید؟ مسلما جواب نه است. پس ما باید با دانش فعلی سیستم خود را طراحی کنیم، اما طراحی که قابلیت توسعه داشته باشید با کمترین هزینه دستکاری سیستم موجود.

فرض کنید که شما یک نرم افزاری نقاشی ساده می خواهید طراحی کنید که قابلیت رسم شکلهای مختلف را داشته باشد.

یک طراحی می تواند به این صورت باشد که شما یک کلاس Shape تعریف می کنید، که اشکال دیگر از آن کلاس به ارث می برند، و یک کلاس دیگر مثلا با نام DrawManager تعریف می کنید که لیست اشیاء را نگهداری می کنید و مسئول رسم اشکال مختلف بر روی صفحه نمایش است. مثلا متدی یا نام DrawAllShape داریم که با توجه به هر نوع هر شکل تابع مخصوص رسم ان شکل را فراخوانی می کند. در این متد ما کدی شبیه کد پایین خواهیم داشت.

If TypeOf S Is Circle Then


ElseIf TypeOf S Is Triangle Then



End If

بعد از مدتی نیاز پیدا می کنیم که اشکال جدید را به برنامه اضافه کنیم. برای اینکار ما کلاس های جدید را به برنامه اضافه می کنیم، و می رسیم به نقطه منفی کار، ما باید در کلاس DrawManager تغییرات انجام دهیم، متدهای جدیدی را باید به این کلاس اضافه کنیم تا رسم اشکال جدید را انجام دهد و کد متد DrawAllShape را تغییر دهیم تا در صورت وجود شکل های جدید، آنها را رسم کند. بعد از مدت متد DrawAllShape پر از جملات شرطی خواهد بود و همچنین تعداد زیادی متد خواهیم داشت که مدیریت و تغییر این کلاس را مشکل خواهد کرد.

حالا تصور کنید که کلاس انتزاعی یا یک اینترفیس به نام Shape تعریف کرده ایم که دارای یک متد به نام Draw می باشد، و تمام اشکال این متد را به ارث می براند و متد Draw را بازنویسی می کنند. در این حالت هر شکلی  جدیدی به برنامه اضافه شود، کلاس shape را به ارث می برد و متد Draw را بازنویسی می کند و نیازی نیست که در کلاس DrawManager تغییری ایجاد کنم و این کلاس، تنها متد Draw هر شکل را برای رسم آن شکل فراخوانی می کند. همانطوریکه مشاهده کردید ما در این حالت در کد مربوط به هیچ یک از کلاس های موجود تغییری ایجاد نکردیم اما برنامه خود را توسعه دادیم.

در بسیاری از الگوهای طراحی یکی از مهمترین ویژگیهای که در نظر گرفته شده است، اصل open-closed می باشد. برای نمونه می توانید الگوی TEMPLATE را بررسی کنید. ما باید بعضی از تغییراتی که می تواند در سیستم رخ دهد را، پیش بینی کنیم و با استفاده از مفهوم abstractions از سیستم خود در مقابل این تغییرات حفاظت کنیم. در واقع می توان گفت که کلید اصل open-closed دو مفهوم abstractions و encapsulation می باشد.