Apakah pengembangan aplikasi CLI dianggap "terbelakang"? [Tutup]


38

Saya pemula DBA dengan banyak pengalaman dalam pemrograman.

Saya telah mengembangkan beberapa aplikasi CLI, non-interaktif yang menyelesaikan beberapa tugas harian yang berulang-ulang atau menghilangkan kesalahan manusia dari tugas yang lebih kompleks walaupun tidak begitu sehari-hari. Alat-alat ini sekarang menjadi bagian dari kotak alat kami.

Saya menemukan aplikasi CLI sangat bagus karena Anda dapat memasukkannya dalam alur kerja otomatis.

Juga filosofi Unix untuk melakukan satu hal tetapi melakukannya dengan baik, dan membiarkan output dari suatu proses menjadi input dari yang lain, adalah cara yang bagus untuk membangun satu set alat daripada akan dikonsolidasikan ke dalam keuntungan strategis.

Bos saya baru-baru ini berkomentar bahwa mengembangkan alat CLI adalah "mundur", atau merupakan "regresi".

Saya mengatakan kepadanya bahwa saya tidak setuju, karena sebagian besar alat CLI yang ada sekarang bukan warisan tetapi proyek langsung dengan versi yang ditingkatkan dirilis sepanjang waktu.

Apakah perkembangan semacam ini dianggap "terbelakang" di pasar?

Apakah terlihat buruk pada resume?

Saya juga mempertimbangkan semua solusi apakah itu web atau desktop, harus memiliki baris perintah, opsi non-interaktif. Beberapa orang menganggap ini sebagai pemborosan sumber daya pemrograman.

Apakah tujuan ini layak dalam proyek perangkat lunak?

Saya juga berpikir bahwa untuk aplikasi web atau desktop, memiliki antarmuka CLI alternatif adalah cara yang bagus untuk menunjukkan bahwa logika bisnis sepenuhnya dipisahkan dari GUI.


32
Apakah bos Anda berasal dari latar belakang teknis? Sepertinya dia mengikuti filosofi "Saya tidak melihat banyak, ergo tidak ada banyak". Yang bisa bermasalah. Tanyakan kepadanya apakah menurutnya orang-orang yang mengembangkan Oracle juga mundur.
Joachim Sauer

13
Saya suka hal-hal yang dilakukan di dunia Linux. Sebagian besar aplikasi 'utama' memiliki front CLI dan GUI - ini adalah pembebasan karena Anda dapat membuat skrip saat Anda perlu dan mengklik dengan mouse Anda saat Anda tidak perlu. Saya tidak mengerti mengapa Anda perlu memilih yang satu vs yang lain. Tidak perlu banyak pekerjaan untuk menulis CLI.
MrFox

6
Bos Anda jelas tidak pernah mencoba menulis naskah paling dasar
toasted_flakes

1
@ McFox Saya setuju dengan Anda, aplikasi harus memiliki kedua ujung depan.
Tulains Córdova

4
Saya suka ini tetapi sayangnya kadang-kadang ada juga ini ;)
wim

Jawaban:


21

Memiliki kemampuan untuk bekerja dengan CLI bukanlah hal yang saya anggap mundur. Ini terlihat hebat pada resume, terutama jika Anda dapat memutarnya pada resume Anda dengan frase seperti "Digunakan (Powershell / Bash) untuk membangun seperangkat alat otomatisasi untuk mengirim pesan SMS ketika Database turun".

Ketika saya bertanggung jawab untuk merekrut orang, pengetahuan tentang CLI adalah sesuatu yang saya cari.


49

Itu pada dasarnya turun untuk "menggunakan alat yang tepat untuk pekerjaan itu."

Jika Anda harus berinteraksi dengan pengguna, Anda akan menginginkan semacam GUI. Kami memiliki beberapa dekade penelitian dan pengalaman yang menunjukkan bahwa mereka membuat komputasi jauh lebih intuitif dan produktif. Itu sebabnya GUI telah mengambil alih dunia sejak 1984: mereka bekerja lebih baik untuk berinteraksi dengan orang-orang.

Tetapi jika Anda mengotomatisasi suatu program dengan skrip, program Anda tidak berinteraksi dengan orang-orang; itu berinteraksi dengan skrip. Dan antarmuka terbaik untuk itu adalah berbasis teks, untuk alasan yang seharusnya jelas secara intuitif.

Pengembangan program CLI untuk pengguna untuk bekerja secara langsung dianggap mundur, dan dengan alasan yang bagus. Tetapi jika itu bukan yang Anda lakukan, jika Anda menulis alat produktivitas otomasi, maka Anda tidak melakukan kesalahan dengan memberi mereka CLI.


