CLI uygulamalarının geliştirilmesi “geri” olarak mı kabul edilir? [kapalı]

Programcılıkta çok tecrübeli DBA'yım.

Bazı günlük tekrarlayan görevleri çözen veya günlük işleri yapmasa da, insan hatasını daha karmaşık bir şekilde ortadan kaldıran birkaç CLI, etkileşimli olmayan uygulamalar geliştirdim. Bu araçlar şimdi alet kutumuzun bir parçası.

CLI uygulamalarının harika olduğunu düşünüyorum çünkü bunları otomatik bir iş akışına dahil edebilirsiniz.

Ayrıca, Unix'in tek bir şeyi yapma felsefesi, ancak bunu iyi yapmak ve bir sürecin çıktısının bir başkasının girdisi olmasına izin vermek, bir stratejik avantaj olarak birleştirecek bir araç seti oluşturmak için harika bir yoldur.

Patronum kısa süre önce CLI araçlarını geliştirmenin "geri" olduğunu ya da bir "gerileme" oluşturduğunu belirtti.

Ona karşı çıktığımı söyledim, çünkü şu anda var olan CLI araçlarının çoğu eski değil, sürekli geliştirilmiş sürümleri olan canlı projeler.

Bu tür bir gelişme piyasada "geriye" olarak mı değerlendiriliyor?

Bir rèsumè üzerinde kötü görünüyor mu?

Ayrıca ister web ister masaüstü olsun tüm çözümleri, etkileşimli olmayan komut satırına sahip olmalıdır. Bazı insanlar bunun bir programlama kaynağı kaybı olduğunu düşünür.

Bu amaç bir yazılım projesinde değerli mi?

Ayrıca, bir web veya masaüstü uygulaması için, alternatif bir CLI arayüzüne sahip olmanın, işletme mantığının GUI'den tamamen ayrıldığını göstermenin harika bir yolu olduğunu düşünüyorum.

Bir CLI ile çalışabilme yeteneğine sahip olmak geriye doğru düşüneceğim bir şey değil. Özgeçmişinde harika görünüyor, özellikle özgeçmişinizde "Veritabanı kapalıyken SMS mesajı göndermek için bir dizi otomasyon aracı oluşturmak için" kullanılmış (Powershell / Bash) gibi bir cümle ile döndürebiliyorsanız harika görünüyor.

İnsanları işe almaktan sorumlu olduğumda, CLI'nin çalışma bilgisi aradığım bir şeydir.

Temelde "iş için doğru aracı kullanmak" için aşağı gelir.

Bir kullanıcıyla etkileşime geçmeniz gerekiyorsa, bir çeşit GUI isteyeceksiniz. Bilgisayarları çok daha sezgisel ve üretken yaptıklarını gösteren onlarca yıllık araştırma ve deneyime sahibiz. Bu yüzden GUI'lar 1984'ten beri dünyaya kaçınılmaz bir biçimde katılıyor: insanlarla etkileşimde bulunmak için daha iyi çalışıyorlar.

Ancak, bir komut dosyasını komut dosyasıyla otomatikleştiriyorsanız, programınız insanlarla etkileşime girmez; bir senaryo ile etkileşime giriyor. Ve bunun için en iyi arayüz, sezgisel olarak bariz olması gereken nedenlerden dolayı, metin tabanlı bir arayüzdür.

Kullanıcıların doğrudan birlikte çalışabilmeleri için CLI programlarının geliştirilmesi geriye dönük olarak ve iyi bir sebeple değerlendirilir. Ancak yaptığınız şey bu değilse, otomasyon üretkenliği araçları yazıyorsanız, onlara bir CLI vererek yanlış bir şey yapmazsınız.

Eric Raymond'ın Unix Programlama Sanatı, yaptığınız tartışma için kanonik bir çalışmadır. Mükemmel kitabını birkaç paragrafa sıkıştırmaya çalışmıyorum. Ancak, argümanın çoğunlukla programcılar, yöneticilerin komut dosyası kullanarak görevleri otomatik hale getirmeleri veya CAD gibi yüksek teknik yazılım kullanıcıları için geçerli olduğunu unutmayın.

Yüksek düzeyde teknik kullanıcılarla bile, o sırada hangi şapkaları taktıklarını düşünmeniz gerekir. Mesela ben geçim kaynağı olan ağ donanımları için gömülü yazılımlar yazıyorum. Tüm ürünlerimiz hem bir CLI hem de bir GUI'ye sahiptir, ancak geliştiriciler esnekliği, komut dosyası yazılabilirliği, kullanılabilirliği, hızı vb. Nedeniyle neredeyse evrensel olarak CLI'yi tercih eder.

