กัปตันชัดเจนต่อการช่วยเหลือ!
ฉันจะเป็นกัปตันแจ่มแจ้งที่นี่และบอกว่ามีพื้นกลางที่จะพบ
คุณต้องการสร้างเพื่ออนาคตและหลีกเลี่ยงการล็อคตัวเองในการเลือกเทคโนโลยีหรือการออกแบบที่ไม่ดี แต่คุณไม่ต้องการใช้เวลา 3 เดือนในการออกแบบสิ่งที่ควรจะง่ายหรือเพิ่มจุดส่วนขยายสำหรับแอปที่รวดเร็วและสกปรกซึ่งจะมีอายุการใช้งาน 2 ปีและไม่น่าจะมีโครงการติดตามผล
เป็นการยากที่จะค้นหาความแตกต่างเนื่องจากคุณไม่สามารถคาดการณ์ความสำเร็จของผลิตภัณฑ์ของคุณได้ตลอดเวลาและหากคุณต้องการขยายในภายหลัง
สร้างตอนนี้ถ้า ...
- โครงการกำลังจะถูกทิ้ง
- โครงการมีอายุการใช้งานสั้น
- โครงการไม่ควรมีส่วนขยาย
- โครงการไม่ได้มีค่าผลกระทบความเสี่ยง (ส่วนใหญ่ในแง่ของภาพ)
โดยทั่วไปโครงการภายในหรือสิ่งที่สร้างขึ้นสำหรับลูกค้าควรได้รับการพัฒนาในขณะนี้ ตรวจสอบให้แน่ใจว่ามีข้อกำหนดตรงและเกี่ยวข้องกับพวกเขาเท่าที่จำเป็นเพื่อทราบสิ่งที่จำเป็นและสิ่งที่ไม่ ไม่ต้องการใช้เวลามากเกินไปในทุกสิ่งที่ "ดีที่มี" แต่อย่าใช้รหัสเช่นหมู
ออกจากปัญหาทั่วไปในภายหลังหากจำเป็นและคุ้มค่ากับความพยายาม:
สร้างเพื่ออนาคตถ้า ...
- โครงการจะเป็นสาธารณะ
- โครงการเป็นองค์ประกอบที่จะนำมาใช้ใหม่
- โครงการเป็นก้าวสำคัญสำหรับโครงการอื่น ๆ
- โครงการจะมีโครงการติดตามผลหรือการให้บริการพร้อมการปรับปรุง
หากคุณกำลังสร้างสิ่งที่เป็นสาธารณะหรือกำลังจะถูกนำมาใช้ซ้ำในโครงการอื่น ๆ คุณมีโอกาสสูงที่การออกแบบที่ไม่ดีจะกลับมาหลอกหลอนคุณดังนั้นคุณควรให้ความสำคัญกับเรื่องนั้นมากขึ้น แต่ไม่รับประกันเสมอ
แนวทาง
ฉันจะบอกว่าปฏิบัติตามหลักการต่อไปนี้ให้ดีที่สุดเท่าที่จะทำได้และคุณควรจะอยู่ในตำแหน่งของการออกแบบผลิตภัณฑ์ที่มีประสิทธิภาพและปรับเปลี่ยนได้:
- รู้ว่าYAGNI ,
- KISS ,
- เมื่อใดก็ตามที่คุณรู้สึกอยากเกาคันและคิดการเติมให้จดลงไป มองย้อนกลับไปที่ความต้องการโครงการของคุณและถามตัวเองว่าสิ่งที่เพิ่มเติมตามลำดับความสำคัญหรือไม่ ถามว่าพวกเขาเพิ่มมูลค่าทางธุรกิจหลักหรือไม่
ฉันรู้ว่าฉันมีแนวโน้มที่จะคิดและ overengineer เป็นการส่วนตัว มันช่วยในการเขียนความคิดและบ่อยครั้งที่คิดใหม่ถ้าฉันต้องการคุณสมบัติเพิ่มเติม บ่อยครั้งคำตอบคือไม่หรือ "มันจะเจ๋งในภายหลัง" ความคิดสุดท้ายเหล่านั้นเป็นสิ่งที่อันตรายเพราะมันอยู่ด้านหลังศีรษะของฉันและฉันจำเป็นต้องบังคับตัวเองไม่ให้วางแผนสำหรับพวกเขา
วิธีที่ดีที่สุดในการเขียนโค้ดโดยไม่มีการใช้งานเกินกำหนดและไม่มีการปิดกั้นตัวเองในภายหลังคือการมุ่งเน้นที่การออกแบบที่เรียบง่าย ทำลายสิ่งลงอย่างเป็นส่วนประกอบที่คุณภายหลังสามารถขยาย แต่ไม่ต้องคิดแล้วเกี่ยวกับวิธีที่พวกเขาอาจจะขยายออกไปในภายหลัง คุณไม่สามารถทำนายอนาคตได้
เพียงแค่สร้างสิ่งง่าย ๆ
Dilemmata
Overengineering
นี่คือโปรแกรมเมอร์ทั่วไปที่ตามมาเมื่อทำโครงการเช่นนี้หรือไม่?
ใช่แล้ว. มันเป็นภาวะที่กลืนไม่เข้าคายไม่ออกที่รู้จักกันดีและมันแสดงให้เห็นว่าคุณใส่ใจผลิตภัณฑ์เท่านั้น ถ้าคุณทำไม่ได้นั่นเป็นเรื่องที่น่ากังวลมากขึ้น มีความขัดแย้งกันว่าอะไรจะเกิดขึ้นจริงหรือไม่น้อยกว่าและดีกว่าเสมอ คุณอาจจะเป็นชนิดของคน MIT หรือรัฐนิวเจอร์ซีย์ ไม่มีคำตอบง่าย ๆ ที่นี่
การสร้างต้นแบบ / Quick-n-Dirty / Less เป็นมากกว่า
มันเป็นแนวโน้มทั่วไปที่จะบดตัวอย่างให้ได้โดยเร็วที่สุดหรือไม่?
มันเป็นวิธีปฏิบัติที่แพร่หลาย แต่ไม่ใช่วิธีการที่โครงการส่วนใหญ่เข้าหา ถึงกระนั้นการทำต้นแบบก็เป็นแนวโน้มที่ดีในความคิดของฉัน แต่สิ่งที่มีข้อเสียคือ มันอาจดึงดูดการส่งเสริมต้นแบบที่รวดเร็วและสกปรกให้กับผลิตภัณฑ์จริงหรือใช้เป็นฐานสำหรับผลิตภัณฑ์จริงภายใต้แรงกดดันในการจัดการหรือข้อ จำกัด ด้านเวลา นั่นคือเมื่อต้นแบบสามารถกลับมาหลอกหลอนคุณได้
มีที่เห็นได้ชัดเป็นข้อได้เปรียบในการสร้างต้นแบบแต่ยังมีจำนวนมากที่มีศักยภาพสำหรับการใช้ผิดประเภทและการละเมิด (หลายผกผันแน่นอนของข้อได้เปรียบที่ระบุไว้ก่อนหน้านี้เป็นผลเป็นพิเศษ)
เมื่อใดจึงควรใช้การสร้างต้นแบบ
มีคำแนะนำเกี่ยวกับการเป็นชนิดที่ดีที่สุดของโครงการที่จะใช้ต้นแบบ :
[... ] การสร้างต้นแบบนั้นมีประโยชน์มากที่สุดในระบบที่จะมีปฏิสัมพันธ์กับผู้ใช้จำนวนมาก
[... ] การสร้างต้นแบบมีประสิทธิภาพมากในการวิเคราะห์และออกแบบระบบออนไลน์โดยเฉพาะอย่างยิ่งสำหรับการประมวลผลธุรกรรมที่การใช้กล่องโต้ตอบหน้าจอมีหลักฐานมากขึ้น ยิ่งมีการโต้ตอบระหว่างคอมพิวเตอร์กับผู้ใช้มากเท่าใดก็ยิ่งได้รับประโยชน์มากขึ้นเท่านั้น [... ]
"หนึ่งในการใช้ต้นแบบที่รวดเร็วและมีประสิทธิภาพที่สุดของวันนี้เป็นเครื่องมือสำหรับวิศวกรรมความต้องการของผู้ใช้ซ้ำและการออกแบบส่วนต่อประสานระหว่างมนุษย์และคอมพิวเตอร์"
ในทางกลับกัน:
ระบบที่มีการโต้ตอบกับผู้ใช้เพียงเล็กน้อยเช่นการประมวลผลเป็นชุดหรือระบบซึ่งส่วนใหญ่ทำการคำนวณจะได้ประโยชน์เพียงเล็กน้อยจากการทำต้นแบบ บางครั้งการเขียนโค้ดที่จำเป็นสำหรับการทำงานของระบบอาจจะเข้มข้นเกินไปและผลกำไรที่อาจเกิดขึ้นจากการทำต้นแบบอาจน้อยเกินไป
และถ้าคุณมีสัตว์ประหลาดสีเขียวรอบ ๆ อย่าลืมเก็บต้นแบบไว้ในงบประมาณ ...