6
+1 Nah beberapa alat memberikan informasi kepada pengguna, seperti "apakah semua cadangan basis data mutakhir, jika tidak, beri tahu saya yang mana yang lama?". Mereka mencetak jawaban untuk STDOUT. Tapi jelas itu bisa diletakkan di crontab untuk mengirim SMS jika jawabannya TIDAK. Saya pikir bahkan jika aplikasinya adalah GUI, seharusnya memiliki mode CLI dengan parameter. Saya sendiri pengagum GUI, bagaimanapun juga saya adalah pengguna Mac. Banyak aplikasi penting bisnis, khususnya yang dikembangkan in-house tidak pernah merenungkan CLI.
Tulains Córdova

23
Sementara saya 99% setuju, saya juga menemukan bahwa, sebagai pengguna teknis, kadang-kadang saya lebih suka CLI daripada GUI. Alasannya adalah karena banyak GUI mengharuskan saya untuk menavigasi, mengarahkan, mengklik, menelusuri menu, mencari kotak centang yang tepat, dll. Namun pada CLI, yang harus saya lakukan adalah menerjemahkan bahasa Inggris di kepala saya ke "Computerish" on baris perintah, dan program melakukan apa yang saya inginkan dalam waktu kurang. Jadi, sementara GUI jauh lebih mudah bagi pengguna biasa, pengguna listrik keras terkadang lebih suka CLI.
Phil

15
"Pengembangan program CLI bagi pengguna untuk bekerja secara langsung dianggap terbelakang, dan dengan alasan yang bagus" um, tidak, tidak sesederhana itu, karenanya mengapa aplikasi GUI yang cukup canggih akhirnya menyematkan beberapa mesin skrip dengan CLI
jk sendiri.

11
@MasonWheeler: Saya pikir Anda kehilangan poin jk. Ketika GUI menjadi rumit, pengguna yang mengerti teknologi sering lebih suka menggunakan mesin skrip CLI bahkan untuk tugas sekali saja . Yang pasti adalah "pengguna yang bekerja dengannya secara langsung".
ruakh

8
-1 pada "pengembangan program CLI bagi pengguna untuk bekerja secara langsung dianggap terbelakang, dan dengan alasan yang bagus" ini sepenuhnya tergantung pada aplikasi. Sering kali sebagai pengguna saya perlu bekerja dengan program untuk dijalankan pada mesin yang bahkan tidak memiliki GUI atau monitor. Saya yakin sekali butuh CLI!
wim

35

The Art of Unix Programming karya Eric Raymond adalah karya kanonik untuk argumen yang Anda buat. Saya tidak akan mencoba menyingkat bukunya menjadi beberapa paragraf. Namun, perlu diingat bahwa argumen sebagian besar berlaku untuk programmer, administrator mengotomatisasi tugas menggunakan skrip, atau memberi kekuatan pengguna perangkat lunak yang sangat teknis seperti CAD.

Bahkan dengan pengguna yang sangat teknis, Anda harus mempertimbangkan topi mana yang mereka kenakan saat itu. Sebagai contoh, saya menulis perangkat lunak tertanam untuk peralatan jaringan untuk mencari nafkah. Semua produk kami memiliki CLI dan GUI, tetapi pengembang hampir secara universal lebih menyukai CLI, karena fleksibilitas, skripibilitas, ketersediaan, kecepatan, dll.

Namun, kelompok pengembang yang sama persis lebih suka GUI pada perangkat lunak kontrol versi kami, meskipun CLI-nya lebih kuat dan didukung dan didokumentasikan sama halnya dengan GUI. Perbedaannya adalah kita adalah pengguna akhir dari perangkat lunak kontrol versi, bukan administrator atau pengembang.

Jadi, pertimbangkan dengan cermat peran apa yang dilakukan pengguna saat mereka menggunakan utilitas Anda, dan rencanakan antarmuka pengguna sesuai dengan itu. Jika bos Anda menyebutkannya, kemungkinan Anda perlu meningkatkan dokumentasi dan / atau pelatihan tentang CLI paling tidak. Jika Anda terus-menerus memberi tahu orang-orang bahwa fitur hanya tersedia di CLI ketika mereka mengharapkannya untuk GUI, Anda mungkin perlu memikirkan kembali prioritas pengembangan Anda, dengan mempertimbangkan kebutuhan pengguna Anda dengan lebih baik.


16

Bukan hanya Unix yang didorong oleh program baris perintah. Microsoft juga menuju ke sana.

Microsoft telah mendorong PowerShell untuk beberapa waktu sekarang. Semua perangkat lunak server mereka saat ini (Exchange, SharePoint, Server 2012, System Center, dll) dapat sepenuhnya dikontrol melalui baris perintah PowerShell. Dan PowerShell bergantung pada fungsi-fungsi kecil yang melakukan satu hal dengan baik dan menyalurkan data ke yang berikutnya (meskipun itu menyalurkan objek bukan hanya teks).

