การพัฒนาแอพพลิเคชั่น CLI ถือเป็น“ ย้อนกลับ” หรือไม่? [ปิด]

ฉันเป็น DBA ที่เต็มไปด้วยประสบการณ์มากมายในการเขียนโปรแกรม

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

ฉันพบว่าแอพ CLI นั้นยอดเยี่ยมเพราะคุณสามารถรวมไว้ในเวิร์กโฟลว์อัตโนมัติ

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

เจ้านายของฉันเพิ่งแสดงความคิดเห็นว่าการพัฒนาเครื่องมือ CLI นั้น "ย้อนกลับ" หรือถือเป็นการ "ถดถอย"

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

การพัฒนาแบบนี้ถือว่าเป็น "ถอยหลัง" ในตลาดหรือไม่?

มันดูไม่ดีกับrèsumèหรือไม่?

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

เป้าหมายนี้คุ้มค่าสำหรับโครงการซอฟต์แวร์หรือไม่?

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

การมีความสามารถในการทำงานกับ CLI นั้นแทบจะไม่เป็นสิ่งที่ฉันจะพิจารณาย้อนหลัง มันดูดีมากในเรซูเม่โดยเฉพาะอย่างยิ่งถ้าคุณสามารถหมุนมันในเรซูเม่ของคุณด้วยวลีเช่น "ใช้แล้ว (Powershell / Bash) เพื่อสร้างชุดเครื่องมืออัตโนมัติเพื่อส่งข้อความ SMS เมื่อฐานข้อมูลล่ม"

เมื่อฉันรับผิดชอบในการจ้างคนความรู้ในการทำงานของ CLI คือสิ่งที่ฉันมองหา

โดยพื้นฐานแล้วมันลงมาที่ "ใช้เครื่องมือที่เหมาะสมสำหรับงาน"

หากคุณต้องโต้ตอบกับผู้ใช้คุณจะต้องมี GUI บางประเภท เรามีการวิจัยและประสบการณ์มานานหลายทศวรรษแสดงให้เห็นว่าพวกเขาทำให้การคำนวณง่ายขึ้นและมีประสิทธิภาพมากขึ้น นั่นเป็นเหตุผลที่ GUIs ได้ยึดครองโลกอย่างไม่ลดละนับตั้งแต่ปี 1984 พวกเขาทำงานได้ดีขึ้นในการโต้ตอบกับผู้คน

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

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

การเขียนโปรแกรม The Art of Unix ของ Eric Raymond เป็นงานที่เป็นที่ยอมรับสำหรับการโต้แย้งที่คุณทำ ฉันจะไม่พยายามย่อหนังสือยอดเยี่ยมของเขาออกเป็นสองสามย่อหน้า อย่างไรก็ตามโปรดทราบว่าข้อโต้แย้งส่วนใหญ่จะใช้กับโปรแกรมเมอร์ผู้ดูแลระบบทำงานอัตโนมัติโดยใช้สคริปต์หรือผู้ใช้ขั้นสูงของซอฟต์แวร์ด้านเทคนิคอย่าง CAD

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

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

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

ไม่ใช่เพียง Unix ที่ขับเคลื่อนโดยโปรแกรมบรรทัดคำสั่ง Microsoft กำลังมุ่งหน้าไปทางนั้นเช่นกัน

Microsoft ผลักดัน PowerShell ไประยะหนึ่งแล้ว ซอฟต์แวร์เซิร์ฟเวอร์ปัจจุบันทั้งหมด (Exchange, SharePoint, Server 2012, System Center, ฯลฯ ) สามารถควบคุมได้อย่างสมบูรณ์ผ่านบรรทัดคำสั่ง PowerShell และ PowerShell พึ่งพาฟังก์ชั่นเล็ก ๆ ที่ทำสิ่งหนึ่งได้ดีและไปป์ data ต่อไปอีกอันหนึ่ง (แม้ว่ามันจะไปป์ออบเจ็กต์แทนที่จะเป็นข้อความ)

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

