Tracer Bullet Development

Question

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

Я вижу два пути:

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

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

Вопросы:
При разработке трассирующей пули какой из этих двух подходов вы используете и почему?
Или есть другой подход, который мне не хватает?

Answer 1

Насколько я понимаю, метод Tracer Bullet имеет две основные цели

1. решите фундаментальные проблемы как можно скорее
2. дать клиенту полезный результат как можно скорее

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

Я бы сказал, что ваша идея в порядке, пока

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

Answer 2

Если вы выберете подход № 1, у вас будет достаточно быстро работать с 90% функциональности. Тем не менее, ваш клиент также будет думать, что вы сделали 90%, и удивится, почему вам требуется в 9 раз больше времени, чтобы закончить работу.

Если вы выберете подход № 1, я бы назвал это не чем иным, как прототипом, и относился бы к нему таким образом. Представлять его как нечто большее, чем это, не приведет ни к чему, кроме проблем в дальнейшем. Сценарии счастливого дня - это только 10% работы. Оставшиеся 90% заставляют работать другие сценарии, а сценарий счастливого дня - надежно. Очень трудно заставить не-разработчиков поверить в это. Я обычно делаю что-то между # 1 и # 2. Я пытаюсь сделать довольно хорошую работу по выявлению сценариев использования и всех сценариев. Затем я пытаюсь выявить наиболее архитектурно влияющие сценарии и работаю над ними.

Answer 3

Я бы посоветовал использовать пули Tracer для комбинации положительных + отрицательных тестовых случаев

1. Положительные тестовые примеры ( они будут упомянуты в ваших пользовательских историях / документах о функциях / технических характеристиках)
2. Отрицательные тестовые случаи ( распространенные негативные сценарии, которые можно ожидать в сценарии BAU ) ( Редкие бизнес-сценарии могут быть исключены после тщательного рассмотрения. )

Эти тесты были выполнены с использованием specflow для автоматизации тестирования.

Включение сценариев Common Negative в ваши тестовые примеры обеспечивает достаточную уверенность в том, что последовательные разработки могут быть выполнены с использованием базового кода.

Обмен опытом здесь http://softwarecookie.wordpress.com/2013/12/26/tracer-bullet/