Sebagian besar GUI untuk program-program itu hanyalah tampilan depan dari perintah PowerShell, banyak yang bahkan memberi tahu Anda apa perintah yang akan dijalankan untuk membuat skrip lebih mudah. Semua yang dapat Anda lakukan dari GUI dapat Anda lakukan dari PowerShell. Kebalikannya tidak benar - ada beberapa fungsi yang diekspos hanya di PowerShell.

Jadi jika * nix selalu melakukannya, dan Microsoft sedang menuju ke sana ... sepertinya tidak terlalu terbelakang bagi saya!


5
Hanya untuk menambah ini: Microsoft mendorong jauh dari GUI di server secara besar - besaran . Mereka ingin semua orang menjalankan Server Core - tanpa GUI, titik. Jika Anda dapat membuat skrip satu set tugas pada satu mesin, Anda dapat skrip itu di seluruh perusahaan - semoga berhasil melakukannya dengan GUI. Jeffrey Snover (lead architecht untuk Windows) memberikan wawancara yang baik tentang topik tersebut.
alroc

4
"Windows" tidak menuju ke arah itu; Windows Server adalah. Server dimaksudkan untuk berjalan sebagai sistem otomatis dengan interaksi manusia minimal, sehingga masuk akal. Tetapi Anda tidak akan pernah melihat itu terjadi pada bagian OS yang menghadap pengguna.
Mason Wheeler

3
Juga, Mac OS X beralih dari GUI murni ke arsitektur * nix dengan fokus yang kuat pada skrip baris perintah. Oleh karena itu, saya akan mengatakan bahwa Microsoft dan Apple telah menuju ke lebih banyak CLI.
Brandon

1
+1 Saya harus menjelaskan kepada orang-orang level C bagaimana 'Windows' akan kembali ke teks. Masuk akal - setiap tindakan dapat ditulis, diuji, dan diluncurkan ke ribuan server daripada masuk ke setiap kotak dan mencoba mereplikasi 200 klik mouse secara akurat. OP harus menggunakan keterampilannya sebagai scripting / automation daripada hanya sebagai CLI. IIRC Windows menawarkan dukungan PowerShell dari XP dan seterusnya. Sangat bagus untuk menginstal pre-reqs dengan satu skrip alih-alih banyak mengklik.
jqa

Anda benar, tetapi perlu diingat bahwa untuk massa pengguna komputer (bodoh), GUI akan menjadi satu-satunya hal yang mereka ketahui dan lihat ... ini terutama benar jika Anda mempertimbangkan fakta bahwa GUI lebih tua daripada banyak. dari mereka ...
Radu Murzea

4

Saya pasti tidak akan mengatakan itu hal yang buruk. Yang menyenangkan tentang program CLI adalah ketika mengimplementasikannya Anda dapat memiliki cakupan yang sangat terbatas. Sebagai contoh, jika saya ingin menulis catklon atau "program untuk mencetak isi file ke layar", itu sangat layak dilakukan dengan CLI.

Namun, bagaimana jika Anda tidak menggunakan CLI, maka Anda akan memiliki program dasar dengan GUI yang menampilkan beberapa teks. Tetapi kemudian Anda juga harus mengikat dalam membuka dialog file dan mengaitkannya .. tetapi kemudian seseorang juga ingin dapat memodifikasi teks dan menyimpannya di tempat lain ..

Cakupan creep konyol dengan aplikasi GUI. Sangat mudah untuk menghindarinya meskipun dengan aplikasi CLI. "Anda ingin mengedit file dan kemudian menyimpannya? cat foo > ed > bar" Dengan aplikasi CLI itu sepele bagi pengguna Anda (bukan Anda, pengembang) untuk menggabungkannya dengan alat lain.

Sekarang, yang dikatakan, program CLI mulai dilihat sebagai "mundur". Ini karena banyak pengembangan aplikasi dewasa ini terjadi di pasar di mana pengguna yang menggabungkan alat Anda dengan alat lain nyaris tidak mungkin. Saya tidak akan membahasnya di sini, tapi saya memang menulis posting blog tentang bagaimana "pasar memberlakukan mentalitas yang tidak ada", yang merupakan kebalikan dari aplikasi CLI yang dirancang dengan baik (untuk melakukan satu hal dan melakukannya dengan baik )


4

GUI dan CLI keduanya memiliki tempat masing-masing. GUI sangat bagus untuk memungkinkan pengguna untuk melakukan operasi kalengan tertentu dengan cepat. CLI adalah untuk saat Anda ingin melakukan hal-hal yang GUI tidak memungkinkan Anda untuk melakukannya. CLI biasanya lebih kuat dan lebih sulit digunakan.

Sebuah baik alat CLI memungkinkan pengguna untuk melakukan hal-hal orang yang menulis alat tidak pernah memikirkan. Salah satu contoh adalah perintah 'temukan' UNIX. Perintah ini:

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

