เกณฑ์ที่ดีในการใช้ Tracer Bullets มีอะไรบ้าง

ฉันเพิ่งอ่าน The Pragmatic Programmer เป็นครั้งแรกและฉันได้พบกับแนวคิดของ Tracer Bullets ฉันรู้ว่าฉันได้เขียนตามแบบจำลองนี้ในอดีตและเพิ่งยื่นแบบที่ฉันทำงานในสมองของฉันเป็น "เปรียว"

พวกเขาเพียงยกตัวอย่างหนึ่งที่พวกเขาเคยใช้มันในอดีต วิธีที่สถานการณ์ถูกระบุว่าเป็นตัวเลือกที่ดีสำหรับ Tracer Bullets คือ

มีสิ่งแปลกปลอมมากมายและสภาพแวดล้อมที่แตกต่างกันและไม่มีใครแน่ใจว่า GUI ควรประพฤติอย่างไร

ดูเหมือนว่าโครงการจะเริ่มขึ้นเป็นจำนวนมากโดยเฉพาะอย่างยิ่งเมื่อคุณทำงานกับคนที่ไม่ใช่ด้านเทคนิคในแอพทางธุรกิจทั่วไปสำหรับกองทุนป้องกันความเสี่ยง (เป็นตัวอย่าง)

ฉันใช้มันเพราะรู้สึกถูกต้องโดยที่ไม่รู้ว่ามันถูกเรียกหรือมีคำอธิบายให้ฉัน ฉันรู้ว่าถ้าฉันพยายามทำให้ทุกคนอยู่ในห้องและให้พวกเขาระบุทุกอย่าง (หรืออย่างน้อยก็บางอย่าง) ข้างหน้ามันจะเป็นหายนะที่สมบูรณ์ แต่อีกครั้งนั่นเป็นความรู้สึก ...

ใครบ้างที่สามารถสร้างเกณฑ์ที่เป็นรูปธรรมมากขึ้นเมื่อแบบจำลองนี้เป็นไปได้หรือไม่

คุณต้องมีโครงการที่คุณสามารถรับความคิดเกี่ยวกับว่าคุณอยู่ในเส้นทางที่ถูกต้องด้วยฟังก์ชั่นย่อย ๆ โดยทั่วไปสิ่งนี้เป็นไปได้สำหรับสิ่งต่าง ๆ เช่นการออกแบบ GUI พื้นฐาน แต่ยากกับสิ่งที่ผลลัพธ์ไม่เป็นที่รู้จักเช่นถ้าคุณออกแบบแอป data mining และรูปร่างของเครื่องมือจะขึ้นอยู่กับรูปแบบของข้อมูลของคุณ

คุณต้องอยู่ในสถานการณ์ที่สามารถทำซ้ำได้หลายครั้ง เวลาและค่าใช้จ่ายในการพัฒนา (และแน่นอนอาจเป็นประโยชน์หากคุณสมัครเป็นสมาชิกกระบวนการพัฒนาที่คล่องตัว) แต่สิ่งที่ยากกว่าคือค่าใช้จ่ายในแง่ของการได้รับผู้ใช้ ผู้ใช้จะหมดแรงอย่างรวดเร็วหากคุณแสดงการออกแบบมากเกินไปและคุณภาพของความคิดเห็นของคุณจะลดลง ดังนั้นคุณต้องมีกลุ่มผู้ใช้ขนาดใหญ่หรือเลือก (ไมโคร) ของคุณออกอย่างระมัดระวัง

ฉันจะบอกว่ามีเพียงปัจจัยพื้นฐานเดียวเท่านั้นที่กำหนดว่าแนวทาง Tracer Bullet มีประโยชน์อย่างไร: จำนวนและขอบเขตของความไม่แน่นอนในสถาปัตยกรรมและการออกแบบแอปพลิเคชัน

เนื่องจากเป้าหมายหลักของเทคนิค (หากไม่เพียง แต่) คือการล้างความไม่แน่นอนดังกล่าวคุณจะไม่ได้รับประโยชน์มากนักหากคุณไม่มีหรือไม่เกี่ยวข้องกับสถาปัตยกรรมหรือการออกแบบ โครงการกรีนฟิลด์ที่ไม่มีข้อ จำกัด ทางสถาปัตยกรรมเป็นตัวอย่างทั่วไปเมื่อเริ่มต้นด้วย Tracer Bullet เกือบจะเป็นสิ่งที่สมเหตุสมผลที่ต้องทำในขณะที่โครงการที่ครบกำหนดพร้อมคุณสมบัติใหม่ที่จะนำมาใช้อาจจะเสียเวลา (แม้ว่า อาจมีความไม่แน่นอนเกี่ยวกับข้อกำหนดการล้างสิ่งเหล่านั้นให้มากขึ้นเป็นขอบเขตของการพัฒนาแบบว่องไวทั่วไปหรือการวนซ้ำ)

ฉันเจอแนวคิดของการพัฒนากระสุนติดตามในหนังสือShip It! แก้ไขโดยโปรแกรมเมอร์ในทางปฏิบัติ

ฉันเดาว่าในคำถามของคุณคุณจะหมายถึงหนังสือโปรแกรมเมอร์ศาสตร์: จากคนงานที่จะโท ฉันไม่ได้อ่านอันนั้นและฉันไม่รู้ว่าจะนำเสนอ TBD ได้อย่างไร ในการจัดส่งมัน! มีหนึ่งบท (20 หน้า) ที่อุทิศให้กับ TBD โดยเฉพาะอย่างยิ่งพวกเขาพูดคุยเกี่ยวกับประสบการณ์ของพวกเขาด้วยตัวอย่างที่เป็นรูปธรรม: แอปพลิเคชันการบันทึกข้อมูลสำหรับ บริษัท เทคโนโลยีชีวภาพ โดยพื้นฐานแล้วพวกเขาอธิบายว่าการมีเลเยอร์สิ่งที่เป็นนามธรรม (ออกแบบโดยใช้ TBD) ช่วยให้พวกเขาลบคอขวดของประสิทธิภาพออกทีละหนึ่งโดยการแยกวิเคราะห์แต่ละเลเยอร์

ในมุมมองของฉัน TBD เป็นสองสิ่ง:

• สร้างสถาปัตยกรรมซอฟต์แวร์โดยแยกวัตถุระบบและให้ผู้พัฒนาร่วมทำงานเพื่อกำหนดส่วนต่อประสานระหว่างวัตถุระบบเหล่านี้
• ใช้วัตถุจำลองเพื่อให้แน่ใจว่าสถาปัตยกรรมนั้นยั่งยืน (ทดสอบสถาปัตยกรรมก่อน)

ฉันคิดว่าจุดแรกเป็นวิธีที่ดีมากในการออกแบบซอฟต์แวร์ไม่ว่าจะเกิดอะไรขึ้น จุดที่สองคือการหยุดยั้ง: มันอาจป้องกันการเขียนซ้ำทั้งหมดของโครงการเนื่องจากสถาปัตยกรรมเริ่มต้นที่ไม่สามารถใช้งานได้จริง