Материалы конференции «В гостях у Agile практиков»: доклад Дмитрия Миндры

Еще один докладчик прошедшей конференции «В гостях у Agile практиков» подготовил материалы к публикации. Это Дмитрий Миндра с докладом на тему «Мифы о проектировании»:

Дима очень серьезно отнесся к вопросам участников и подготовил очень подробные и развернутые ответы.

Вопрос: Обновление диаграмм — на чьей совести?
Ответ: Для начала определимся с ответом на вопрос: “Что первично?”. Диаграмма редко строится постфактум. Как правило, диаграмма первична и она является отражением мысли разработчика о проектируемой системе или некоторых ее аспектах.

Второй вопрос: “Каково место диаграммы в вашем процессе?”. Если процесс предполагает поддержку документации, на это выделяется время и команда разделяет ценности процесса, то ответственный за обновление будет назначен, а выполненная работа проверена. Если же работа не будет выполнена и проверена, то кого-то будет мучить не только совесть, но и менеджер. Если процесс неформальный, то возникает новый вопрос: “Какова ценность актуальных диаграмм для команды?”. И ответ на этот вопрос будет определять будет ли мучить совесть того, кто диаграмму не обновил. А именно человека, разрабатывавшего компонент или вносящего существенные изменения(сравнимые с повторной разработкой). Как мы говорили, диаграмма — отражение идеи. Соответственно и меняться она будет когда меняется идея заключенная в конкретном компоненте. Чаще всего мы будем иметь дело не с обновлением диаграммы а с построением новой (или с обновлением, сравнимым с построением новой диаграммы).

Совет: в диаграммы лучше выносить устойчивую информацию о системе. Ту, которой достаточно для иллюстрации идеи, лежащей в основе системы или компонента. Эта информация является наиболее полезной и наиболее устойчивой.

Цицерон говорил что самое главное украшение — чистая совесть. Многим, к сожалению, достаточно наручных часов.

Вопрос: Наверное, очень общий вопрос, как заставить разработчиков писать unit tests, если есть QA и они все проверят, это их работа. Не хотелось бы заваливать пару спринтов и показывать, что мы не справляемся с объемом изменений.
Ответ: Начнем с первого утверждения: “QA все проверят”. QA все не проверят. Точно так же все не проверят разработчики. Чем сложнее разрабатываемое программное обеспечение, тем больше всевозможных вариантов использования. Когда QA и разработчики действуют сообща, вероятность сделать корректное программное обеспечение намного больше.

“Завалить пару спринтов” означает не справится с задачей планирования. Если опыта в написании модульных тестов у вас нет, то вам надо будет немного потренироваться, прежде чем вы сможете оценить работу с учетом нового процесса, частью которого являются модульные тесты. Перед началом первого спринта вы должны получить представление о модульном тестировании. Затем, пытаясь оценить задачи, вы заложите в оценки страховку, и она позволит вам справиться с первыми спринтами. Совершенно не обязательно начинать внедрение изменений в процесс разработки с провала.

Итак, QA и модульные тесты не проверят все. Качество и корректность продукта — это общая ответственность. Разработчики и тестировщики находятся в одной упряжке и должны действовать сообща.

Модульный тест — это прежде всего инструмент разработчика. Один из инструментов. И он, как и все инструменты, позволяет сделать труд разработчика более продуктивным при правильном применении. Научившись применять модульные тесты, разработчик будет проводить меньше времени в отладке и больше анализировать требования к системе. В виду наличия кривой обучения и необходимости писать больше кода, модульное тестирование — это не сиюминутная выгода, а инвестиция в благополучное будущее.

Попытка заставить разработчика писать модульные тесты для галочки ситуацию лишь ухудшит. Написание модульных тестов требует знаний, навыков и мотивации. Нужно заразить разработчиков идеей, обучить их, дать возможность поиграть с тестами, дать время осознать их преимущества. Они сами к вам придут с модульными тестами и потребуют включить их в процесс. Попытка “заставить”, “принудить”, “продавить” встретит сопротивление и обречена на провал.

В разработке программного обеспечения нет серебряных пуль. Модульные тесты — это всего лишь один из инструментов. Не стоит возлагать на него решение всех своих проблем.

Совет: не пытайтесь заставить разработчика писать модульные тесты. Вместо этого попытайтесь научить его пользоваться модульными тестами и применять их к месту.

Как сказал Антуан де Сент-Экзюпери: “Если ты хочешь построить корабль, не надо заставлять людей рубить деревья и носить бревна, надо лишь научить их тосковать по морю. И они сами построят корабль.”

