Modern araçlar ve hizmetler geliştiricileri daha üretken hale getirse de, hala bir “uygulama bölünmesi” var. Bu, oluşturabileceğiniz kaynaklara sahip olduğunuz kod ile ortaklarınızın istediği kod arasındaki boşlukla ilgilidir. Geliştirme ekipleri genellikle aşırı yüklendiğinde ve temel iş sistemlerine ve onlarla çalışmak için gereken araçlara odaklanarak çalışmalarına öncelik vermeleri gerektiğinde zor bir takas.
Bu nedenle, düşük kodlu araçların popüler hale gelmesi şaşırtıcı değil. Son kullanıcılara ihtiyaç duydukları uygulamaları oluşturmalarına ve paylaşmalarına yardımcı olacak bir dizi araç sağlamak için tanıdık kavramlar üzerine inşa ederler. Excel ve Access’in mantıksal ardılları olan bu araçlar, ortak yapı taşlarından basit kullanıcı deneyimleri oluştururken verilere erişim sağlayan ve uygulamaları ve hizmetleri birbirine bağlayan oyun alanlarıdır. Bunları, operasyonlardan iş akışlarını çıkarabilen ve bu yakalanan eylemleri koda dönüştürebilen modern süreç otomasyon araçları olarak düşünebilirsiniz.
Zapier ve Microsoft’un Power Platform gibi düşük kodlu araçlar, genellikle geliştirme talebini boşaltmanın bir yolu olarak görülür ve kullanıcıların ihtiyaç duydukları uygulamaları ihtiyaç duyduklarında oluşturmalarına olanak tanır. Uygulama açığını azaltmanın bir yolunun olması iyi bir şey olsa da, düşük kodlu araçları tek başına değerlendirmeyi imkansız kılan önemli sınırlamalar vardır.
Oyunun merkezindeki API’ler
Düşük kod yoğunluğunda genellikle gözden kaçan şey, bunun temelde bir iş akışı ve uç noktaların oluşturulmasını ve yönetilmesini içeren bir entegrasyon teknolojisi olmasıdır. Burada, mevcut uygulamalar ve hizmetler için yönetilen API’ler sağlamakla görevlendirilmeleri gerektiğinden, mevcut geliştirme ekipleri gerekli hale gelir. Düşük kodlu araçların çoğu tarafından kullanılan REST tabanlı API kalıplarının uygulanması ve desteklenmesi nispeten kolay olsa da, bu süreç yeni bir dizi sorunu beraberinde getiriyor: Bu API’lere kimlerin erişimi var ve bunlar neye erişebilir?
Mevcut kimlik platformunuza bağlı bir tür API yönetimi olmadan düşük kodlu çözümleri uygulayamazsınız. Güvenlik ve veri bütünlüğünü sağlamak için rol tabanlı erişim kontrolleri ve yönetilen kısıtlama gerekli olacaktır. Korunan verilere yalnızca ihtiyaç duyanların erişebildiğinden ve çok fazla kullanıcının işletim sistemlerinin işleyişini etkilemeyeceğinden emin olmalısınız. API yönetimini düşük kodlu paketinize entegre ederek, API’lere erişmesi gereken kullanıcılara, veri kaybını önlemek için kullanılmayan hesaplar silinerek basit self-servis süreçleri kullanılarak yetki verilebilir.
Ekip çalışması daha mı değerli?
Sonra bir boşlukta düşük kod geliştirme sorunu var. Çok sık olarak, kaynaklar birden çok kez oluşturulur ve kullanıcıları kodun yeniden kullanımı ve taşınabilirliğinin avantajlarından mahrum bırakır. Sorunun bir kısmı, kaynak kontrol sistemleriyle veya GitHub gibi sosyal kodlama ortamlarıyla entegrasyon olmadan, tescilli ortamlarda birçok düşük kodun geliştirilmesidir. Orijinal düşük kodlu, Excel tabanlı ortam bile, farklı projeler arasında kod bloklarını paylaşmanıza izin veren yeni LAMBDA özelliğiyle tescilli modelden uzaklaşır.
Ancak açık olan şu ki, düşük kod, görsel bir tuvalde, sürükle ve bırak yöntemiyle oluşturulsa bile kod olarak kalır. Güvenli ve güvenilir olduğundan ve mümkün olan her yerde bu uygulamaları oluşturmak için kullanılan bilgilerin kaybolmadığından ve diğer ekiplerle paylaşılabildiğinden emin olarak, buna tipik kurumsal geliştirme kodumuzla aynı şekilde davranmalıyız.
İlk düşük kodlu araçlar, bu konuda gerekli olan şeylerin çoğunu görmezden geldi. Elbette, geliştirici incelemeleri ve diğer kilometre taşları ile süreçleri devreye sokmak mümkündü, ancak bu yaklaşım, düşük kodun bariz faydalarını boşa çıkararak, beklenen ömrü yalnızca birkaç ay olan uygulamaların hızlı geliştirilmesinin önüne engeller koyuyor.
Dikkate alınması gereken bir büyüme kaldıracı
Büyük ölçekli geliştirme araçlarına düşük kod ekleyerek, farklı grupların belirli sorunları çözen bir uygulama veya hizmet oluşturmak için birlikte çalıştığı “birleştirme ekipleri” olarak bilinenleri oluşturarak, organizasyonun farklı bölümlerinden becerilerden yararlanmaya başlayabilirsiniz. Birleştirme ekibinin her üyesinin farklı bir sorumluluğu olacaktır: biri son kullanıcı olabilir, diğeri düşük kod geliştirici olabilir, diğeri ise hizmet API’lerini yönetebilir.
Böyle bir ekip için sabit bir yapı yoktur; belirli bir görev için ihtiyaç duyulan insanlardan oluşur. Yüz yüze görüşmeleri bile gerekmez: proje için bir Slack veya Teams kanalı en yaygın etkileşimler için yeterli olabilir. Daha yeni araçlar bu durumu değiştirmeye başladı, yeni yönetim konseptleri ve kod paylaşmanın yeni yollarını getirdi. Ana gelişmelerden biri, grafik araçlarla yapılabileceklerin çoğunu kapsayan ve düşük kod geliştirmemizi CI/CD ardışık düzenlerine ve sosyal medyaya entegre etmemize olanak tanıyan yeni dillerin geliştirilmesiyle, tamamen grafik araçlardan uzaklaşmadır. GitHub gibi kodlama araçları.
Bu yeni diller, düşük kodlu ortamlar için daha uygundur ve SQL sorguları ve Excel formülleri gibi kavramlara dayanır. Bildirime dayalı ve işlevsel programlama kavramlarının bir karışımını anlamakta ve kullanmakta hızlıdırlar. Kullanıcılar, normal grafik geliştirme ortamlarını kullanarak çalışmaya devam edebilir ve ortaya çıkan kodu otomatik olarak github alanlarına kaydedebilir. Bu arada, geliştiriciler bu kodu IDE’lerinde veya kod düzenleyicilerinde hızlı bir şekilde inceleyebilir. Bağlam değiştirme yoktur ve herkes, yapması gereken işi yapmak için ihtiyaç duyduğu araçlara sahiptir. Geliştiriciler daha sonra CI/CD işlem hatlarını kullanarak kodu yayınlamadan önce hızlı bir şekilde test edebilir, kusurları ve diğer kritik hataları arayabilirler.
Geliştiriciler için bir fırsat mı?
Düşük kodu koda dönüştürmek, yeni nesil makine öğrenimi tabanlı kodlama yardımcılarından yararlanmanıza olanak tanır. OpenAI’nin Codex modeli gibi teknolojiler, koddaki ortak kalıpları tanımlayabilir ve diğer uygulamaların benzer sorunları nasıl çözdüğüne bağlı olarak önerilerde bulunabilir. Örneğin, düşük kodlu bir uygulamanın bir ERP sistemine bağlı bir kontrol ızgarasına ihtiyacı varsa, uygun bağlantı dizilerinin nasıl oluşturulacağı veya bir sorgunun en iyi nasıl biçimlendirileceği konusunda önerilerde bulunabilir.
Bu yaklaşım henüz emekleme aşamasında olmasına rağmen, şimdiden umut verici olduğunu kanıtlıyor. Bu, sizin için bir AI yazma koduna sahip olmaktan çok, AI ile çalışan bir programcının çiftler halinde kodun nasıl geliştirileceğine dair önerilerde bulunmasıyla ilgilidir. Düşük kodlu uygulamalar oluşturmayı öğrenirken, yavaş yavaş yerden kalkabileceğiniz, yapay zeka ve geliştirici kaynaklarına olan bağımlılığınızı azaltabileceğiniz bir dizi eğitim çarkınız olur. Çekirdek sistem geliştiricilerinin API’ler oluşturduğunu, yapay zekanın kullanımlarını iyileştirdiğini ve kullanıcıların iyi çalışan ve diğer kullanıcıları rahatsız etmeyen yüksek kaliteli uygulamalar oluşturmak için önerilerini hızla takip ettiğini hayal edebilirsiniz.
Uygulamaları oluşturma ve kullanma şeklimizde büyük bir değişikliğin henüz ilk günlerindeyiz ve düşük kod, bu yeni devrimin önemli bir parçası olacak. Düşük kod ve genel uygulama geliştirme arasındaki ilişki yakın olmalıdır. Ancak, düşük kod geliştirme kaynaklarının eksikliğini gidermenin bir yolu olarak görüldüğünden, bu, dikkatle yönetilmesi gereken bir ilişkidir. Bu nedenle, kuruluşların etkin API yönetiminin, kod paylaşımını geliştiren araçların kullanımının, kuruluş sınırlarını aşan yeni ekip yapılarının ve son olarak, riski azaltmak ve üretkenliği artırmak için makine öğrenimini kullanmanın öneminin farkına vardığını görmek güzel.
Kaynak: ZDNet.com