menemukan file di bawah direktori saat ini (tetapi terbatas pada 5 level ke bawah) yang memiliki nama yang dimulai 'xyzzy' dan telah dimodifikasi lebih dari 3 hari yang lalu dan kemudian menghapusnya (catatan: kode yang belum diuji). Dan itu penggunaan yang cukup sederhana. Anda dapat menggunakan manajer file untuk melakukan hal semacam itu, tetapi akan memakan waktu lebih lama dan rentan kesalahan. Tentu saja, menjadi lebih kuat berarti CLI dapat lebih mudah disalahgunakan dan menciptakan masalah bagi diri Anda sendiri!

Pengembang yang baik dapat menulis alat CLI sedemikian rupa sehingga juga memiliki GUI yang memungkinkan serangkaian operasi terbatas dilakukan. Pengguna dapat mulai dengan GUI dan mempelajari kompleksitas CLI nanti.

Bacaan yang bagus (panjang dan bias (?)) Di trade off CLI / GUI ada di:

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

1
+1, terutama untuk referensi "In the Beginning was the Command Line"
Ben Lee

1

Tidak, itu tidak mundur sama sekali.

"Arahan" banyak terkait dengan perspektif kita. Seorang pengguna senang dengan jalur saat ini menuju antarmuka sederhana, "satu pengalaman semua perangkat" akan melihat CLI sebagai kemunduran atau regresi pasti. Itu tidak sesuai dengan harapan mereka secara keseluruhan.

Seorang programmer, administrator atau pengguna listrik mungkin melihatnya sebagai perkembangan logis dari alat sesuai dengan pengalaman mereka. Banyak dari ini mulai menggunakan alat GUI. Ketika mereka ingin atau perlu mengukur, mereka dengan cepat mencari tahu mengapa CLI ada dan perkembangan itu beresonansi dengan mereka yang membangun lebih banyak alat CLI.

Ada ini oleh Paul Ferris: http://www.linuxplanet.com/linuxplanet/opinions/1505/1

Bagi saya pribadi, gagasan sintaksis membedakan keduanya. Ketika sintaks agak hadir dalam GUI, hasilnya hampir tidak pernah baik dan sefleksibel sintaks CLI. Ketika ini digabungkan dengan pipa dan pengalihan, GUI jatuh datar karena itu tidak terlalu berguna di luar kasus penggunaan yang direncanakan.

Preferensi pribadi saya tentang ini adalah alat CLI yang menawarkan opsi - gui atau --verbose yang cukup untuk memungkinkan pembungkus GUI untuk berinteraksi dengan cara yang kuat termasuk bilah status dan elemen dasar lainnya yang dilihat orang untuk GUI.

Tentu saja biaya ini pada dasarnya adalah dua program dengan satu agak tidak berguna tanpa yang lain, tetapi manfaat utama adalah dapat menggabungkan satu atau lebih alat CLI yang hebat ke dalam GUI kustom tanpa modifikasi ke alat CLI tersebut. Paling sering ini hanya dilakukan untuk menawarkan opsi GUI pada CLI tertentu, tetapi gagasan mengemudi beberapa alat dengan satu "proses" atau "use case" yang berorientasi GUI dapat memberikan hasil yang mirip dengan pemipaan dan pengalihan dan pembuatan skrip untuk kasus penggunaan tersebut, membuatnya tersedia bagi orang-orang yang tidak akan melakukan operasi-operasi itu secara cukup teratur untuk mencapai penguasaan sementara masih tidak menghambat pengguna CLI.

Saya menemukan pendekatan ini pada SGI IRIX dan sangat menyukainya. Saya menemukan diri saya menggunakan GUI atau baris perintah sesuai kebutuhan dan yang menyenangkan adalah mengetahui persis apa yang sebenarnya dilakukan tombol mewah.

Di mana ada banyak lingkungan operasi yang berbeda, pembungkus GUI dapat sangat berbeda tanpa berdampak pada alat CLI juga.

Saya melihat ini di Linux hari ini dengan hal-hal seperti alat disk / sistem file, di mana GUI dapat menambahkan banyak nilai bahkan untuk pengguna yang akrab dengan CLI.

Dalam kasus filesystem / disk / perangkat yang dikenal, mematikan CLI tidak sulit, dan tentu saja dapat dituliskan skrip. Namun kesalahan bisa menyakitkan.

Di mana hal itu mungkin tidak diketahui, atau mungkin melakukan operasi tidak dilakukan secara cukup teratur untuk tetap solid dan bebas dari kesalahan, menjalankan GUI menyediakan lingkungan yang dapat dengan mudah diverifikasi, operasi dirantai bersama dan kemudian dijalankan dengan percaya diri, tanpa skrip yang diperlukan.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.