Каковы хорошие критерии для использования Tracer Bullets?

Недавно я впервые читал «Прагматичный программист» и натолкнулся на концепцию Tracer Bullets. Я понял, что я кодировал в соответствии с этой моделью в прошлом и просто заподозрил то, как я работал в своем мозгу, как «проворный».

Они приводят только один пример того, где они использовали его в прошлом. То, как ситуация была определена как хороший кандидат для Tracer Bullets, было

Было много неизвестных и много разных сред, и никто не был слишком уверен, как должен вести себя GUI.

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

Я использовал это, потому что это просто чувствовало себя правильным, фактически не зная, как это назвали или объяснив это мне. Я знал, что если я попытаюсь собрать всех в комнате и заставить их заранее определить все (или, по крайней мере, некоторые вещи), это будет полной катастрофой, но, опять же, это такое чувство ...

Может ли кто-нибудь придумать более конкретные критерии того, когда эта модель может быть подходящей?

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

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

Я бы сказал, что на самом деле есть только один базовый фактор, который определяет, насколько полезен подход Tracer Bullet: количество и область неопределенности в архитектуре и дизайне приложения.

Поскольку основная (если не единственная) цель метода заключается в устранении таких неопределенностей, вы не получите от этого большой пользы, если у вас их нет или они не касаются архитектуры или дизайна. Проект «с нуля» без архитектурных ограничений является типичным примером того, что когда начинать с Tracer Bullet - это практически единственная разумная вещь, в то время как для зрелого проекта с некоторыми новыми функциями для его реализации, вероятно, будет пустая трата времени (хотя могут быть неопределенности в отношении требований, их прояснение - это скорее область общей гибкой или итеративной разработки).

Я наткнулся на концепцию разработки Tracer Bullet в книге « Отправь!». под редакцией прагматичных программистов .

Полагаю, что в своем вопросе вы имеете в виду книгу «Прагматичный программист: от подмастерье до мастера» . Я не читал это, и я не знаю, как TBD представлен там. В корабль это! Есть одна глава (20 страниц), посвященная TBD. В частности, они рассказывают о своем опыте на конкретном примере: приложении для обработки данных для биотехнологической компании. По сути, они объясняют, что наличие хороших уровней абстракции (разработанных с использованием TBD) помогло им устранить узкие места в производительности по одному, пареллизуя каждый слой.

На мой взгляд, TBD это две вещи:

• Создайте программную архитектуру, изолировав системные объекты, и позвольте разработчикам сотрудничать, чтобы определить интерфейсы между этими системными объектами.
• Используйте фиктивные объекты для обеспечения устойчивости архитектуры (тестируйте архитектуру заранее)

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