เป็นความคิดที่ดีหรือไม่ที่จะออกแบบสถาปัตยกรรมที่คิดว่าคลาส User Interface สามารถถูกแทนที่ด้วยอินเตอร์เฟสบรรทัดคำสั่งได้?

ใน Code Complete หน้า 25 มีการกล่าวกันว่าเป็นความคิดที่ดีที่จะสามารถแทนที่คลาสส่วนติดต่อผู้ใช้ทั่วไปด้วยบรรทัดคำสั่งหนึ่งได้อย่างง่ายดาย

รู้ถึงข้อดีของการทดสอบแล้วจะเกิดปัญหาอะไรขึ้น

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

ความสามารถในการใช้งานซ้ำภายใต้อินเทอร์เฟซที่แตกต่างกัน (เช่น GUI vs CLI vs REST) ​​ไม่จำเป็นเสมอไป แต่ดีที่มีและเปิดใช้งานการใช้ซ้ำแบบบังเอิญสำหรับระบบในขณะที่คนอื่นหาวิธีใหม่ในการโต้ตอบกับมัน

สิ่งนี้มีข้อบกพร่องเล็กน้อยที่จำเป็นต้องให้น้ำหนัก:

1. มันจะต้องมีเลเยอร์นามธรรมเพิ่มเติม (บางครั้งก็เป็นชั้น) ในขณะที่การมีเลเยอร์เหล่านี้เป็นแนวปฏิบัติทางวิศวกรรมที่ดีพวกเขามีค่าใช้จ่ายเพิ่มเติมในการพัฒนาความเข้าใจที่อาจนำไปสู่การลดความพยายามในด้านอื่น ๆ (เช่นการบำรุงรักษาการใช้ซ้ำการทดสอบ) ดังนั้นจึงคุ้มค่าที่จะไตร่ตรอง
2. การไหลที่เหมาะสมที่สุดสำหรับสื่ออาจน่ากลัวสำหรับผู้อื่น หากการทำงานที่ถูกออกแบบมาเพื่อรองรับ GUI ที่มันอาจจะเป็นช่างพูดเกินไปสำหรับเว็บ ฟังก์ชันการทำงานบางอย่างอาจไม่คุ้มค่าสำหรับทุกสื่อ
3. มีกับดักในการพยายามกำหนดตัวแปลงทั่วไประหว่างบริการและส่วนต่อประสานผู้ใช้ดังนั้นหนึ่งสามารถกำหนดสัญญาบริการและได้มาโดยอัตโนมัติ (หรือมากที่สุด) UI สำหรับสื่อทั้งหมด หลายโครงการสูญเสียความพยายามมากเกินไปในการพยายามสร้างเฟรมเวิร์กดังกล่าวและเพิ่มการปรับแต่งที่เป็นไปได้ทุกอย่างเมื่อความต้องการเปลี่ยนไป

ต้องบอกว่าในประสบการณ์ของฉันการใช้เลเยอร์ดังกล่าวมักจะจบลงด้วยการจ่ายความพยายาม ในบางกรณีฉันจัดการเพื่อปรับใช้ระบบให้ตรงเวลาเพราะเราต้องเปลี่ยนสื่อ (เช่นจากการรวม Web Services ไปยัง UI) สองสามสัปดาห์ก่อนวันครบกำหนด

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

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

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

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

นอกเหนือจากนั้นความสามารถในการทดสอบอัตโนมัติเป็นข้อได้เปรียบที่สำคัญ

ใช่มันเป็นความคิดที่ดีเกือบตลอดเวลา

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

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

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

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

ดังนั้นปัจจัยที่เป็นเช่นกันเมื่อสร้างการทดสอบ

ไม่คำแนะนำนิดหน่อย

มันค่อนข้าง yagni (คุณไม่ต้องการมัน)

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

มันใช้งานไม่ได้กับ UI ใด ๆ ที่ไม่เหมาะกับอินเตอร์เฟสบรรทัดคำสั่ง MS Paint เป็นแอพที่ใช้งานง่าย แต่ในสถานการณ์ใดคุณจะเห็นประโยชน์ที่จะสามารถควบคุมได้จากบรรทัดคำสั่งหรือไม่

มันจะไม่ช่วยให้คุณใช้งานสคริปต์ มันจะขัดขวางความก้าวหน้าในทิศทางนั้น

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

การสร้างสิ่งที่ Mason Wheeler กล่าวว่าการสามารถโต้ตอบกับแอปพลิเคชันผ่านทางบรรทัดคำสั่งทำให้การทำงานอัตโนมัติเป็นเรื่องง่าย

สิ่งนี้มีประโยชน์อย่างยิ่งในการทดสอบ

