Responsibility-Driven Design و به خصوص تکنیک CRC-Class Responsiblity Collaboration- یکی از ساده‏ترین تکنیکها و روشهای طراحی شیءگرای نرم‏افزار است.

مبدع آن، خانم Wirfs-Brock است. کتاب ایشان با نام Designing Object-Oriented Software منتشر شده به سال 1990، یکی از تأثیرگذارترین کتابهای حوزه طراحی شیءگرا بوده است.

در سایت شرکتشان در مورد ایشان آمده است:

Rebecca Wirfs-Brock, who founded Wirfs-Brock Associates in 1997, is an object technology innovator and pioneer. Having invented Responsibility-Driven Design while at Tektronix in 1990, she has pushed on “object thinking” for the past 15 years.

توصیه می‏کنم کتاب جدیدتر ایشان با نام Object Design: Roles, Responsibilities, and Collaborations را مطالعه کنید. همچنین بد نیست مصاحبه ایشان را در OOPSLA2007 را که بهانه نوشته این مطلب بود، در اینجا ببینید و بشنوید.

گزیده:

Never let a project go somewhere your plan didn’t go a month earlier.
John M. Nevison, 13 Risk Rules for New Project Managers

Over the last decade or two, a philosophy has developed as an undercurrent in the object community. The premise of domain-driven design is two-fold:

• For most software projects, the primary focus should be on the domain and domain logic; and
• Complex domain designs should be based on a model.

Domain-driven design is not a technology or a methodology. It is a way of thinking and a set of priorities, aimed at accelerating software projects that have to deal with complicated domains.

مرجع: http://www.domaindrivendesign.org/
گزیده:

Every project needs an ending, but not every project needs to be started.
John M. Nevison, 13 Risk Rules for New Project Managers

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

از بانیان این کار بزرگ، صمیمانه سپاسگذارم. حق یاورشان.

This webpage is dedicated to pay tribute to the memory of our dear friend, classmate and colleague, Afshin Jafari Mojdehi, who passed away on September, 10th 2003 after three years of courageous battle with Leukemia. He was 29 years old.

Afshin was a researcher and faculty member of IRPD (Institute for Research in Planning and Development) the pioneer center for research and graduate studies of economics in Iran. In IRPD he impressed senior faculty and graduate students with his passion and hard work. The students that attended Afshin’s classes enjoyed having an enthusiastic teacher willing to explore and discuss new horizons in economics theory and applications. In his short time as an economic researcher he participated in several research projects, which resulted in publishing a number of excellent reports and papers, his contribution to the quality of these articles was enormous. He was an extraordinary teacher and devoted researcher.

Afshin came from a small green city in north of Iran. He graduated from Sharif University in Tehran in class of 1997 (1376). He continued his graduate studies in IRPD, where he was invited to stay after graduation. He was a lovely young man, who in any occasion tried his best to make everybody around him happy, life was radiating from him. Decided not to share anything his illness with others, he didn’t mention it to anybody until his last weeks. So it became a shock for many to understand it later.

Now here we are, his friends and colleagues in Iran and abroad, making a pledge to prolong his devotion to the development of economic studies in Iran, in naming an annually award for the best graduate student paper in the field of economics. We know if he were here among us, he would be the most industrious one to pursue this contest, something he would have longed to do. And he is doing it right now, because he inspired many of us in many ways to like economics. To see the details about the prize visit Afshin Jafaris’s Prize Page.

گزیده:
ببار ای ابر بهار
ببار ای باران ببار
با دلم گریه کن خون ببار
دلم خون شد خون ببار
بر کوه و دشت و هامون ببار

به همگی دوستان عزیزم، سلام.

به قول مرحوم حاج قربان سلیمانی، استاد دو تار “گاهی دوتارم با من قهر می‏کند”. گاهی هر چه فکر می‏کنم، حرفی برای گفتم ندارم. انگار وبلاگم با من قهر می‏کند.

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

اگر نظری دارید بفرمایید تا در نهایی‏کردن قالب وبلاگ در نظر گرفته شود.

گزیده:

دندون اسب پیش‏کش رو، در هنگام تحویل می‏شمارند.

خانم مهندس کراری در توضیحی برایم نوشته بودند:
“….ولی قکر میکنم اگر شرکتها و سازمانها به نیروی انسانی به اندازه کافی بها می دادند اوضاع سودآوری شون حتما بهتر از اینی که هست می شد و حداقل می دیدیم که آرزوی هر نیروی IT داشتن یک شرکت مستقل نبود! “

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

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

گزیده:

There is always something for which to be thankful. —Charles Dickens

The Tyranny of Tools

I have seen teams attempt to enforce a style through the use of tools. Some tools are benign and helpful. Many IDEs, for example, allow you to specify things like indent level, brace placement, etc. With a single keystroke you can ensure that a batch of code conforms to the team style. I use tools like this, an depend upon them. I make sure that all the team members set their IDEs to use the conventions.

Other tools can be more intrusive. Some tools can act like compilers, generating errors if the style is not adhered to. Such tools might be useful for an occasional scan of the code; but I think you have to be very careful if you put them into the normal build cycle.

Automatic enforcement is power; and power corrupts. We do not want a well-meaning bureaucrat deciding, one day, to enforce the style that every function argument must have a javadoc comment. This leads to comments of the form: //required comment.

This is not to say that tools like findbugs and checkstyle should be avoided. Indeed, I find them very useful. However, I think they should be run occasionally and manually, not as part of every build. The issues that these tools discover should be dealt with on a case-by-case basis.

Many tools like this allow you to insert special meta-comments that override the warnings. If these tools are placed in the build process; then the code will become cluttered with these meta-comments.

I have a pathological distaste for meta-comments.

Conclusion

Coding style is a matter of team pride and team identity. Teams should be free to adopt their own styles, and to change those styles as the spirit moves them. Each member of the team should follow the team style, and work to ensure that the body of code is a consistent statement of that style. If this sounds too artsy-fartsy, keep in mind that pride of workmanship is a powerful motivator. We want teams to be proud of their creations.

گزیده:

Comments are free but facts are sacred. —Charles Prestwich Scott

Style not Substance

A good coding standard should be about style and form, not about substance. It should not attempt to legislate good design. It should not, for example, proscribe goto or public variables. Those rules are part of the body of knowledge that all software developers should have, and are not a matter of style.

Coding standards should be about the things that don’t matter. They should be about brace placement, naming conventions, the use of blank lines, indentation levels, etc. A coding standard should describe the way code looks, not the substance the code is made from.

It is important to keep style and substance separate because they matter for different reasons. Issues of style matter only for consistency. It does not matter whether your indent depth is 2 or 4, so long as everyone uses the same depth. It does matter if you use public variables inappropriately.

Oral/Code Tradition

Documents that describe coding standards tend to be useless. They often become a bloated battleground for many different competing ideas. My advice is to avoid writing them.

The real document that describes your coding standard is your code. If you want to know how to name a variable, look at how they are named in the code. If you want to know what the standard indent depth is, look in the code. The code is the living document that describes the coding standard.

Oral tradition plays a role as well; especially when communicating issues of substance vs. style. Teams should make use of code reviews and pair programming to communicate with each other about issues of style and substance. New members of the team should have frequent exposure to the more seasoned members, so that the issues of style and substance are inculcated with moral authority. Nothing is quite as persuasive to a young programmer than pairing with the lead programmer and hearing him say: “We don’t do things that way; we do things this way.”

گزیده:

Real seriousness in regard to writing is one of two absolute necessities. The other, unfortunately, is talent. Ernest Hemingway