Які хороші критерії використання Tracer Bullets?

Нещодавно я вперше читав Прагматичного програміста і натрапив на концепцію Tracer Bullets. Я зрозумів, що раніше кодував за цією моделлю і просто щось подав так, як працював у своєму мозку як "спритний".

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

Було багато невідомих і безліч різних середовищ, і ніхто не був надто впевнений, як повинен вести себе GUI.

Це виглядає як початок величезної кількості проектів, особливо коли ви працюєте з нетехнічними людьми над типовою діловою програмою для хедж-фонду (як приклад).

Я використовував це, тому що він просто почував себе правильно, не знаючи, як це називається, чи пояснюючи це мені. Я знав, що якщо я спробую змусити всіх у кімнаті і змусити їх розглянути все (або принаймні деякі речі) на передній план, це було б повною катастрофою, але, знову ж таки, це щось таке відчуття ...

Чи може хто-небудь придумати якісь конкретніші критерії, коли ця модель може бути дорогою?

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

Вам також потрібно опинитися в ситуації, коли ви можете дозволити собі повторити багато разів. Це коштує часу та розвитку (і, звичайно, може бути корисним, якщо ви підписуєтесь на спритні процеси розробки), але складніше з точки зору впливу користувачів. Користувачі швидко виснажуються, якщо ви покажете їм занадто багато дизайну, і якість ваших відгуків знизиться. Тож вам або потрібен великий користувацький пул, або ретельно вибирати (мікро) випуски.

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

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

Я натрапив на концепцію розвитку Tracer Bullet у книзі " Доставлю! під редакцією прагматичних програмістів .

Я здогадуюсь, що у вашому питанні ви маєте на увазі книгу Прагматичний програміст: від мандрівника до майстра . Я цього не читав, і не знаю, як там представлений ТБД. У Корабельному! , є одна глава (20 сторінок), присвячена TBD. Зокрема, вони розповідають про свій досвід на конкретному прикладі: заявку на обмін даними для біотехнологічної компанії. В основному, вони пояснюють, що приємні шари абстракції (розроблені за допомогою TBD) допомогли їм усунути вузькі місця продуктивності один за одним, шляхом парелелізації кожного шару.

На мій погляд, TBD - це дві речі:

• Створіть архітектуру програмного забезпечення, виділивши системні об'єкти, і дозвольте розробникам співпрацювати для визначення інтерфейсів між цими системними об'єктами
• Використовуйте макетні об’єкти, щоб гарантувати стійкість архітектури (тестуйте архітектуру рано)

Я думаю, що перший пункт - це дуже хороший спосіб архітектури програмного забезпечення, незважаючи ні на що. Другий момент викликає заперечення: він потенційно може запобігти повному перезапису проекту через початкову архітектуру, яка не працює на практиці.