มันจะมีประโยชน์ในการสร้างแอปพลิเคชันที่เริ่มต้นด้วย GUI หรือไม่?

แนวโน้มในการออกแบบและพัฒนาแอพพลิเคชั่นดูเหมือนจะเริ่มต้นด้วย "ความกล้า": โดเมนจากนั้นเข้าถึงข้อมูลจากนั้นก็เป็นโครงสร้างพื้นฐานเป็นต้น GUI ดูเหมือนว่าโดยปกติจะมาในภายหลัง ฉันสงสัยว่ามันจะมีประโยชน์ในการสร้าง GUI ก่อนหรือไม่

เหตุผลของฉันคือการสร้าง GUI ต้นแบบอย่างน้อยคุณจะได้ความคิดที่ดีขึ้นเกี่ยวกับสิ่งที่ต้องเกิดขึ้นเบื้องหลังและดังนั้นจึงอยู่ในตำแหน่งที่ดีกว่าในการเริ่มทำงานในโดเมนและรหัสการสนับสนุน

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

อาจเป็นความคิดที่เป็นไปได้สำหรับโครงการจริงหรือ บางทีเราอาจเพิ่ม GDD (การพัฒนา GUI ขับเคลื่อนด้วย) ไปยังตัวย่อที่เสถียร ...

การสร้างต้นแบบ GUI ที่รวดเร็วเป็นความคิดที่ดีและฉันได้ยินมาว่ามันถูกใช้ในหลายโครงการ ข้อเสนอแนะก่อนมีคุณค่าแน่นอน อย่างไรก็ตามมันมีอันตราย:

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

การลดความเสี่ยงเหล่านี้จำเป็นต้องมีการอภิปรายอย่างแข็งขันและอาจเป็นการให้ความรู้แก่ผู้ใช้และ / หรือผู้จัดการของคุณ

ปัญหาที่ฉันเห็นด้วยคือเป้าหมายดูเหมือนว่าจะย้อนกลับไปโดยสิ้นเชิง

"เหตุผลของฉันคือการสร้าง GUI ต้นแบบอย่างน้อยคุณจะได้แนวคิดที่ดีกว่าว่าจะต้องเกิดอะไรขึ้นเบื้องหลังและอยู่ในตำแหน่งที่ดีกว่าที่จะเริ่มทำงานในโดเมนและรหัสสนับสนุน"

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

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

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

การสร้างต้นแบบสามารถทำได้ดีสำหรับการรวบรวมข้อกำหนดและข้อตกลง แต่ก็ควรทิ้งไป อย่าใช้อะไรจากรหัสต้นแบบในผลิตภัณฑ์จริง

ฉันคิดว่า @ Péterถูกต้องแล้วที่จะแนะนำว่าการสร้างต้นแบบ GUI เป็นความคิดที่ดี ฉันต้องการเสริมด้วยข้อผิดพลาดที่อาจเกิดขึ้นจากการให้ประสบการณ์ผู้ใช้ในลักษณะที่ล้าหลังนั่นคือการเน้นไปที่ ontology สถาปัตยกรรมและโครงสร้างพื้นฐานเป็นอันดับแรก

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

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

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

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

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

สิ่งนี้เกี่ยวข้องกับการออกแบบเว็บเซอร์วิสหรือ API อื่น ๆ เช่นเดียวกับที่รู้จักกันในชื่อการออกแบบ " สัญญาแรก "

ดังนั้นสำหรับทุกสิ่งไม่มีกฎว่าจะออกแบบอะไรก่อน บางครั้งเป็นรุ่นและบางครั้งก็เป็น GUI ตามกฎของหัวแม่มือฉันจะไปกับ "ออกแบบส่วนที่สำคัญที่สุดก่อน"

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

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

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

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

และทำไมคุณต้องการที่จะทิ้ง protoype? เราไม่ได้จัดการกับสนามกีฬาที่สร้างขึ้นจากไม้ขีดไฟ เพียงปรับสภาพสิ่งแช่งให้เป็นสิ่งที่ดี

ฟังดูไม่ดีสำหรับฉันเลยถ้าคนที่ดู GUI เข้าใจว่ามันเป็นแค่เปลือกหอยและปุ่มและกระบวนการต่าง ๆ ใช้งานไม่ได้ (ไม่ใช้ NotImplementedException ();;))

หากคุณยึดถือการใช้สถาปัตยกรรมสไตล์ MVC ฉันจะไม่คาดการณ์ปัญหาการบำรุงรักษาหรือการก่อสร้างในอนาคตเนื่องจาก "มุมมอง" ไม่ได้กำหนดประเภทใด ๆ เลย "ตัวควบคุม" และ "แบบจำลอง" สามารถมาพร้อมกับโครงสร้างพื้นฐานใด ๆ ที่คุณต้องการสำหรับความต้องการด้านความยืดหยุ่น / การออกแบบเป็นต้น

สำหรับการจัดการให้วาดแผนภูมิวงกลมขนาดใหญ่ที่มี 3 ส่วนติดป้าย "M", "V" และ "C" ให้ V ประมาณ 20% และอธิบายส่วนที่เหลือของพายคือ "TBC";)

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

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

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

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

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