CLI yönelimli bir programlayıcının iş akışı GUI yönelimli olandan nasıl farklıdır?

GUI uygulamalarında daha az programlama çalışması yapmanın ve daha fazla komut satırı aracı kullanmanın (özellikle işlerin daha verimli bir şekilde yapılmasına ilişkin) avantajları hakkında çok şey duydum. Ancak, komut satırı araçlarına daha fazla bağımlı olsaydım iş akışımın nasıl farklı olacağını anlamadığım için, yeni bir araç seti öğrenmek ve değiştirmek için zaman ve çaba harcamak için kişisel olarak yeterli bir kazanç olup olmadığını kolayca değerlendiremiyorum. iş akışım.

Şimdi:

• Visual Studio, Eclipse vb. Kullanarak C / C ++ / D / C # / Java / Python gibi dillerde bazı yan projeleri kodluyorum ve derleme ayarlarını yapıp oluşturmak / çalıştırmak için F5 tuşuna basarak çalıştırıyorum.

• İş yerinde bir web programı geliştiriyorum, bu yüzden bir sunucu kurmak, bir veritabanına bağlanmak vb. İçin Django'yu kullanmak ... neredeyse tüm SciTE metin editörü içinde.

• Normal programları başlatmak için Launchy kullanıyorum ... hala terminal yok. :)

• Dosyaları ve neyi kopyalamak için, grafik dosya yöneticisinde (Windows Gezgini, Nautilus) normal bir bul / taşı kullan.

• Hata ayıklama: Windows için Visual Studio veya Hata Ayıklama araçlarını kullanıyorum (Windows'tayım). Linux'ta çok fazla hata ayıklama yapmadım, ancak yaptığım şeyler için Eclipse'i kullandım (Windows'ta Java için de).

• İş yerinde: Yapı sistemine bağlanmak ve bir proje kurmak için, sadece kullanımım için Eclipse'e entegre edilmiş araçları kullanıyorum - bir terminale veya başka bir şeye gerek yok (her ne kadar kesinlikle bir terminal kullanmam hoşuma gidiyorsa) gerçekten istiyorum)

Bu şeyleri CLI'de yapmak nasıl bir şey? Hangi parçalar daha fazla / daha az verimli hale geliyor? Çoğunlukla CLI'da çalışmaya geçişten en büyük avantajı elde etmek için iş akışımın hangi yönlerinin değiştirilmesi gerekir? Başka bir deyişle ... Beni sihirli bir şekilde komut satırı gurusuna dönüştürdüyseniz, yeni kodlama iş akışım şu anki GUI merkezli, bir şeyler yapma tarzımdan nasıl farklı olurdu?

Bunun artık doğru olduğunu düşünmüyorum. CLI'nin belirli bir avantajı vardır - aradığınızı önceden biliyorsanız, o zaman bir menüde gezebileceğinizden daha hızlı yazabilirsiniz. Bu, çok az içeriğe sahip programa açıkça komut vermek istiyorsanız, çoğunlukla daha hızlı olduğu anlamına gelir. Ancak, iki sorun vardır.

İlk olarak, GUI programları sizin için bağlam çıkarabilir. Örneğin, Visual Studio'nun Tanıma Git özelliği ve Intellisense. Bu özellikleri bir CLI'da nasıl çoğaltabilirsiniz?

İkinci olarak, GUI programları size çok daha fazlasını gösterebilir. Örneğin, zaman içinde birden çok çekirdekte CPU kullanımının bir grafiği olan Visual Studio Paralel Profiler. Bunu bir CLI'da nasıl görüntüleyebilirsiniz? Bu hiç mantıklı değil. Verileriniz metin dışında bir şey olarak daha iyi ifade edilir edilmez, CLI anında kaybolur. Başka bir kolay örnek kesme noktalarıdır. Visual Studio'da, kırılmasını istediğiniz satırın kenar boşluğunu tıklatın. Bir CLI'de ne yapacaksınız, dosyayı ve satır numarasını bulmaya çalışın ve bu komutu girin? Bu size göreli bir on yıl sürecek. Bu, Debugger Canvas gibi daha yeni GUI yeniliklerini saymaz.

