เวิร์กโฟลว์ของโปรแกรมเมอร์ที่ใช้ CLI แตกต่างจาก GUI-oriented อย่างไร

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

ตอนนี้

• ฉันเขียนโค้ดโปรเจ็กต์ด้านข้างในภาษาเช่น C / C ++ / D / C # / Java / Python โดยใช้ Visual Studio, Eclipse และอื่น ๆ และรันโดยการตั้งค่าการตั้งค่าการสร้างและกด F5 เพื่อสร้าง / เรียกใช้

• ฉันกำลังพัฒนาโปรแกรมเว็บในที่ทำงานเพื่อให้เกี่ยวข้องกับการใช้ Django เพื่อตั้งค่าเซิร์ฟเวอร์เชื่อมต่อกับฐานข้อมูลและอื่น ๆ ... เกือบทั้งหมดภายในตัวแก้ไขข้อความ SciTE

• สำหรับการเปิดตัวโปรแกรมปกติฉันใช้ Launchy ... ยังไม่มีเทอร์มินัล :)

• สำหรับการคัดลอกไฟล์และอะไรก็ตามฉันใช้การค้นหา / ย้ายปกติในตัวจัดการไฟล์กราฟิก (Windows Explorer, Nautilus)

• การดีบัก: ฉันใช้ Visual Studio หรือเครื่องมือการดีบักสำหรับ Windows (ถ้าฉันใช้ Windows) ฉันไม่ได้ทำการดีบักบน Linux แต่สำหรับสิ่งที่ฉันทำฉันใช้ Eclipse (เช่นสำหรับ Java บน Windows)

• ที่ทำงาน: เพื่อเชื่อมต่อกับระบบการสร้างและตั้งค่าโครงการฉันแค่ใช้เครื่องมือที่รวมเข้ากับ Eclipse สำหรับการใช้งานของฉัน - ไม่จำเป็นต้องใช้เครื่องเทอร์มินัลหรืออะไรก็ตาม (แม้ว่าฉันจะยินดีใช้เทอร์มินัล แน่นอนต้องการ)

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

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

ประการแรกโปรแกรม GUI สามารถสรุปบริบทสำหรับคุณ ตัวอย่างเช่นฟีเจอร์ Go To Definition และ Intellisense ของ Visual Studio คุณจะทำซ้ำฟีเจอร์เหล่านั้นใน CLI ได้อย่างไร?

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

GUI อาจช้าลงหากคุณต้องการใช้เวลาในการผลักดัน Debug ซ้ำแล้วซ้ำอีก แต่ทันทีที่กรณีการใช้งานมีความซับซ้อนมากขึ้นก็ไม่มีทางที่ CLI จะสามารถติดตามได้

ฉันคิดว่าความแตกต่างที่ยิ่งใหญ่ที่สุดไม่ได้ขึ้นอยู่กับแต่ละงาน แต่มีสองสิ่ง:

ระบบอัตโนมัติอันดับแรกและสำคัญที่สุด CLI สามารถเขียนได้โดยเนื้อแท้ซึ่งโดยปกติแล้วจะยากกว่าบน Windows ฉันเคยได้ยินสิ่งต่าง ๆ ที่ได้รับการปรับปรุงด้วย PowerShell แต่ฉันไม่ได้ใช้

ประการที่สองปรัชญา UNIX ของ "การแยกความกังวล" ฉันสามารถเขียนอินเตอร์เฟสแบบ readline ขนาดเล็กไปยังบางสิ่งบางอย่างและการใช้ emacs Mx shell ใช้ภายใน emacs GUI สิ่งนี้ทำให้การใช้เครื่องมืออื่น ๆ และฟังก์ชั่นที่มีอยู่ง่ายขึ้น

สำหรับการแก้ไขข้อบกพร่อง gdb ทำงานได้ดี แต่ฉันมักจะชอบ VS ดีบักเกอร์ อาจเป็นซอฟต์แวร์ที่ดีที่สุดที่ Microsoft เคยทำ