ดังนั้นถ้า * ระวังทำไปแล้วและ Microsoft ก็กำลังมุ่งหน้าไปทางนั้น ... ดูเหมือนจะไม่ย้อนกลับไปที่ฉัน!

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

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

การคืบของขอบเขตนั้นไร้สาระด้วยแอป GUI มันง่ายมากที่จะหลีกเลี่ยงด้วยแอป CLI "คุณต้องการแก้ไขไฟล์แล้วบันทึกใหม่หรือไม่cat foo > ed > bar" ด้วยแอป CLI มันเป็นเรื่องเล็กน้อยสำหรับผู้ใช้ของคุณ (ไม่ใช่คุณผู้พัฒนา) เพื่อรวมเข้ากับเครื่องมืออื่น ๆ

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

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

ดีเครื่องมือ CLI ช่วยให้ผู้ใช้ในการทำสิ่งที่คนที่เขียนเครื่องมือไม่เคยคิดว่า ตัวอย่างหนึ่งคือคำสั่ง 'find' ของ UNIX คำสั่งนี้:

find . -type f -name xyzzy\* -maxdepth 5 -mtime +3 -exec rm {} \;

ค้นหาไฟล์ภายใต้ไดเรกทอรีปัจจุบัน (แต่ จำกัด ไม่เกิน 5 ระดับ) ที่มีชื่อขึ้นต้นว่า 'xyzzy' และถูกแก้ไขมากกว่า 3 วันที่แล้วและลบออก (หมายเหตุ: รหัสที่ยังไม่ทดลอง) และนั่นเป็นการใช้งานที่เรียบง่ายในระดับปานกลาง คุณสามารถใช้ตัวจัดการไฟล์เพื่อทำสิ่งนั้นได้ แต่จะใช้เวลานานกว่าและเกิดข้อผิดพลาดได้ง่าย แน่นอนว่าการมีประสิทธิภาพมากขึ้นหมายถึง CLI นั้นสามารถนำไปใช้ในทางที่ผิดได้ง่ายขึ้นและสร้างปัญหาให้กับคุณ

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

การอ่านที่ดี (ยาวและเอนเอียง (?)) บนการแลกเปลี่ยน CLI / GUI อยู่ที่:

http://www.cryptonomicon.com/beginning.html

ไม่มันไม่ย้อนกลับเลย

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

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

มีสิ่งนี้โดย Paul Ferris: http://www.linuxplanet.com/linuxplanet/opinions/1505/1

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

การตั้งค่าส่วนตัวของฉันเกี่ยวกับเรื่องนี้คือเครื่องมือ CLI ที่ให้ตัวเลือก - กุยหรือ --verbose เพียงพอที่จะให้ GUI wrapper โต้ตอบอย่างมีประสิทธิภาพรวมถึงแถบสถานะและองค์ประกอบพื้นฐานอื่น ๆ ที่ผู้ใช้มองหา GUI

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

ฉันพบวิธีนี้ใน SGI IRIX และชอบมันมาก ฉันพบว่าตัวเองกำลังใช้ GUI หรือบรรทัดคำสั่งตามต้องการและสิ่งที่ดีคือการรู้ว่าปุ่มแฟนซีกำลังทำอะไรอยู่

ในกรณีที่มีสภาพแวดล้อมการทำงานที่แตกต่างกันมากตัวห่อ GUI สามารถแตกต่างกันมากโดยไม่ส่งผลกระทบต่อเครื่องมือ CLI เช่นกัน

ฉันเห็นสิ่งนี้ใน Linux วันนี้ด้วยสิ่งต่าง ๆ เช่นเครื่องมือดิสก์ / ระบบไฟล์ซึ่ง GUI สามารถเพิ่มคุณค่าได้มากมายแม้แต่กับผู้ใช้ที่คุ้นเคยของ CLI

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

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