Apa sajakah kriteria yang baik untuk menggunakan Pelacak Pelacak?

Saya baru-baru ini membaca The Pragmatic Programmer untuk pertama kalinya dan saya menemukan konsep Peluru Peluru. Saya menyadari bahwa saya telah mengkodekan menurut model ini di masa lalu dan hanya semacam mengajukan cara saya bekerja jauh di otak saya sebagai "lincah".

Mereka hanya memberikan satu contoh di mana mereka telah menggunakannya di masa lalu. Cara situasinya diidentifikasi sebagai kandidat yang baik untuk Tracer Bullets adalah

Ada banyak yang tidak diketahui, dan banyak lingkungan yang berbeda, dan tidak ada yang terlalu yakin bagaimana seharusnya GUI berperilaku.

Jenis itu kelihatannya seperti cara sejumlah besar proyek dimulai, terutama ketika Anda bekerja dengan orang-orang non-teknis pada garis khas aplikasi bisnis untuk hedge fund (sebagai contoh).

Saya menggunakannya karena rasanya benar, tanpa benar-benar tahu apa namanya atau menjelaskannya kepada saya. Saya tahu bahwa jika saya mencoba membuat semua orang berada di sebuah ruangan dan membuat mereka menentukan semuanya (atau setidaknya beberapa hal) di muka, itu akan menjadi bencana total, tetapi sekali lagi itu semacam perasaan ...

Adakah yang bisa membuat beberapa kriteria yang lebih konkret ketika model ini mungkin merupakan jalan yang harus ditempuh?

Anda perlu memiliki proyek di mana Anda bisa mendapatkan ide tentang jika Anda berada di jalur yang benar dengan hanya sebagian kecil fungsi. Secara umum hal ini dimungkinkan untuk hal-hal seperti desain GUI dasar, tetapi sulit dengan hal-hal di mana hasilnya tidak diketahui - misalnya jika Anda mendesain aplikasi data mining dan bentuk alat akan tergantung pada jenis pola yang terjadi pada data Anda.

Anda juga harus berada dalam situasi di mana Anda mampu untuk berulang kali. Ini membutuhkan waktu dan pengembangan (dan tentu saja mungkin bermanfaat jika Anda berlangganan proses pengembangan yang gesit), tetapi yang lebih sulit adalah biaya dalam hal pemaparan kepada pengguna. Pengguna akan cepat lelah jika Anda menunjukkan terlalu banyak desain kepada mereka dan kualitas umpan balik Anda akan menurun. Jadi Anda perlu kumpulan pengguna yang besar, atau untuk memilih rilis (mikro) Anda dengan hati-hati.

Saya akan mengatakan bahwa sebenarnya hanya ada satu faktor dasar yang menentukan seberapa berguna pendekatan Tracer Bullet adalah: jumlah dan ruang lingkup ketidakpastian dalam arsitektur dan desain aplikasi.

Karena tujuan utama (jika bukan hanya) dari teknik ini adalah untuk menjernihkan ketidakpastian seperti itu, Anda tidak akan mendapat banyak manfaat darinya jika Anda tidak memiliki atau mereka tidak memedulikan arsitektur atau desain. Proyek greenfield tanpa kendala arsitektur adalah contoh khas ketika memulai dengan Tracer Bullet adalah satu-satunya hal yang masuk akal untuk dilakukan, sedangkan proyek dewasa dengan beberapa fitur baru untuk mengimplementasikannya mungkin akan membuang-buang waktu (walaupun mungkin ada ketidakpastian mengenai persyaratan, membersihkan mereka lebih merupakan domain dari pengembangan tangkas atau iteratif umum).

Saya menemukan konsep pengembangan Tracer Bullet dalam buku Ship It! , diedit oleh programmer pragmatis .

Saya kira itu dalam pertanyaan Anda, Anda merujuk pada buku Program Pragmatis: Dari Journeyman ke Master . Saya belum membaca yang itu, dan saya tidak tahu bagaimana TBD disajikan di sana. Di Kapal Itu! , ada satu bab (20 halaman), yang didedikasikan untuk TBD. Secara khusus, mereka berbicara tentang pengalaman mereka dengan contoh nyata: aplikasi pendataan untuk perusahaan biotek. Pada dasarnya, mereka menjelaskan bahwa memiliki lapisan abstraksi yang bagus (dirancang menggunakan TBD) membantu mereka menghilangkan hambatan kinerja satu per satu, dengan memparelelisasi setiap lapisan.

Menurut saya, TBD adalah dua hal:

• Buat arsitektur perangkat lunak dengan mengisolasi objek sistem, dan biarkan pengembang mengembangkan kolaborasi untuk mendefinisikan antarmuka antara objek sistem ini
• Gunakan benda tiruan untuk memastikan arsitektur berkelanjutan (uji arsitektur lebih awal)

Saya pikir poin pertama adalah cara yang sangat baik untuk merancang perangkat lunak, apa pun yang terjadi. Poin kedua adalah interresting: berpotensi mencegah penulisan ulang lengkap suatu proyek karena arsitektur awal yang tidak berfungsi dalam praktiknya.