สำหรับการสร้างและใช้งานสิ่งของ: ทำ หรือทุบตี ที่ไหนก็ตาม

เพื่อการพัฒนา: emacs (ตัวแปลงล่าสุดจาก vi, oh shame!) Vi ถ้าทำงานผ่าน ssh

ฉันไม่คุ้นเคยกับ Eclipse จริงๆ ฉันคิดว่ามันเป็นปัญหา "รูปร่างของจิตใจ": มันไม่เหมาะกับฉัน

สำหรับฉันการเปลี่ยนไปใช้เวิร์กโฟลว์ CLI จาก Visual Studio นั้นเกี่ยวข้องกับการจดจำคำสั่ง * nix จำนวนมาก นอกจากนี้ยังเกี่ยวข้องกับอาการปวดหัวเมื่อใดก็ตามที่ฉันทำระเบียบ SVN

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

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

สิ่งหนึ่งไม่ได้ดีไปกว่าสิ่งอื่น แต่การเปลี่ยนจากสภาพแวดล้อมแบบอิง GUI เป็นเทอร์มินัลเป็นการเดินทาง

นี่คือข้อสังเกตเพิ่มเติมจากโปรแกรมเมอร์ที่อาศัยอยู่ในทั้งสองโลก ฉันจะไม่ทำซ้ำคะแนนในคำตอบอื่น ๆ แล้ว:

การพัฒนาบนพื้นฐานของ CLI นั้นมีแนวโน้มที่จะใช้ความหลากหลายของโปรแกรมโดยแต่ละโปรแกรมจะทำหน้าที่ 1 ฟังก์ชั่น การพัฒนาบนพื้นฐานของ GUI มีแนวโน้มที่จะใช้ 1 โปรแกรมขนาดใหญ่ (IDE) ซึ่งทำหน้าที่ต่าง ๆ มากมาย ความแตกต่างนี้มีผลกระทบหลายประการ:

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

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

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

ใน IDE การสร้างเครื่องมือของคุณเองหมายถึงการเรียนรู้ปลั๊กอิน (อาจมีขนาดใหญ่) API และอาจใช้ภาษาที่เฉพาะเจาะจง เมื่อใช้ CLI ไม่จำเป็นต้องมีอะไรเป็นพิเศษในการสร้างเครื่องมือแบบกำหนดเอง

ในทางตรงกันข้ามข้อดีของ IDE คือมันคือ "รวม" ดังนั้นคุณสามารถคลิกในหน้าต่างตัวแก้ไขของคุณเพื่อตั้งจุดพักดีบั๊กและอื่น ๆ

อีกจุดหนึ่ง: ตัวเลือกของคุณจะขึ้นอยู่กับแพลตฟอร์มการพัฒนาระบบปฏิบัติการและภาษาที่คุณใช้ ในบางแพลตฟอร์มการพัฒนาบน IDE จะฝังลึกในวัฒนธรรมการพัฒนาที่แพร่หลาย ในคนอื่น ๆ การพัฒนาบนพื้นฐานของ CLI นั้นเป็นที่แพร่หลาย หากคุณกำลังใช้แพลตฟอร์มที่มีการพัฒนาบน IDE เป็นที่แพร่หลายมีแนวโน้มว่าเครื่องมือ CLI จะได้รับการพัฒนาอย่างไม่ดีและได้รับการสนับสนุนไม่ดี การสนทนาก็เป็นจริงเช่นกัน

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

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

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

"เปลี่ยนเป็นกูรูของ CLI ข้ามคืนหรือไม่" ใช่มีถู GUIs ที่ออกแบบมาอย่างดีมีแนวโน้มที่จะค้นพบได้มากกว่า CLIs และให้อภัยกับ newbie

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

ส่วนใหญ่ฉันใช้เบราว์เซอร์เป็นกลุ่มและเทอร์มินัลมากมาย SSH ให้ความยืดหยุ่นกับฉันเป็นอย่างมาก เดสก์ท็อประยะไกลอาจมอบประสบการณ์ที่ดีกว่าเมื่อเราทุกคนมีท่อ 10Gigabit ต่อเน็ต แต่ฉันจะไม่กลั้นหายใจ

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

