Một số tiêu chí tốt để sử dụng Tracer Bullets là gì?

Gần đây tôi đã đọc Lập trình viên thực dụng lần đầu tiên và tôi đã bắt gặp khái niệm về Tracer Bullets. Tôi nhận ra rằng tôi đã mã hóa theo mô hình này trong quá khứ và chỉ cần nộp đơn theo cách mà tôi đang làm việc trong não là "nhanh nhẹn".

Họ chỉ đưa ra một ví dụ về nơi mà họ đã sử dụng nó trong quá khứ. Cách tình huống được xác định là một ứng cử viên sáng giá cho Tracer Bullets là

Có nhiều điều chưa biết và nhiều môi trường khác nhau và không ai quá chắc chắn GUI sẽ hoạt động như thế nào.

Điều đó có vẻ giống như cách một số lượng lớn các dự án bắt đầu, đặc biệt là khi bạn làm việc với những người không có kỹ thuật trên một dòng ứng dụng kinh doanh điển hình cho một quỹ phòng hộ (ví dụ).

Tôi đã sử dụng nó bởi vì nó đơn giản là cảm thấy đúng, mà không thực sự biết nó được gọi là gì hoặc đã giải thích cho tôi. Tôi biết rằng nếu tôi cố gắng đưa mọi người vào một căn phòng và khiến họ chỉ định mọi thứ (hoặc ít nhất là một số thứ) ở phía trước thì đó sẽ là một thảm họa hoàn toàn, nhưng một lần nữa đó lại là một điều ...

Bất cứ ai cũng có thể đưa ra một số tiêu chí cụ thể hơn khi mô hình này có thể là con đường để đi?

Bạn cần có một dự án nơi bạn có thể có ý tưởng về việc bạn đang đi đúng hướng chỉ với một tập hợp nhỏ chức năng. Nói chung, điều này có thể đối với những thứ như thiết kế GUI cơ bản, nhưng khó với những thứ không biết kết quả - ví dụ: nếu bạn đang thiết kế một ứng dụng khai thác dữ liệu và hình dạng của công cụ sẽ phụ thuộc vào loại mẫu nào xảy ra trong dữ liệu của bạn.

Bạn cũng cần phải ở trong một tình huống mà bạn có thể đủ khả năng lặp đi lặp lại nhiều lần. Điều này tốn thời gian và sự phát triển (và tất nhiên có thể có lợi nếu bạn đăng ký các quy trình phát triển nhanh), nhưng khó khăn hơn là chi phí về mặt tiếp xúc với người dùng. Người dùng sẽ nhanh chóng bị cạn kiệt nếu bạn cho họ xem quá nhiều thiết kế và chất lượng phản hồi của bạn sẽ đi xuống. Vì vậy, bạn cần một nhóm người dùng lớn hoặc chọn các bản phát hành (vi) của mình một cách cẩn thận.

Tôi muốn nói rằng thực sự chỉ có một yếu tố cơ bản quyết định cách tiếp cận Tracer Bullet hữu ích như thế nào: số lượng và phạm vi không chắc chắn trong kiến ​​trúc và thiết kế của ứng dụng.

Bởi vì mục tiêu chính (nếu không chỉ) của kỹ thuật là để giải tỏa những điều không chắc chắn như vậy, bạn sẽ không được hưởng lợi nhiều từ nó nếu bạn không có bất kỳ hoặc họ không quan tâm đến kiến ​​trúc hoặc thiết kế. Dự án greenfield không có ràng buộc về kiến ​​trúc là một ví dụ điển hình khi bắt đầu với Tracer Bullet gần như là điều hợp lý duy nhất để làm, trong khi đó, đối với một dự án trưởng thành với một số tính năng mới để thực hiện thì có lẽ sẽ lãng phí thời gian (mặc dù có thể có sự không chắc chắn về các yêu cầu, làm rõ những vấn đề đó là lĩnh vực của sự phát triển nhanh hoặc lặp chung).

Tôi bắt gặp khái niệm phát triển Tracer Bullet trong cuốn sách Ship It! , được chỉnh sửa bởi các lập trình viên thực dụng .

Tôi đoán rằng trong câu hỏi của bạn, bạn đang đề cập đến cuốn sách Lập trình viên thực dụng: Từ Journeyman đến Master . Tôi chưa đọc cái đó và tôi không biết TBD được trình bày ở đó như thế nào. Trong tàu đó! , có một chương (20 trang), dành riêng cho TBD. Cụ thể, họ nói về trải nghiệm của họ với một ví dụ cụ thể: ứng dụng dữ liệu cho một công ty công nghệ sinh học. Về cơ bản, họ giải thích rằng việc có các lớp trừu tượng đẹp (được thiết kế bằng TBD) đã giúp họ loại bỏ các nút thắt hiệu suất từng cái một, bằng cách làm mờ từng lớp.

Theo quan điểm của tôi, TBD là hai điều:

• Tạo một kiến ​​trúc phần mềm bằng cách cô lập các đối tượng hệ thống và để cho các nhà phát triển cộng tác để xác định các giao diện giữa các đối tượng hệ thống này
• Sử dụng các đối tượng giả để đảm bảo kiến ​​trúc bền vững (kiểm tra kiến ​​trúc sớm)

Tôi nghĩ rằng điểm đầu tiên là một cách rất tốt để kiến ​​trúc sư một phần mềm, không có vấn đề gì. Điểm thứ hai là can thiệp: nó có khả năng ngăn chặn việc viết lại hoàn toàn dự án do một kiến ​​trúc ban đầu không hoạt động trong thực tế.