Bununla birlikte, aynı geliştirici grubu, CLI daha güçlü olmasına ve GUI'nin yanı sıra desteklenip belgelenmesine rağmen sürüm kontrol yazılımımızdaki GUI'yi büyük ölçüde tercih ediyor. Aradaki fark, yöneticiler veya geliştiriciler değil, sürüm kontrol yazılımının son kullanıcıları olduğumuzdur.

Bu nedenle, kullanıcılarınızın yardımcı programlarınızı kullanırken rollerinin neler olduğunu dikkatlice düşünün ve kullanıcı arayüzünü buna göre planlayın. Patronunuz bundan söz ediyorsa, CLI ile ilgili belgeleri ve / veya eğitimi en azından geliştirmeniz gerekir. İnsanlara sürekli olarak bir özelliği yalnızca GUI'de beklediklerinde CLI'de kullanabileceğini söylüyorsanız, kullanıcılarınızın ihtiyaçlarını göz önünde bulundurarak, geliştirme önceliklerini yeniden düşünmeniz gerekir.

Komut satırı programları tarafından yönlendirilen sadece Unix değil. Microsoft da bu yöne gidiyor.

Microsoft bir süredir PowerShell'i zorluyor. Mevcut sunucu yazılımlarının tümü (Exchange, SharePoint, Server 2012, System Center, vb.) PowerShell komut satırı üzerinden tamamen kontrol edilebilir. PowerShell, bir şeyi iyi yapan kük işlevlere ve verileri bir sonrakine yönlendirir (yalnızca metin yerine nesneleri yönlendirmesine rağmen).

Bu programlara ilişkin GUI'lerin çoğu sadece PowerShell komutlarının bir öncüsüdür, hatta birçokları komut yazmayı kolaylaştırmak için hangi komutların çalıştırılacağını söyler. GUI'den yapabileceğiniz her şeyi PowerShell'den yapabilirsiniz. Tersi doğru değil - sadece PowerShell'de açığa çıkan birkaç fonksiyon var.

Öyleyse * nix her zaman yapmışsa ve Microsoft bu yöne doğru gidiyorsa ... bana pek de ters görünmüyor!

Bunun kötü bir şey olduğunu kesinlikle söylemem. CLI programları hakkında güzel bir şey, onları uygularken çok sınırlı bir kapsam olabilir. Örneğin, bir catklonu veya "bir dosyanın içeriğini ekrana yazdırmak için bir program" yazmak istersem , bu CLI ile çok mümkün.

Ancak, ya CLI kullanmasaydınız, o zaman bir metin görüntüleyen bir GUI ile temel bir program olurdu. Ama sonra bir dosya iletişim kutusu açarak onu bağlamaya da bağlaman gerekiyordu .. ama sonra birileri de metni değiştirip başka bir yerde saklamak istiyor.

Kapsam sürünmesi GUI uygulamaları ile saçma. CLI uygulamaları ile olsa da önlemek için son derece kolaydır. “Dosyayı düzenlemek ve yeniden kaydetmek ister misiniz? cat foo > ed > bar” CLI uygulamaları ile kullanıcılarınız (geliştirici değil) diğer araçlarla birleştirmeniz önemsizdir .

Şimdi, söylendiği gibi, CLI programları "geriye" olarak görülmeye başlandı. Bunun nedeni, bu günlerde pek çok uygulama geliştirmenin, aracınızı diğer araçlarla birleştiren kullanıcıların imkansız olduğu pazarlarda gerçekleşmesidir. Buraya girmeyeceğim, ancak iyi tasarlanmış bir CLI uygulamasının tam tersi olan “pazarların hiçbiri ustalık zihniyetini nasıl yürüttüğü” hakkında bir blog yazısı yazdım (bir şeyi yapmak ve iyi yapmak için) )

GUI ve CLI'nın ikisinin de yeri vardır. GUI, kullanıcının belirli hazır işlemleri hızlı bir şekilde gerçekleştirmesine izin vermek için mükemmeldir. CLI, GUI'nin yapmanıza izin vermediği şeyleri yapmak istediğinizde içindir. CLI genellikle daha güçlü ve kullanımı daha zordur.

Bir iyi CLI aracı kullanıcı aracını yazan kişinin hiç düşünmemiştim şeyler yapmanızı sağlar. Bunun bir örneği UNIX 'find' komutu. Bu komut:

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