ปัญหาที่แท้จริงคืออินเทอร์เฟซที่ออกแบบมาไม่ดี อินเทอร์เฟซที่ออกแบบมาอย่างดีนั้นยากที่จะสร้างดังนั้นจึงไม่เกิดขึ้นบ่อยครั้งในทั้งสองค่าย แต่เนื่องจากตัวช่วยสร้างที่ไม่ใช่ ux-wiz กำลังออกแบบ GUIs ในปัจจุบันมากกว่า CLIs, ....

(สัตว์เลี้ยงขนาดใหญ่อื่น ๆ ของฉันเปื่อยตัวบวมเมื่อใช้โปรแกรมขนาด 19MB เพื่อช่วยให้ฉันทำงานได้สำเร็จเช่นเดียวกับโปรแกรม 200kB มีบางอย่างผิดปกติ XTree Gold for DOS ปรับปรุงประสิทธิภาพการทำงานของฉันมากกว่าตัวจัดการไฟล์สมัยใหม่ Windows 2.11 ใช้กระเบื้องเท่านั้น windows. Turbo C เป็น IDE ที่ยอดเยี่ยม. ทำไม Nook ของฉันถึงทำงานช้ากว่า Mac classic ทำไมเคอร์เนลเพียงอย่างเดียวจึงใช้พื้นที่ดิสก์มากกว่าระบบที่เคยใช้?)

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

การเขียนโปรแกรมในเทอร์มินัลอาจจะไม่ดีไปกว่าในโปรแกรมแก้ไขกราฟิกเว้นแต่ว่าคุณใช้ SSH

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

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

ฉันมีการถกเถียงกันในเรื่องคำสั่งคีย์บอร์ดกับเมาส์

วิธีการทำงานของฉันโปรดปราน GUI โดยไกล

การใช้งานทั่วไป:

• สาม IDEs สำหรับสามแพลตฟอร์มที่แตกต่างกัน นอกจากนี้ยังมีหน้าต่าง Notepad ++ สำหรับบางสคริปต์ ไม่มีทางที่ฉันจะสามารถจำคำสั่งสำหรับระบบบิลด์เหล่านั้นได้ทั้งหมด ปัญหาของ CLI คือคุณจำเป็นต้องรู้รายละเอียดมากมายเพื่อให้บิลด์ทำงานได้ Modern IDES โดยปกติจะมีตัวเลือกที่เหมาะสมในการตั้งค่าเริ่มต้น คุณสามารถดูได้ใกล้ขึ้นเมื่อถึงเวลา
• รวม SVN หรือ Git มีตัวเลือกมากมายสำหรับโปรแกรมที่สนับสนุนการเขียนโปรแกรมและส่วนใหญ่เวลาที่ฉันทำเพียงกระทำหรือปรับปรุง
• เนื้อหาของเครือข่าย: โชคดีฉันได้ทำการตั้งค่าเครือข่ายทั้งหมดในสำนักงานของเราด้วย บอร์ดเครือข่ายส่วนใหญ่จะให้คำสั่ง CLI จำนวนมากแก่คุณ แต่ถ้ามีสิ่งหนึ่งที่คุณต้องการภาพรวมของสถานะก็คือไฟร์วอลล์และการกำหนดเส้นทาง สำหรับการกำหนดเส้นทางฉันสามารถใช้งานได้จริงกับ command line แต่ไฟร์วอลล์มีความซับซ้อนและหากมีสิ่งหนึ่งที่ GUIs ทำได้ดีก็จะแสดงข้อมูลจำนวนมาก
• โดยทั่วไปมีการเคลื่อนไหวจากสิ่งหนึ่งไปอีกสิ่งหนึ่งเป็นจำนวนมาก บริบทของสวิทช์ง่ายขึ้นด้วยบริบทภาพ

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