Jakie są dobre kryteria korzystania z Tracer Bullets?

Niedawno po raz pierwszy czytałem The Pragmatic Programmer i natknąłem się na koncepcję Tracer Bullets. Uświadomiłem sobie, że kodowałem zgodnie z tym modelem w przeszłości i po prostu zapisałem sposób, w jaki pracowałem w mózgu jako „zwinny”.

Podają tylko jeden przykład tego, gdzie używali go w przeszłości. Sposób, w jaki stwierdzono, że jest dobrym kandydatem do Tracer Bullets, był

Było wiele niewiadomych i wiele różnych środowisk i nikt nie był zbyt pewny, jak powinien się zachowywać GUI.

Taki sposób wydaje się być początkiem ogromnej liczby projektów, zwłaszcza gdy pracujesz z osobami nietechnicznymi w typowej aplikacji biznesowej dla funduszu hedgingowego (na przykład).

Użyłem go, ponieważ po prostu czułem się dobrze, nie wiedząc naprawdę, jak się nazywa, ani nie wyjaśniłem mi tego. Wiedziałem, że jeśli spróbuję zaprowadzić wszystkich do pokoju i zmusić ich do sprecyzowania wszystkiego (a przynajmniej niektórych rzeczy) z przodu, byłaby to kompletna katastrofa, ale znowu to jest coś w rodzaju ...

Czy ktoś może wymyślić bardziej konkretne kryteria określające, kiedy ten model może być właściwym rozwiązaniem?

Musisz mieć projekt, w którym możesz dowiedzieć się, czy jesteś na dobrej drodze z niewielkim podziałem funkcjonalności. Zasadniczo jest to możliwe w przypadku podstawowego projektu GUI, ale jest trudne w przypadku rzeczy, w których wyniki są nieznane - np. Jeśli projektujesz aplikację do eksploracji danych, a kształt narzędzia będzie zależeć od rodzaju wzorców występujących w twoich danych.

Musisz także znaleźć się w sytuacji, w której możesz sobie pozwolić na wielokrotne iteracje. To kosztuje czas i rozwój (i oczywiście może być korzystne, jeśli subskrybujesz zwinne procesy programistyczne), ale trudniejsze są koszty pod względem narażenia użytkowników. Użytkownicy szybko się wyczerpią, jeśli pokażesz im zbyt wiele projektów, a jakość Twojej opinii spadnie. Potrzebujesz więc dużej puli użytkowników lub ostrożnie wybieraj wersje (mikro).

Powiedziałbym, że tak naprawdę tylko jeden podstawowy czynnik decyduje o przydatności podejścia Tracer Bullet: liczba i zakres niepewności w architekturze i projekcie aplikacji.

Ponieważ głównym (jeśli nie tylko) celem techniki jest wyjaśnienie takich niepewności, nie odniesiesz z niej większych korzyści, jeśli jej nie masz lub nie dotyczą one architektury lub projektu. Projekt typu greenfield bez ograniczeń architektonicznych jest typowym przykładem, gdy rozpoczęcie od Tracer Bullet jest prawie jedyną sensowną rzeczą, podczas gdy dla projektu dojrzałego z kilkoma nowymi funkcjami do wdrożenia prawdopodobnie byłby to strata czasu (chociaż wymagania mogą być niepewne, ich usunięcie jest raczej domeną ogólnego zwinnego lub iteracyjnego rozwoju).

Koncepcję rozwoju Tracer Bullet natrafiłem w książce Ship It! , edytowane przez pragmatycznych programistów .

Wydaje mi się, że w swoim pytaniu odwołujesz się do książki The Pragmatic Programmer: From Journeyman to Master . Nie przeczytałem tego i nie wiem, jak tam prezentowane jest TBD. W Ship It! , jest jeden rozdział (20 stron) poświęcony TBD. W szczególności mówią o swoich doświadczeniach z konkretnym przykładem: aplikacją do analizy danych dla firmy biotechnologicznej. Zasadniczo wyjaśniają, że posiadanie ładnych warstw abstrakcji (zaprojektowanych przy użyciu TBD) pomogło im usuwać wąskie gardła wydajności jeden po drugim, parellelizując każdą warstwę.

Moim zdaniem TBD to dwie rzeczy:

• Utwórz architekturę oprogramowania, izolując obiekty systemowe i pozwól programistom współpracować w celu zdefiniowania interfejsów między tymi obiektami systemowymi
• Użyj próbnych obiektów, aby zapewnić trwałość architektury (wcześniej przetestuj architekturę)

Myślę, że pierwszy punkt to bardzo dobry sposób na zaprojektowanie oprogramowania, bez względu na wszystko. Drugi punkt jest interesujący: może potencjalnie zapobiec całkowitemu przepisaniu projektu z powodu początkowej architektury, która nie działa w praktyce.