Kodsuz geliştirme sözde bir talep midir?
Yazar | Alex Hudson
Çevirmen | Yeldeğirmeni ve Bulut Atı, Sorumlu Editör | Tang Xiaoyin
Mühürlü resim | Doğu IC'den ödendi
Son yıllarda bir söz giderek daha popüler hale geldi, "2020 kodsuz bir yıl olacak". Bu, bir yazılım geliştiricisi olmasanız bile, iş mantığını veya hatta tüm uygulamaları yazabileceğiniz anlamına gelir. Bunun belirli faydaları vardır. Bazı "kodsuz" araçlar gerçekten çok güçlüdür, ancak bunun olası olmadığını da düşünüyorum.
Neden "Kod Yok" var?
Görünüşte "kod yok" olmanın nedeni açıktır: yazılım geliştiriciler pahalıdır ve yetersiz tedarik edilir ve yazılımın kendisinin geliştirilmesi döngüleri gerektirir ve sonraki aşamalarda talepteki değişikliklere göre ayarlamalar gerekir ve işletme ve bakım maliyetleri çok yüksektir. yüksek.
Ancak yazılıma olan talep gün geçtikçe artmaktadır. Modern dijital işletmeler, çoğu son derece özelleştirilmiş olan çok sayıda yazılıma ihtiyaç duyar.
Dijital bir iş ya da hatta dijital bir ürün yaratabilsek daha iyi olmaz mıydı? Yeni teknolojinin ilk başta kullanımı zor olabilir, ancak zamanla daha erişilebilir hale gelecektir.
İş süreçlerini yazılım alanına dönüştürmenin iki bariz faydası vardır:
-
"Değişim kontrolü" bir personel sorunu değil, bir yazılım sorunu haline geldi. Çok sayıda personelin yeniden eğitilmesine gerek kalmadan sadece bir yazılım yayınlayarak mevcut süreci değiştirebilir veya yeni bir süreç tanıtabilirsiniz. Daha hızlı geri alma veya yineleme elde etmek için.
-
İnovasyon, özellikle rakipleri de aynı ürünleri üretirken ve iş süreçlerini yazılım alanına dönüştürürken şirketleri farklı kılar.Bu, bazı şirketler için iyi bir şey, ancak çoğu şirket yazılım ürün hizmetleriyle uğraşmak istemiyor.
Pek çok şirket bu faydaları dijital dönüşüm yoluyla elde etmeye çalıştı ancak başarısız oldu. Birdenbire, şirketin (en azından bir dereceye kadar) bir yazılım geliştirme şirketi olacağını göreceksiniz ve çoğu şirket bu konuda iyi değil! Yazılım ortamının sınırsız olanakları olmasına rağmen, yeterli kaynaklara (zaman, para, Personel), çoğu insan çeşitli olasılıkları hayal eder, ancak pratikte birçok kısıtlamaya tabidirler.
"Kod yok" nedir?
"Kod yok", yazılım geliştirmenin kod yazmayı gerektirmediği anlamına gelir. İnsanlar "daha yüksek bir seviyede" çalışabilir, bu seviyede gelişme çok daha basittir, ancak sonuç aynıdır.
Özellikle, bir bilgisayar programlama dilinin gramer biçiminde iş mantığı yazmak can sıkıcıdır. Bir benzetme yapmak gerekirse: Yazılım geliştiriciler, motorun içini bilen araba tamircileri gibidir. Ancak çoğu insanın sadece araba kullanabilmesi, direksiyon simidini ve bazı pedalları kullanması gerekiyor. Zamanla, mekanizasyon derecesini sürekli olarak geliştirdik. Bazı insanlar manuel şanzımanı sevebilir, ancak çoğu insan otomatik şanzımanı tercih eder, bu yüzden sürüşü kolaylaştırabiliriz!
Basit soyutlama
Sektörün ilk günlerinde programlamayı basitleştirme girişimleri çoktan başladı: BASIC, insanların İngilizce'ye benzeyen bir dilde yazılım yazmalarına izin verme girişimidir ve bu da çok başarılıdır.
Bununla birlikte, bir kodlama sisteminin temel bir kavramı olarak soyutlama, çok basitleştirilmeme eğilimindedir: aslında, birçok geliştirici, kodun anlaşılmasını kolaylaştırmak için yeterince spesifik olmasını aktif olarak sağlamaya çalışıyor.
Basit sözdizimi
Asıl sorun metin yazmaktır.Dilbilgisini basitleştirmek veya hatta tamamen kaldırmak için girişimlerde bulunulmuştur - birçok grafik geliştirme sistemi vardır.
Bu gramerlerin sadeleştirilmesi aynı zamanda ifade problemlerini de beraberinde getirecektir. Hızlı bir şekilde ustalaşmak için yeterince basit olduklarında, artık birçok senaryoda kullanılacak yeterli ifade gücüne sahip değillerdir. Etki alanına özgü diller (dsl) adı verilen belirli bir uygulama etki alanına odaklanan bilgisayar dilleri de vardır. Ancak bu dillerden birkaçı, gelişmede gerçekten başarılıdır, çünkü esas olarak işleri yine aşırı derecede karmaşık hale getirirler.
Yapılandırma kodu
Kod yazamayan birçok kişi, mevcut uygulamaları entegre ederek önemli sistemler inşa ediyor. Bu, farklı sistemlere geniş çapta entegre edilebilen Zapier gibi araçlar kullanılarak daha doğrudan yapılabilir.
Bu durumun iki sebebi var. İlk olarak, mantığı çeşitli farklı sistemlere genişlettiniz, bu nedenle tüm uygulamayı sıralamak zordur.
İkinci olarak, mantık kodla değil yapılandırma yoluyla uygulanır. Programcılar genellikle şu ikilemle karşı karşıyadır: harici sistemlere güveniyor muyuz ve çok fazla yapılandırma işi mi yapıyoruz yoksa kendimiz için daha fazla mantık mı kullanıyoruz?
Uygulama nasıl genişlerse genişlesin, mantık kaybolmayacaktır. Bağlanmak için Zapier kuralları kullanılsa bile, herhangi bir bakım maliyetini veya yükünü ortadan kaldırmayacaktır.
Kod denkliği
Geliştiriciler, esas olarak verimliliği ve net ifadeyi iyileştirmek için hala düz metin kullanıyor. Elbette, daha kısa araçlar ortaya çıkarsa, geliştiricilerin çoğu (hepsi değil!) Sıcak taşlar gibi metinleri atacaktır.
Ancak mantıksal ifade şekli ne olursa olsun, açıklanan şeylerin karmaşıklığını azaltmayacaktır. Örneğin, "iki" ve "2" yazmak aynı anlama gelir.
Varsayımsal görsel geliştirme ortamındaki süreç şu şekildedir:
Tam olarak eşdeğerdir:
def process_email (öz, adres): self.validate_email (adres) değilse: InvalidDataException (_ ("Adres geçerli değil")) self.store (adres)İlk örnekte, görsel çevre sisteminin nasıl çalıştığını bilmem gerekiyor. İkinci örnekte, bir dil ve gelişim ortamını anlamam gerekiyor. Ancak bu iki becerinin edinilmesi kolaydır. Aralarındaki ortak nokta, mantığın ne olduğunu ve nasıl çalışacağını anlamak istememdir.
Yazılımı - her tür yazılımı - anlamak için, temsil edilen sistemi kafanızda modelleyebilmeniz ve buna bağlı olarak farklı senaryolarda nasıl çalışacağını tahmin edebilmeniz gerekir.
Bu nedenle birçok insan modern dijital cihazlarla sorun yaşıyor. Sorun, donanımın birkaç giriş düğmesine sahip olmasıdır, ancak dahili çalışma çok karmaşıktır: bu nedenle kullanıcıların, cihazın dahili durumunun üst düzey bir modelini akıllarında tutmaları gerekir.
Bazı insanlar bunun öğrenilemez bir beceri olduğunu düşünüyor. Bir şeyin iç durumunu çıkaramazsanız, muhtemelen onu programlayamazsınız. Çok fazla pratik yapmadan iyi yapmamalısın diyebilirim. Açıkçası, mantığın metinsel mi yoksa görsel mi olduğu önemli değil.
"Kod yok" kötü mü?
Kesinlikle hayır.
70 yılı aşkın süredir programlanabilir bilgisayar geliştirme geçmişinde, 20 yıl önce hala geliştirme araçlarını kullanıyoruz, bu en büyük talihsizlik.
Tabii ki, dilimizi ve çevremizi iyileştirmek için hala çabalamalıyız. Aşağıdaki iki kod parçasına bakın:
#Dahil etmek < string.h > #Dahil etmek < stdlib.h > char * add_domain_name (char * kaynak) { const size_t size = 1024; char * dest = malloc (boyut + 1); strncpy (hedef, kaynak, boyut); strncat (dest, "@example .com ", boyut); dest dönüş; }Ve bu:
function add_domain_name (kullanıcıadı: dize): string { kullanıcı adı + "@example döndür .com "; }İlk örnek C (1972 civarında icat edildi) ve ikinci örnek TypeScript 40 yıl sonra (2012'de piyasaya sürüldü). Pek çok yerde kabaca aynı sözdizimine sahipler, ancak TypeScript C'den çok daha gelişmiş. Özellikle, geliştiricilerin bellek ayırma, dizgi kodlaması veya diğer şeyler hakkında endişelenmesine gerek yoktur.
Aslında, yeterince büyük bir uygulama için, iş mantığının çoğu oldukça yüksek bir seviyede uygulanacak ve diller arasındaki farklar daha az belirgin olacaktır.
Pratikte, "kod yok" un dezavantajları nelerdir?
Bazı çok gelişmiş sistemler var mesela Salesforce Cloud'da çok karmaşık yazılımları herhangi bir kod yazmadan tanımlayabilirsiniz. Görsel programlama, kural belirleme ve yapılandırmayı içerir.
Diğer insanların platformları için, gerekli işlevler aslında hiç gerçekleştirilemez. İşlevsellik eksikliğini telafi etmek için genellikle karmaşık çözümler oluşturmanız gerekir. Örneğin, bir e-posta otomatik yanıtlayıcısına sahip bir platform kullandım, ancak bir spam denetleyicisine yerleştirilemez. Bunun kullanılması, birçok e-posta sistemi tarafından hızla yasaklanan spam'in geri saçılması anlamına gelir.
İhtiyaçlarınıza göre özellikleri tam olarak uygulayabildiğini varsayarsak, proje ilerledikçe ürünleştirmede sorun yaşarsınız. Değişim kontrolü bariz bir örnektir.
Değişiklikler oluşturmak için kodu kullanmaya, ardından bunları ayrı bir test ortamına ve son olarak da üretim ortamına (bu özelliği kademeli olarak etkinleştirmek için) dağıtmaya alışkınız. Hatalar oluşursa, bunlarla hızlı bir şekilde ilgilenebilir ve sorunu tüm kullanıcıları etkilemeden çözebiliriz.
Sistem "kodsuz" olduğundan, üretim dışı bir ortamda test yapmak genellikle zor veya imkansızdır. Salesforce, bu işi tamamlamak için kullanılabilecek bazı mükemmel araçlara sahiptir, bu ortamda bile, çok zordur.
"Kodsuz" un başarısı?
Yazılım talebini sorgulamak, iyi ya da kötü olmaktan başka bir şey değildir. "Kodsuz" sistem, kavram kanıtlama aşaması için iyi bir rehberdir.
BT dışı sistemler olarak, gerçek iş tasarımı girdisi ve geri bildirimi elde etmede de çok faydalıdırlar. Çevik geliştirme hakkında çok konuşmamıza rağmen, geliştirme ekibinde son kullanıcıları nadiren görüyorum.
Kendi içlerinde "kod yok" olmasa da, kullanıcıların daha fazla teknik çıktı üretmesine izin veren birçok araç vardır. En sevdiğim örnek bir iş zekası aracı olan Looker, farklı pazar segmentlerinde birçok benzer araç var. Geleneksel yazılım geliştirme araçlarını kullanarak model geliştirmelerinin tamamen düz metin olduğunu buldum, bu çok ilginç.
sonuç olarak
Çoğu ana akım geliştirmeye alternatif olarak "kod yok" un boş bir hayal olduğunu düşünüyorum. Geçtiğimiz 70 yıl içinde, metin tabanlı geliştirmeyi değiştirmeye cesaret etmemize izin veren herhangi bir ileri teknoloji yoktu.
Bir yazılım geliştirme CTO'su olarak, çeşitli "kodsuz" araçların çok değerli olduğunu düşünmeme rağmen, dikkatlice konuşlandırılmaları gerekir. Yazılım geliştirme için her derde deva değiller ve durumu daha iyi olmaktan çok daha kötü hale getirmeleri muhtemeldir.
Benim için en ideal kullanıcılar "süper kullanıcılar": Zaten çok yetenekli olan BT kullanıcıları daha iyi araçlar tasarlayabilir. Onlara bir teslimat ortamı sağlamak son derece önemlidir, ancak bu bizim teknolojimiz olmalı Her iki tarafın "kodlu / kodsuz" personelinin ortak çabalarına karşı çıkılmamalıdır.
Orijinal: The'No Code 'Delusion
Bağlantı: https: // www. Alexhudson .com / 2020/01/13 / kod-yok-kuruntusu /
Yazar: Alex Hudson, Freeman Clarke'da Kesirli CIO / CTO
Çevirmen: Yeldeğirmeni Yunma
Kodsuz geliştirmenin güvenilir olduğunu düşünüyor musunuz?
