VPF::Проектирования больше нет? - Форум программистов

ivashkanet

Дата 14.4.2008, 15:01 (ссылка)

(нет голосов)

Загрузка ...

Кодю потиху

Профиль
Группа: Участник Клуба
Сообщений: 3684
Регистрация: 23.2.2006
Где: Гомель, Беларусь

Репутация: нет
Всего: 149

Грамотная статья о совмещении проектирования с принципами итеративной разарботки от Мартина Фаулера

Оригинал: http://www.martinfowler.com/articles/designDead.html
Перевод: http://www.maxkir.com/sd/designDead_RUS.html

Цитата(Эпиграф к статье)

Тем, кто успел кратко познакомиться с принципами Extreme Programming (ХР), порой кажется, что в этой методологии нет места процессу проектирования программных продуктов. При этом высмеиваются не только "Большое и Подробное Предварительное Проектирование", но и такие техники как UML и гибкие каркасы приложений. Даже значение паттернов либо принижается, либо напрочь отрицается. На самом же деле, в ХР много проектирования, но подается оно по-другому, нежели в обычных устоявшихся процессах разработки ПО. Методология XP оживила эволюционное проектирование новыми техниками, благодаря которым его теперь можно считать вполне жизнеспособной стратегией. Кроме того, в ХР перед проектировщиком ставятся новые трудные задачи, требующие немалого мастерства. Во-первых, это необходимость проектировать максимально простым образом, во-вторых, рефакторинг, и наконец, использование паттернов в эволюционном стиле.

P.S. Чичас читаю -- нарвится

--------------------

design, simplicity, and experience with a technology focus

ivashkanet

Дата 14.4.2008, 17:05 (ссылка)

(нет голосов)

Загрузка ...

Кодю потиху

Профиль
Группа: Участник Клуба
Сообщений: 3684
Регистрация: 23.2.2006
Где: Гомель, Беларусь

Репутация: нет
Всего: 149

Понравившиеся мысли:
UML:

Цитата

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

Обратимость решений:

Цитата

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

Задачи, плохо поддающиеся рефакторингу:

Цитата

Я бы сказал, что те, кто знает, как это делается, могут сами судить о затратах, которые нужны для выполнения такой задачи. Однако, если вы никогда раньше не занимались такими проблемами, вы не только не можете верно оценить задачу, но и скорее всего, будете допускать ошибки в ее решении. В таком случае, лучше будет внести нужные дополнения в систему позже. Если же вы так и поступили, а теперь испытываете массу трудностей, то поверьте, вам было бы куда тяжелее, начни вы работать над этой задачей с самого начала. Теперь ваша команда уже более опытна, вы лучше понимаете предметную область и требования к системе. Часто, оглядываясь назад, вам будет казаться, что раньше это было бы сделать намного проще. Смею вас уверить, все могло быть гораздо сложнее, если бы начали работать над этим в начале проекта.

Цитата

Выпустить программу как можно раньше - одна из жизненно важных задач. Все, что не нужно в первом выпуске, нужно вносить в систему после него. Впечатление, которое производит на заказчика работающий программный код, просто неописуемо. Первый выпуск программы заставляет его сосредоточиться на проекте, повышает уровень доверия к разработчикам, и кроме того, является мощным источником новых сведений. Делайте все от вас зависящее, чтобы этот день наступил как можно быстрее. Даже если вы знаете, что затратите больше усилий, если внесете новую функциональность позже, все равно лучше будет сделать это после первого выпуска системы.

Цитата

Если вы, к примеру, менеджер или заказчик, как вам узнать, насколько хорошо была спроектирована система? А знать это вам нужно, потому что плохо спроектированную систему будет гораздо сложнее и дороже изменять в будущем. Однозначного ответа на этот вопрос нет, но что-то посоветовать все-таки можно:
Прислушивайтесь к тому, что говорят технари. Если они постоянно жалуются, как трудно делать те или иные изменения в системе, отнеситесь к этим жалобам максимально серьезно и дайте им потратить время на решение возникших проблем.
Обращайте внимание на объем выбрасываемого кода. В любом проекте, где производят рефакторинг, плохой код постоянно удаляется из системы. Если код не удаляется, это можно считать явным признаком отсутствия рефакторинга, что не замедлит привести к деградации дизайна системы. Впрочем, как и любую другую информацию, эти данные можно неправильно интерпретировать. Лучше всего прислушаться к мнению высококлассных технических специалистов, потому что их мнение, пусть даже субъективное, гораздо важнее, чем любая другая метрика.

Это сообщение отредактировал(а) ivashkanet - 14.4.2008, 18:23

--------------------

design, simplicity, and experience with a technology focus

1 Пользователей читают эту тему (1 Гостей и 0 Скрытых Пользователей)
0 Пользователей:
« Предыдущая тема \| Системный анализ, проектирование и UML \| Следующая тема »