Eğer zaman ayırmak için Debug'ı tekrar tekrar itmek istiyorsanız, bir GUI daha yavaş olabilir, ancak kullanım durumları daha karmaşık hale gelir gelmez, CLI'nin devam etmesinin bir yolu yoktur.

Bence en büyük fark bireysel görevlerde değil iki şeyde yatmaktadır:

Her şeyden önce otomasyon. CLI doğası gereği yazılabilir, bu da Windows'da genellikle daha zordur. PowerShell ile bazı şeylerin düzeldiğini duydum ama ben kullanmadım.

İkincisi, UNIX "endişelerin ayrılması" felsefesi. Bir şeye küçük bir readline tabanlı arayüz yazabilir ve emacs Mx kabuğu kullanarak emacs GUI içinde kullanabilirsiniz. Bu, diğer araçlardan ve mevcut işlevlerden yararlanmayı kolaylaştırır.

Hata ayıklama için gdb iyi çalışıyor ama genellikle VS hata ayıklayıcıyı tercih ederim. Muhtemelen Microsoft'un yaptığı en iyi yazılımdır.

Bir şeyler inşa etmek ve çalıştırmak için: yapmak. Veya bash. Nerede olursa.

Geliştirme için: emacs (yakın zamanda vi'dan dönüştürün, oh utanç!). Vi ssh ile iş yapıyorsa.

Tutulmaya gerçekten alışamıyorum. Bence bu bir "zihin şekli" sorunu: benimkine uymuyor.

Benim için, Visual Studio'dan CLI iş akışına geçmek çok sayıda * nix komutunu ezberlemeyi içeriyordu. Bir SVN check-up'ını berbat ettiğimde bazı baş ağrıları da vardı.

Ancak iş akışındaki en büyük fark, bir işletim sisteminin nasıl çalıştığını daha iyi anlayabilmemdi . Bir GUI iş akışıyla, yalnızca düğmelere tıklayıp programın yanıt vermesini bekliyordu. Komut satırı dünyasında, bilgisayara doğrudan bir şey yapmasını söylüyorum.

Başka bir deyişle, bir GUI iş akışı size geri iletişim kuran bilgisayarken, CLI iş akışı daha çok doğrudan bilgisayarla iletişim kuruyormuşsunuz gibi görünüyordu.

Biri diğerinden daha iyi değil, ama tamamen GUI tabanlı bir ortamdan terminale geçiş yapmak kesinlikle bir yolculuktu.

Her iki dünyada da yaşayan bir programcıdan daha fazla gözlem. Diğer cevaplarda zaten verilen puanları tekrarlamayacağım:

CLI tabanlı geliştirme, her biri 1 işlev gerçekleştiren çeşitli programlar kullanma eğilimindedir. GUI tabanlı geliştirme, düzinelerce farklı işlevi yerine getiren 1 büyük programı (IDE) kullanma eğilimindedir. Bu tek farkın birkaç sonucu vardır:

Bir IDE her zaman çalıştığınız bir "ev" olarak tasarlandığından, verilerinizi tutmak için özel (belki de ikili) bir format kullanabilirler. Uyumluluk büyük bir endişe kaynağı değildir, çünkü aynı projede 2 farklı IDE'de çalışmanızı beklemezler. Öte yandan, CLI araçları genellikle düz metin dosyalarıyla çalışır.

CLI tabanlı geliştirme ile, araçları aşamalı olarak değiştirebilir veya yeni araçları iş akışınıza daha kolay bir şekilde entegre edebilirsiniz. Bir IDE seçmek daha çok ya da hiçtir ve IDE'nizi değiştirmek daha acı vericidir.

IDE'nin yerleşik "Oluştur" menüsü yerine bir CLI derleme komut dosyası kullanmak, kodunuzdan birkaç yıl uzaklaşıp geri dönüp sorunsuz bir şekilde oluşturabilmenizi sağlar. GUI tabanlı geliştirme ile, o zamana kadar tamamen farklı bir IDE çalıştırıyorsunuzdur. Belki de kodu yazarken kullandığınız kod geçerli işletim sisteminizde bile çalışmaz.

Bir IDE'de kendi araçlarınızı oluşturmak, (muhtemelen büyük) bir eklenti API'sı öğrenmek ve belki de belirli bir dil kullanmak anlamına gelir. CLI kullanırken, özel araçlar yapmak için özel bir şey gerekmez.

Öte yandan, bir IDE'nin avantajı "entegre" olmasıdır. Böylece hata ayıklayıcı kesme noktalarını ayarlamak için editör pencerenizi tıklatabilirsiniz.

Başka bir nokta: seçiminiz, kullandığınız geliştirme platformuna, işletim sistemine ve dillere de bağlı olacaktır. Bazı platformlarda, IDE tabanlı geliştirme, hakim geliştirme kültüründe derinlemesine yerleşmiştir. Diğerlerinde, CLI tabanlı gelişim yaygındır. IDE tabanlı geliştirmenin yaygın olduğu bir platform kullanıyorsanız, CLI araçlarının zayıf bir şekilde geliştirilmiş ve zayıf bir şekilde desteklenmesi muhtemeldir. Bunun tersi de doğrudur.

Hatta çiftlikte internet bile vardı çocukluğumun çoğu bir bilgisayarda harcanmadı. Liseye geç başladım ve her zaman GUI'lerde çalıştım. Üniversitede CLI'de büyüyen ve her şeyi bu şekilde yapan bir adamla tanıştım. Bu yüzden prof dinlemek yerine bir linux sunucusu kurmaya karar verdim. Birkaç yıl sonra arkadaşım gömülü kod yazmamı izliyordu ve nasıl yazdığımı düşünemiyordu.

Temelde yarım CLI yarım GUI kullanıyorum. GUI ile birlikte verilen ortamların çok daha hızlı ve daha verimli yaptığı bazı şeyler vardır. Aynı şey CLI için de geçerlidir. Metin düzenlememin çoğu VIM'de yapıldı çünkü gelişmiş CLI editörleri VIM / EMACS (burada savaş yok) metin manipülasyonunu en verimli hale getiriyor. Öte yandan GDB kullanarak Gömülü hata ayıklama gibi şeyler, klavyesiz metin düzenlemek kadar acı vericidir. Emin olun güçlü ve emin aradığınız bilgiyi bulacaksınız ama herhangi bir bellek bloğuna anında erişimli güzel bir GUI penceresine sahip olmak, özellikle başka bir bellek bloğuyla karşılaştırmaya çalışırken çok değerlidir.

Zaten söylemeye çalıştığım şey GUI vs CLI değil, daha ziyade CLI daha iyi ve GUI daha iyi ne olmasıdır. Çünkü sonunda ES'niz düşünce sürecinizden daha yavaşsa bir sorun vardır.

"bir gecede CLI gurusuna dönüştürüldü mü?" Evet, sürtünme var. İyi tasarlanmış GUI'ler CLI'lerden daha keşfedilebilir ve yeni başlayanlara daha affedici olma eğilimindedir.

Son zamanlarda bir döşeme penceresi yöneticisi (dwm) tarafından geliştirilen iş akışım, çok fazla yazımdan oluşuyor. Dizüstü bilgisayarım artık bir fare takmadan kullanılabilir. (İzleme dörtgeni, geriye kalanlar için yeterlidir). Alt-sekme ile birçok uygulamayı açık tutuyorum. Pencereleri taşımak ve yeniden boyutlandırmak için zaman harcamıyorum.

Çoğu zaman bir tarayıcı, vim ve bir grup terminal kullanıyorum. SSH, nerede çalıştığım konusunda (fiziksel olarak) çok fazla esneklik sağlıyor. Uzak masaüstleri, ağda 10Gigabit borusu olduğunda daha iyi bir deneyim sunabilir, ancak nefesimi tutmayacağım.

Vim'i karmaşık özelliklerinden yararlanacak kadar iyi öğrenemedim, ama bu yönde eğiliyordum - başarısız bir markadan sonra vim doğru satıra atlamak istiyorum. (Teknik olarak vim, bir terminalde çalışmasına rağmen bir Görsel Arayüzdür, ancak fare ile değil klavyeyle sürüyorum.)

Asıl sorun, kötü tasarlanmış arayüzler. İyi tasarlanmış arayüzler oluşturmak zordur, bu nedenle her iki kampta da çok sık gerçekleşmezler. Ama bugün ux-olmayan sihirbazlar CLI'lerden daha fazla GUI tasarlıyorlar.

(Diğer büyük evcil hayvanım şişkinlik. 200 KB'lık bir programla aynı görevi yerine getirmeme yardımcı olmak için 19 MB'lık bir program gerektiğinde, bir şeyler yanlış. DOS için XTree Gold, üretkenliğimi herhangi bir modern dosya yöneticisinden daha fazla geliştirdi. Turbo C harika bir IDE idi. Nook'um neden bir Mac klasiğinden daha yavaş çalışıyor gibi görünüyor?

Grafik kullanıcı arayüzlerinde, aynı işlemi tekrar tekrar gerçekleştirmek için programla tekrar tekrar etkileşime girmeye zorlanırsınız. Bir kabukla, işleri daha kolay bir şekilde otomatikleştirebilir ve programların borulama yoluyla birlikte çalışmasını sağlayabilirsiniz; Söylendiği gibi, birçok işlem için daha hızlıdır.

SSH kullanmıyorsanız, terminalde programlama belki bir grafik düzenleyiciden çok daha iyi değildir.

Şahsen unix kabuğunu tipik Windows komut satırından çok daha ulaşılabilir buldum ve şimdi bir döşeme penceresi yöneticisi ve birçok terminali olan bir Linux sistemine daldım.

Tüm örnekleriniz hemen hemen tek adımlık bir süreçtir. Çoğu GUI ortamında, bulunduğunuz uygulama ile ilgisi olmayan bir dosyayı taşımak istiyorsanız, dosya menüsünden uygulamadan çıkmadan bunu yapabilirsiniz. Komut istemine gitmenin bir anlamı yok. Dosyayı kopyalayıp farklı bir ad vermek istiyorsanız, bir komut satırında bunu bir kerede yapabilirsiniz. Bunu bir toplu iş dosyasına koymak için, en azından bunu nasıl yapacağınızı bilmeniz gerekir, ancak isterseniz toplu iş dosyasını GUI'den yürütebilirsiniz.

Fare ile klavye komutları üzerinde benzer bir tartışma yaşadım.

Çalışma şeklim GUI'yi açık arayla tercih ediyor.

Tipik kullanım:

• Üç farklı platform için üç IDE. Ayrıca bazı komut dosyaları için bir Notepad ++ penceresi. Tüm bu yapı sistemleri için komutları hatırlamamın hiçbir yolu yok. CLI ile ilgili sorun sadece bir yapı çalışma almak için birçok ayrıntı bilmek gerekir. Modern IDES normalde orada varsayılan olarak bazı uygun seçeneklere sahiptir. Zamanı geldiğinde her zaman daha yakından bakabilirsiniz.
• SVN veya Git entegredir. Programlamaya yardımcı olan bir program için çok fazla seçenek var ve çoğu zaman sadece taahhüt veya güncelleme yapıyorum.
• Ağ şeyler: Şanslıyım, ofisimizde de tüm ağ kurulumunu yapıyorum. Ağ panellerinin çoğu size bir sürü CLI komutu verecektir, ancak duruma genel bakış gereken bir şey varsa, güvenlik duvarı ve yönlendirme. Yönlendirme için komut satırı ile yaşayabilirim, ancak güvenlik duvarları karmaşıklaşıyor ve eğer GUI'lerin iyi olduğu bir şey varsa, çok fazla bilgi görüntülüyor.
• Genellikle bir şeyden diğerine çok fazla hareket vardır. Görsel bağlamda bağlam anahtarları daha kolaydır.

CLI'nin ana yararı için, senaryo yazarken, bunu neredeyse hiç yapmam. Elimizdeki tekrarlanan görevler sadece c # ile birlikte attığımız ve sık sık değişmeyen cron iş uygulamalarıdır. Linux'ta işleri çalıştırmak için yöntemlerimiz var, ancak esas olarak taşındı (artırıldı), bu nedenle dosyalarla uğraşmak ve bu tür şeyler en aza indiriliyor. Ve işler kıllı olursa, Linux için de iyi IDE'ler var.