Для решения описанных проблем имеет смысл посмотреть в сторону паттернов Object Mother и Test Data Builder. Врочем, тесты — это обычный код, для устранения дублирования (в тестовых методах, фикстур и т. д.) следует применять те же правила, что и в обычном рабочем коде.
А делать зависимые тесты и, тем более, завязывать их на порядок выполнения — это, как уже сказали выше, не самая хорошая затея.
С исследованиями не знаком (взял на заметку), поэтому прокомментировать не могу. Но могу смело утверждать, что мы сумели увеличить качество кода, уменьшить количество ошибок, и, как следствие, повысить производительность, в разы.
При этом путь мы прошли довольно тяжелый: пол года безуспешно пытались внедрить XP, затем, начав с чистого листа, стали использовать Scrum. И только после того, как почувствовали уверенность, стали постепенно добавлять инженерные практики из XP. В результате мы получили уникальную гибкую методологию, которая подходит именно для нашей команды.
> На мой взгляд, успешным проект делает не методология, а команда.
А на мой взгляд, хорошая методология позволяет максимально раскрыть потенциал любой команды. И гибкие методологии, как раз за счет своей гибкости и адаптивности, идеально для этого подходят. Это не противоречит сказанному вами, так что вполне можно утверждать, что методология + команда = успех проекта.
В аджайле хорошие отношения между заказчиком и исполнителем, а самое главное, доверие заказчика к исполнителю являются одним из важных факторов успеха проекта. В случае с «плохим» заказчиком, вполне возможно, что подробное ТЗ и спецификации могут очень пригодиться при решении конфликтов, с этим спорить не буду.
В том или ином виде во всех методологиях можно найти что-то общее :) Более того, любая итеративная методология — это почти классический водопад, только длинной в одну итерацию. Очевидно, что в аджайле присутствуют планирование, проектирование, тестирование и прочие фазы, но их роль сильно уменьшена, а акцент смещен именно на разработку и максимально быстрое получение рабочего кода.
Не нужно брать в команду людей с суперэго :) В любой гибкой методологии на первый план выходит команда: коллективное владение кодом, коллективная ответственность, ну и так далее. Слаженная команда способна разрабатывать качественный, подготовленный к изменениям, хорошо протестированный продукт.
Кстати, TDD дает наибольший профит как раз в системах со сложной бизнес-логикой, когда заранее спроектировать архитектуру просто нереально. Не знаю, из чего следует утверждение о прототипах и типовых решениях.
Для получения хорошей архитектуры ее вовсе не обязательно проектировать, тем более долго. А для получения качественного кода нет необходимости прикладывать каких-то дополнительных усилий, достаточно следователь некоторым простым, но важным принципам. Говнокод же даже в самых небольших проектах всегда вылазит боком, значительно увеличивая стоимость любого последующего изменения.
Вы начали совершенно верно: если стоит задача написать расчет факториала, необходимо, следуя принципам KISS и YAGNI, максимально просто реализовать расчет факториала :) Заказчик обязательно попросит вас добавить еще один метод расчета, и вы это сделаете, никуда не денетесь. А вот когда он попросит добавить третий — вот тут и проявится качество архитектуры. Если на втором шаге вы все сделали правильно, избежали дублирования, это не займет много времени.
Кстати, то ли у Мартина, то ли у Шаллоуея была описана точно такая же ситуация, только там был не факториал, а программа для копирования. Сначала она должна была копировать из файла в файл, потом из файла на принтер и так далее. На простом примере хорошо иллюстрируется как должен расти качественный продукт.
Достаточно давно, и что более важно, как раз в реальных условиях.
1. Для старта проекта достаточно концепции и краткой информации о предметной области, детальная спецификация не нужна.
2. Классической инспекции тоже нет, есть коллективное владение кодом и, в случае с XP, парное программирование — я об этом выше писал.
3. Мыслить надо командой. Естественно, неявной специализации не избежать, но обычно это выражается в том, что известно, к кому лучше обратиться за советом.
4. В гибких командах нет архитектора ровно как и проектирования «наперед».
В общем все это до меня уже описано и пережевано в умных книжках, я могу лишь подтвердить, что это работает на практике :)
Вы меня поправить пытаетесь или дополняете? :) Если последнее, то все написанное верно. Единственное, я бы в качестве альтернативы инспекции называл бы коллективное владение кодом и частично практику парного программирование.
Если маленькое изменение требует «большого рефакторнига» — это признак сильно связанного когда и неудачной архитектуры. Система должна быть готова к изменениям, которые неизбежны, и сопротивляться им бессмысленно т.к. система которая не изменяется — это мертвая система. Конечно, хорошей спецификацией можно в случае чего прикрыть свой зад, но продукт от этого нужной фичи не получит и лучше не станет.
Практически во всех гибких методологиях:
— нет разработчика, отвечающего за архитектуру;
— нет инспекции кода;
— нет спецификаций;
— архитектура не продумывается заранее;
— нет специализации у участников команды.
При этом гибкие методологии отлично работают и вытесняют «классические». Так что все данные советы как минимум сомнительные.
А делать зависимые тесты и, тем более, завязывать их на порядок выполнения — это, как уже сказали выше, не самая хорошая затея.
При этом путь мы прошли довольно тяжелый: пол года безуспешно пытались внедрить XP, затем, начав с чистого листа, стали использовать Scrum. И только после того, как почувствовали уверенность, стали постепенно добавлять инженерные практики из XP. В результате мы получили уникальную гибкую методологию, которая подходит именно для нашей команды.
> На мой взгляд, успешным проект делает не методология, а команда.
А на мой взгляд, хорошая методология позволяет максимально раскрыть потенциал любой команды. И гибкие методологии, как раз за счет своей гибкости и адаптивности, идеально для этого подходят. Это не противоречит сказанному вами, так что вполне можно утверждать, что методология + команда = успех проекта.
Кстати, TDD дает наибольший профит как раз в системах со сложной бизнес-логикой, когда заранее спроектировать архитектуру просто нереально. Не знаю, из чего следует утверждение о прототипах и типовых решениях.
Кстати, то ли у Мартина, то ли у Шаллоуея была описана точно такая же ситуация, только там был не факториал, а программа для копирования. Сначала она должна была копировать из файла в файл, потом из файла на принтер и так далее. На простом примере хорошо иллюстрируется как должен расти качественный продукт.
1. Для старта проекта достаточно концепции и краткой информации о предметной области, детальная спецификация не нужна.
2. Классической инспекции тоже нет, есть коллективное владение кодом и, в случае с XP, парное программирование — я об этом выше писал.
3. Мыслить надо командой. Естественно, неявной специализации не избежать, но обычно это выражается в том, что известно, к кому лучше обратиться за советом.
4. В гибких командах нет архитектора ровно как и проектирования «наперед».
В общем все это до меня уже описано и пережевано в умных книжках, я могу лишь подтвердить, что это работает на практике :)
— нет разработчика, отвечающего за архитектуру;
— нет инспекции кода;
— нет спецификаций;
— архитектура не продумывается заранее;
— нет специализации у участников команды.
При этом гибкие методологии отлично работают и вытесняют «классические». Так что все данные советы как минимум сомнительные.