Битва гигантов Spolsky vs Robert Martin

Интересное пришло сообщение от Асхата. Гиганты программирования и гуру всего и вся столкнулись в битве за TDD и PPP.

Начало положил подкаст Scott Hanselman. Не нам их судить, но ряд цитат приведу:

Spolskyit seems to me like a lot of the Object Oriented Design principles you're hearing lately from people like Robert Martin and Kent Beck and so forth have gone off the deep end into architecture for architecture's sake.

Kent Beck: He has worked hard to become famous, but he hasn’t figured out that along with notoriety comes responsibility. He is a bright, experienced guy and certainly capable of more accurate, thoughtful, and constructive conversation.

На что ответили все мною почитаемые гуру: Кент Бек, Рон Джефрис.

В общем не понятно, почему Спольски подлил эмоционального огня. Видать его книги стали плохо продаваться. И по его выпадам видно, что он не читал книгу Роберта Мартина, и подавно Кента Бека. Жаль там очено много идей на фоне которых его эмоции просто детский лепет... Но устами младенца :)

К слову:
Роберт Мартин - человек, который собрал ребят в далеком 2001 году и они сделали AgileManifesto. Он так же автор книги про PPP. В ней кстати достаточно ошибок и приколов, которые мы очень хорошо обсудили и посмаковали над Design Patterns Study Group.
Кент Бек - стоял в основе Desing Patterns и идеи wiki-сайтов. Автор eXtreme Programming.

Сопротивляемость изменениям или про тюрьму опыта

Просто приведу цитату, которая просто вызывает благоговенный лепет в моей душе:

Идея о тюрьме впервые была исследована Платоном в «Республике» в знаменитой аллегории пещеры, где Сократ рассуждает о связи видимости, реальности и знания. Перед входом в подземную пещеру пылает костер. В пещере находятся люди, закованные цепями и лишенные возможности двигаться. Они видят только ту стену пещеры, что прямо перед ними. Она освещена пламенем, и тени людей и предметов видны на ней. Обитатели пещеры думают, что тени - реальность, дают им имена, говорят о них и даже связывают звуки, доносящиеся снаружи, с движением теней на стене. Истина и реальность для пленников заключаются в этом мире теней, поскольку они не знают другого.
Однако, считает Сократ, если бы одному из жителей пещеры позволили покинуть пещеру, он понял бы, что тени - всего лишь отражение более сложной реальности, а знания и восприятия его товарищей неверны и искажены. Если бы он вернулся потом в пещеру, он никогда уже не смог бы жить по-старому, поскольку для него мир был бы уже другим. Несомненно, ему трудно было бы смириться со своим затворничеством и стало бы жалко других пленников. Однако если бы он попытался поделиться с ними своим новым знанием, его, вероятно, осмеяли бы. Для пленников знакомые образы пещеры имели бы гораздо большую значимость, чем тот мир, который они никогда не видели. Более того, поскольку человек, получивший новое знание, больше уже не сможет функционировать с прежней убежденностью относительно теней на стене, его сотоварищи, скорее всего, посчитают внешний мир опасным. Это происшествие приведет к тому, что они станут жестче придерживаться знакомого образа мыслей.
Герет Морган. Образы Организации. с.235

И в продолжение к сравнению не-Agile подхода и Agile подхода: многие пытаются устранить неопределённость и защититься от неё через предварительное проектирвоание, детальное изучение требований и анализ. Agile же состоит в том, чтобы учиться на неопределнности и лавировать в её условиях. Аналогичную метафору можно проследить в западном подходе производства (предотвращения через накопление и буфферизацию на складах) и японской модели (от куда, кстати пошли многие Agile практики) производства.

Теперь я полностью понимаю своих не-Agile оппонентов, видать им в пещере уютней :)

Секрет успешной архитектуры в Agile

Обсуждая задачи управление проектами в рамках Scrum с ребятами из Agile Study Group я решил обобщить своё видение на проектирование и построение архитектуры в стиле Agile. И почему оно лучше, чем существующие альтернативы.

Записал подкаст в котором показываю, что классическая разработка (через детальный анализ и проработку архитектуры) и agile-подход (раскидывание релиза на верхнем уровне детализации и итеративная проработка детальных требований по мере проведения итераций) принципиально не отличаются в факторе реакции на изменчивость требованй. Тот и другой подход может дать сбой. И мы сможем получить требование, которое на корне подрубит архитектуру приложения .

Но, я раскрываю секрет, как можно повысить защищённость архитектуры от незапланированных изменений. И главный секрет находится в Команде.

Обзор литературы (сентябрь 2008)

Мини-обзор литературы, попавшейся мне на глаза и достойной нашего внимания

Growing Object-Oriented Software, Guided by Tests by Steve Freeman

Многообещающее название

The ThoughtWorks Anthology: Essays on Software Technology and Innovation by ThoughtWorks Inc.


Clean Code: A Handbook of Agile Software Craftsmanship by Robert C. Martin


Самая поздняя книга по качеству, смесь советов и smells, покрытых рядом рефакторингов. В общем ответ на моду выработки принципов кодирования уровня Code Style. Рекомендую как и остальные, но ставлю в конец моего списка :)

Самый последний список рекомендаций: http://agileconsulting.ru/wiki/Books

Проектирование по контракту

Интересный подход разработки - проектирование по контракту. Основы подхода заложил Бертрана Мейера. Чтобы быстро разобраться рекомендую классную статью:
http://habrahabr.ru/blogs/crazydev/38612/

Немного философии и сопряжения этой идеи с C#:
http://tagirovarthur.blogspot.com/2007/11/1.html
http://tagirovarthur.blogspot.com/2007/11/2.html

Ну и самого великого маэстро можно читать бесплатно здесь:
http://www.intuit.ru/department/se/oopbases/11/

User Group: Изучение качественного кодирования!

Приглашаю на еженедельные встречи желающих укрепить свои знания и навыки в областях: шаблонов проектирования, рефакторинга и других инженерных практик.

Цель встреч: изучение и углубление знаний в области design patterns. Мы практикуемся и обмениваемся опытом в сфере качественного кодирования, шаблонов, рефакторинга и т.п. (см. выше).

Study Group – помогает осилить сложные книги и идеи, может помочь там, где другие проваливаются, и он поможет тогда, когда в вашем окружении нету тех, кто хочет учиться и расти.



Место встречи:
Кафе в центре Москвы,
Каждую среду в 19 часов
Контакты: syspo_mail.ru
ICQ: 20079282
skype: denis_miller
+7 917 518 68 12 (Денис)

Принцип проектирования: LSP

Фото с одного из наших обсуждений. По старому это называется - собрания по повышению квалификации :)