Вопрос: Был ли у Вас опыт работы, когда на проекте делается white box testing. Не противоречит ли эта практика с unit tests?
Ответ: Опыт работы в проекте с white box тестированием у меня был очень давно. Эта практика никоим образом не противоречит модульному тестированию. Как мы уже говорили, модульное тестирование — инструмент разработчика и его инвестиция в благополучное будущее. Кроме того, модульный тест — спецификация на разрабатываемый компонент, выраженная в коде.

White box тестирование в проекте с модульными тестами намного удобнее. Ведь можно поменять любое условие в бизнес логике на обратное и проверить, работают ли тесты. Если работают, то либо это условие лишнее, либо тесты не проверяют один из вариантов использования компонента.

Я бы задумался над другим вопросом: если QA может проверить корректность кода, он скорее всего может его написать. Я думаю, что само white box тестирование подойдет далеко не каждому проекту, точнее будет оправдано далеко не в каждом проекте.

Вопрос: Сколько дополнительно в оценке задач надо закладываться на unit tests?
Ответ: Не нужно закладывать ничего. Нужно изначально оценивать задачи вместе с тестами и не пытаться оценить тесты отдельно. В противном случае тесты в ваших оценках будут выглядеть как что-то лишнее. Поверьте мне, они будут первым что захочет сократить заказчик. Ваша задача не накрутить счетчик заказчику, а улучшить процесс разработки.

Совет: не пытайтесь продавать модульные тесты отдельно. Относитесь к ним как к отладке. Вы же не продаете время проведенное разработчиком в отладчике отдельно?

Вопрос: Кто отвечает за архитектуру системы? Должен ли быть один ответственный или должна отвечать вся команда в целом?
Ответ: За архитектуру отвечает вся команда. Архитектура программного обеспечения — социальная сущность. Она нужна не для галочки. Она должна помогать конкретным людям выполнять конкретные задачи. Заказчику важны корректность, стоимость и сроки. Эти же критерии должна разделять команда разработчиков. Значит, хорошая архитектура должна обеспечивать возможность разрабатывать корректное ПО с контролируемыми сроками и стоимостью разработки.

Если часть команды архитектуру принимает и поддерживает а другая — нет, то команда будет работать как лебедь, рак и щука в известной басне. Архитектура должна быть понятна и удобна всей команде.

Вопрос: Если не разрабатывать сразу гибкую архитектуру, то разве потом не станет сложно вносить изменения? Как тогда быть?
Ответ: Мы не можем предвидеть все изменения. Но мы можем сделать некоторые предположения и попытаться подготовиться к ним. Для того, чтобы мы могли подготовиться к изменениям, существуют принципы, практики, подходы, шаблоны. Если одним словом, то инструменты проектирования. О них, пожалуй, стоит написать отдельный пост. Но если не готовиться вообще, вы рискуете получить плохо адаптированную к изменениям жесткую и хрупкую архитектуру.

Вопрос: Кто должен проектировать, если команда часто не компетентна в архитектуре, например еще не хватает представления о теме? Брать со стороны?
Ответ: Если команда некомпетентна, то нужно в первую очередь работать над ее компетентностью. Стороннего человека имеет смысл пригласить для обучения команды, либо для выполнения некоторых работ в составе команды.

Мы уже говорили, что архитектура — социальная сущность. Люди не могут работать с тем, чего не понимают. Если вы им предложите архитектуру, которой они не понимают, то рано или поздно они ее сведут к тому, что они понимают.

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

Вопрос: Можете ли вы назвать базовый набор техник либо подходов, необходимый для качественной реализации задач проектирования? Какое место здесь занимает DDD?
Ответ: Люди давно пытались найти серебряную пулю для решения задач проектирования.
В период с 1985 по 1989 было разработано множество методологий и подходов, претендующих на звание серебряной пули. Но ни один из них так и не стал единственным верным. Различные задачи и ситуации требуют различных подходов к проектированию. Нет серебряных пуль. Есть знания, опыт, фантазия.

DDD занимает важное место т.к. рассматривает разработку и проектирование с точки зрения доменной модели. Но это всего лишь один из доступных инструментов. Об инструментах проектирования, пожалуй, стоит написать отдельный пост.

Программное обеспечение не ограничено физикой, как здания. Оно ограничено фантазией, дизайном, организацией. Короче говоря, оно ограничено свойствами людей, а не свойства мира. «Мы встретили врага, и этот враг мы сами». (Мартин Фаулер)

You can leave a response, or trackback from your own site.

Leave a Reply