'xyzzy' ile başlayan bir adı olan ve 3 günden daha önce değiştirilmiş bir ismi olan, geçerli dizinin altındaki (ancak 5 seviye aşağı) dosyaları bulur ve sonra siler (not: denenmemiş kod). Ve bu oldukça basit bir kullanım. Böyle bir şey yapmak için bir dosya yöneticisi kullanabilirsiniz, ancak bu daha uzun sürecektir ve hataya açıktır. Elbette, daha güçlü olmak CLI'nin daha kolay kötüye kullanılabileceği ve kendiniz için sorun yaratabileceği anlamına gelir!

İyi bir geliştirici, sınırlı sayıda işlem yapılmasına izin veren bir GUI'ye sahip olacak şekilde bir CLI aracı yazabilir. Kullanıcı GUI ile başlayabilir ve daha sonra CLI'nin karmaşıklığını öğrenebilir.

CLI / GUI tradeoff'unda okunan iyi (uzun ve önyargılı (?)):

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

Hayır, geriye doğru değil.

"Yön", bakış açımızla ilgili çok şey var. Şu anki yoldan mutlu olan bir kullanıcı, basit, "tek bir cihazı deneyimleyin" arayüzleri, CLI'yi kesin olarak bir gerileme veya gerileme olarak görecek. Genel beklentileri ile uyumlu değil.

Bir programcı, yönetici veya uzman kullanıcı, araçların deneyimlerine göre mantıklı ilerlemesi olarak görebilir. Bunların çoğu GUI araçlarını kullanmaya başlar. Ölçeklemek istediklerinde veya ölçeklendirilmeleri gerektiğinde, CLI'nin neden var olduğunu ve bu ilerlemenin daha fazla CLI aracı inşa edenlerle yanıldığını hızla anlarlar.

Paul Ferris tarafından bu var: http://www.linuxplanet.com/linuxplanet/opinions/1505/1

Şahsen benim için sözdizimi fikri ikisini farklılaştırıyor. Bir GUI'de sözdizimi bir şekilde mevcut olduğunda, sonuç hiçbir zaman iyi değildir ve iyi düşünülmüş CLI sözdizimi kadar esnektir. Bu borular ve yönlendirme ile birleştiğinde, GUI planlanan kullanım durumlarının dışında çok faydalı olmadığından düz düşer.

Bu konudaki kişisel tercihim, bir GUI sarmalayıcısının, durum çubukları ve insanların GUI'yi aradığı diğer temel öğeler de dahil olmak üzere sağlam bir şekilde etkileşime girmesini sağlamak için yeterli bir --gui veya --verbose seçeneği sunan CLI araçları.

Elbette, bunun maliyeti, esasen bir tanesi diğeri olmadan oldukça yararsız olan iki programdır, ancak en büyük yararı, bir veya daha fazla büyük CLI aracını, söz konusu CLI araçlarında değişiklik yapmadan, özel bir GUI'ye dahil edebilmektir. Çoğu zaman bu, yalnızca belirli bir CLI üzerinde bir GUI seçeneği sunmak için yapılır, ancak tek bir "işlem" veya "kullanım durumu" yönelimli GUI'ye sahip birden çok aracı kullanma fikri, bu kullanım durumu için boru tesisatı ve yönlendirmeye ve komutlamaya benzer sonuçlar verebilir, CLI kullanıcılarını hala engellememekle birlikte ustalık seviyesine ulaşmak için bu işlemleri düzenli olarak yapamayacak insanlara ulaştırmak.

SGI IRIX'de bu yaklaşıma rastladım ve çok beğendim. Kendimi GUI'yi veya komut satırını gerektiği gibi kullanırken buldum ve güzel olan şey, süslü düğmelerin tam olarak ne yaptığını tam olarak biliyordu.

Birçok farklı çalışma ortamının olduğu yerlerde, GUI sarmalayıcıları, CLI aracını da etkilemeden önemli ölçüde farklılık gösterebilir.

Bunu bugün Linux'ta GUI'nin CLI'nin tanıdık kullanıcılarına bile çok değer katabileceği disk / dosya sistemi araçları gibi şeylerle görüyorum.

Bilinen dosya sistemleri / diskler / cihazlar söz konusu olduğunda, CLI'yi devirmek zor değildir ve elbette yazılabilir. Ancak hatalar acı verici olabilir.

Bunların bilinmediği veya belki de işlemlerin gerçekleştirilmesi, sağlam ve hatasız kalacak kadar düzenli olarak yapılmaması durumunda, GUI'nin çalıştırılması, kolayca doğrulanabilen bir ortam sağlar, birlikte zincirlenir ve daha sonra güvenle çalışır, komut dosyaları gerekmez.