เพื่อเป็นตัวอย่างในทางปฏิบัติหากฉันต้องการเรียกใช้การทดสอบอัตโนมัติในแอปพลิเคชันฉันอาจต้องการติดตั้งแอปพลิเคชันโดยอัตโนมัติ ในการทำเช่นนี้ฉันอาจส่งผ่านพารามิเตอร์ต่อไปนี้ "myApplication.exe / silentinstall"

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

ลองอีกตัวอย่าง Microsoft Test Manager GUI (มาพร้อมกับ Visual Studio) ช่วยให้ผู้ใช้สามารถเรียกใช้การทดสอบการทำงานจากส่วนต่อประสาน GUI ของมัน แต่ยังมีอินเตอร์เฟสบรรทัดคำสั่งให้ทำสิ่งเดียวกัน (โดยใช้การรวมกันของสวิตช์บรรทัดคำสั่งและอินพุต) นี่หมายความว่าฉันสามารถรวมสคริปต์ PowerShell หรือ DOS เพื่อทำการเปิดตัวการทดสอบอัตโนมัติและฉันสามารถสร้างภารกิจที่กำหนดเวลาไว้เพื่อให้สคริปต์ทำงานทุกคืน

บางแอปพลิเคชันมีสวิตช์บรรทัดคำสั่งที่ระบุให้แอปพลิเคชันเปิดด้วยตัวเลือกบางอย่าง (ตัวอย่างเช่นฉันอาจใช้ '/ ขยาย' เพื่อเปิดแอปพลิเคชันในหน้าต่างที่ขยายใหญ่สุด)

มีสถานการณ์มากมายที่อาจมีการใช้งานอินเตอร์เฟสบรรทัดคำสั่ง นี่เป็นเพียงตัวอย่างบางส่วน

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

ดังนั้นสิ่งที่กล่าวคือ UI ของคุณควรถูกแยกออกจากส่วนที่เหลือของรหัส

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

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

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

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

มันขึ้นอยู่กับ.

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

ความแตกต่างบางอย่างอาจมีอยู่ตามห่วงโซ่เครื่องมือ Code Complete เป็นหนังสือ Microsoft Press ดังนั้นบางทีคุณใช้เทคโนโลยีของ Microsoft สำหรับ GUI นี้ ถ้าเป็นเช่นนั้นฉันคิดว่าอาจมีช่องทำเครื่องหมายเมื่อคุณสร้างแอปสำหรับการเปิดเผยอินเตอร์เฟสผ่าน COM หรือ DCOM สำหรับเทคโนโลยีของ Microsoft บางอย่างฉันคิดว่าตารางทรัพยากรและการส่งข้อความมีความสัมพันธ์อย่างเข้มข้นกับสิ่งใดก็ตามที่พ่อมดช่วยคุณสร้างต้นแบบอย่างรวดเร็ว ฉันคิดว่ามันจะดีขึ้น แต่ถ้าคุณรักษา MFC หรือ Forms มันอาจจะเจ็บเล็กน้อย

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

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

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

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

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

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

ก่อนที่จ็อบส์จะเข้ายึดครอง Apple จะมีการสำรวจกลไกควบคุมเสียงที่ซับซ้อน แอปเปิ้ลบีบสิ่งนี้ในความโปรดปรานของสิ่งต่าง ๆ เช่นสิริ

ถอนหายใจ

ยอดนิยมและชัดเจนไม่ใช่ "ดีที่สุด" เสมอไป

นี่เป็นความคิดที่ดีใช่

โดยคำเปรียบเทียบผู้คนอาจคิดว่านี่เป็นรูปแบบของการออกแบบที่สงบ .... ไม่เช่นนั้นตามปกติ (G) UI อาจเกี่ยวข้องกับธุรกรรมหลายขั้นตอนที่ซับซ้อนเช่นการสร้างบัญชี

Better that one stays away from multi-stage complexity through shopping-cart-like models for transactional setup.

ฉันเคยตั้งโปรแกรมอุปมา UI ของ drag'n'drop ในเบราว์เซอร์ กฎการโต้ตอบที่ซับซ้อนมากบนแบ็คเอนด์เพื่อให้ UX รู้สึกเป็นธรรมชาติ ฉันแก้ไขสิ่งนี้ด้วยการทำให้ไซต์เป็น API และ GUI เป็นแอพเต็มรูปแบบที่สร้างกิจกรรมเมื่อดำเนินการ โมดูลตรวจจับเหตุการณ์เหล่านี้และรวมเวลาเข้ากับ 'การเรียก API' (เพื่อประสิทธิภาพเครือข่าย)

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

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

มีความแตกต่างอย่างมากระหว่าง "สร้างบัญชีธนาคาร" และ "เขียนเอกสารคำ MS" แม้ว่าคุณจะไม่ได้สร้าง CLI แต่ก็อาจเพิ่มมูลค่าให้กับการพิจารณา "บริบท CLI" ที่จำเป็น แบบจำลองไม่ได้อยู่ในรูปแบบวัตถุทางธุรกิจเท่านั้น!