Low-code konusunda şüpheliyim

• Low-code konusunda şüpheci bir bakışa sahibim
• Yazılım danışmanlığı yaparken, low-code’un hızlı geliştirme süresi ve düşük bakım maliyeti vaat eden reklamlarına kapılan müşterilerle sık sık karşılaşıyorum
• Müşterilerin memnun kalmamasının birkaç nedeni var

Özelleştirilmiş özelliklerin sınırları

• Low-code çözümleri şirket gereksinimlerinin yaklaşık %80’ini karşılıyor, ancak kalan %20 temel işlevlerle çözülemiyor
• Low-code araçlarının pazarlamacıları kalan %20’nin kolayca çözülebileceğini iddia ediyor, ancak gerçekte ciddi ölçüde özelleştirme gerekiyor ve bazen bu mümkün bile olmuyor
• Şirketler ya aracın temel işlevlerinin yeterince yakın olup olmadığını kabul etmeli ya da aracı hack’leyerek tam kendi kullanım senaryolarına uydurmaya çalışmalı

Geliştirici havuzunun sınırlılığı

• Şirketler bazen low-code araçlarını hack’leyerek gereksinimlerin %100’ünü karşılamaya çalışıyor
• Sonuç olarak belirli bir araç veya kapalı bir dil içinde çok sayıda özelleştirilmiş kod yazılıyor ve bunu anlayabilecek geliştirici sayısı çok az oluyor
• Artık şirket, yaygın kullanılan açık kaynak dilleri bilen geliştirici havuzundan işe almak yerine, bu araca son derece uzmanlaşmış bakımcılar bulmak zorunda kalıyor

Platform yükseltmelerinin sorunu

• Yazılımı yükseltirken entegre çalışan parçaların bozulmamasını sağlamak zordur
• Low-code araçları, kendi tasarım kapsamlarının dışında kalan kullanım senaryoları için rastgele kodları da işlemek zorunda kalır
• Bunun katı API sözleşmeleriyle yapılabilmesi gerekir, ancak pratikte özelleştirilmiş kodun içeride her türlü numarayı çevirdiğini çok görüyorum

Veritabanı yapısındaki karmaşa

• Ayrıntılı analizin kritik olduğu süreçlerde low-code araçları kullanan şirketler görüyorum
• Ancak temel veri modeline baktığınızda durum anlaşılmaz hale geliyor: user_attribute_47 ne anlama geliyor? Uygulamanın 1. sayfasındaki bir alanı 2. sayfaya taşıdığınızda veri neden ayrı bir alanda duruyor?

GN⁺ görüşü

• Low-code, geliştirme hızını artırma ve bakım maliyetini düşürme potansiyeli taşıyan umut verici bir araç olsa da, gerçek kullanımda beklenmedik sorunlar ortaya çıkabilir.
• Özellikle özelleştirilmiş işlevler gerektiğinde veya belirli bir low-code aracına bağımlı geliştirme dilleri kullanıldığında, geliştirici havuzu daralır ve bakım zorlaşır.
• Low-code araçlarının yükseltilmesi ve veritabanı yapısının karmaşıklığı, uzun vadeli proje yönetiminde önemli değerlendirme noktalarıdır.
• Bu yazı, low-code araçlarını kullanırken dikkat edilmesi gereken noktaları vurguluyor ve uygun kullanım senaryolarının dikkatle değerlendirilmesini önererek ilgi çekici içgörüler sunuyor.

[ats62]

Şimdiye kadarki no-code kavramının belirli alanlarda sınırlı şekilde uygulanabildiğini düşünüyorum.

LLM kullanılarak iyi yapılmış servisler ortaya çıkarsa, no-code trendinin? akışının? eğiliminin? her neyse, önce kavramının değişeceğini düşünüyorum

[quack337]

Yaklaşık 10 yıl önce MS Access’in faydalı şekilde kullanıldığı bir örneği biliyorum.

Kuruluşun bilgi sisteminde, nispeten iyi tasarlanmış ve MS Sql Server üzerinde uygulanmış bir veritabanı vardı,
günlük OLTP işleri de yine nispeten iyi şekilde hayata geçirilmişti.

Ancak günlük olmayan veri sorgulama ve rapor çıktısı taleplerine IT departmanının yavaş ve isteksiz yaklaşımına yönelik memnuniyetsizlik birikmişti.

MS Excel ve Access’i iyi kullanabilen bir iş birimi çalışanı, bilgi sisteminden indirilen Excel verilerini Access’e import edip, ihtiyaç duyulan veri sorgulama ve rapor çıktısı işlevlerini kod yazmadan yalnızca birkaç saat içinde Access ile gerçekleştirebileceğini gösterdi.

[quack337]

İş birimi, Access'ten doğrudan DB'ye bağlanabilmeyi talep etti; IT birimi ise bilgi sistemi DB'sinin dış ağa açılmasına karşı çıktı. Ancak iş biriminin talebi güçlü olduğu için, yalnızca bazı verilerin yansıtıldığı ayrı bir mirror DB oluşturulup dışarıya açıldı.

Excel veri özelliklerini iyi kullanabilen çalışanlar ise birkaç günlük eğitimle Access'i işlerinde kullanmaya başlamıştı.

[tequila]

Bu yazıya katılıyorum. Tamamen kişisel görüşüm ama,
Özel sözdizimi kullanılıyorsa -> bir öğrenme eğrisi gerekiyor ve bakım zorlaşıyor
UI kodun basit bir yerine geçiyorsa -> çoğu durumda doğrudan kod yazmak daha rahat oluyor
Tam teşekküllü bir no-code araç haline geliyorsa -> kısıt çok oluyor ve kullanıcıların hack'lemesi teşvik ediliyor. Amaç dışı davranan kullanıcıların sıklığı da ciddi biçimde artıyor
Sonuç: Kimsenin memnun kalamayacağı bir araç ortaya çıkıyor.
Planlama-geliştirme-kullanıcı arasındaki uçurum birbirinden fazla büyük olduğu için, düşünüldüğünden daha iyi yapmak zor bir alan gibi görünüyor.

[GN⁺]

Hacker News görüşü

• Low-code hakkında çeşitli bakış açıları

  • Low-code platformu geliştiricisinin bakış açısı

    Low-code satması kolaydır. IT departmanını sorun gibi gösterip mevcut memnuniyetsizliklerden yararlanan bir strateji kullanır. Demolarda basit işleri hızlıca gösterir. Ancak çekirdek iş mantığını low-code içine koymamak daha iyidir. Karmaşık işlerin uzman sistemlere offload edileceği varsayılır. Büyük şirketlerde teknik bilgisi olup IT yetkisi az olan ekipler için faydalıdır. Low-code, basit araçlarla birçok sorunu çözer ama ölçeklenebilirliği düşüktür ve güçlü merkezi sistemlerle birlikte çalışması gerekir.

  • SRE (site güvenilirliği mühendisi) bakış açısı

    Low-code konusunda şüpheci. Kaynak kod yönetimi yetersiz ve dokümantasyon iyi değil. Çok sayıda özel kod gerekiyor ama yeniden kullanılabilirlik düşük. Tescilli runtime gereksinimleri var ve izleme zor. Gerçekte işi mühendislerin yapıp mühendis olmayanların kullandığı bir durum görmediğini söylüyor. Looker gibi araçlar kaynak kod entegrasyonu sağlayabiliyor ama yine de bunları mühendisler kullanıyor. Karmaşıklığı sıkıştırıyor ama gerektiğinde özelleştirilebilen ve genişletilebilen platformları tercih ediyor.

  • Microsoft low-code platformuna dair bakış açısı

    MS low-code platformuyla ilgilenmiş ama bunun O365 ve Azure üzerinde karmaşık biçimde inşa edildiğini düşünüyor. Kullanıcı arayüzü zayıf ve uzun vadede maliyet tasarrufundan çok kullanılabilirlik sorunlarının yol açtığı kayıplar daha büyük olabilir.

  • MS-Access veritabanı/form çözümlerini dönüştürme iş deneyimi

    Geliştirici olmayanların/son kullanıcıların IT departmanından geçmeden oluşturduğu MS-Access çözümlerini gerçek .net istemci/sunucu uygulamalarına dönüştüren bir iş kurmuş. Low-code çözümleri bazı sorunları çözmek veya bir POC’yi çalıştırmak için yararlı olabilir, ancak ölçek büyütme ya da uyarlama gerektiğinde sorun çıkarabilir.

  • SQLPage web sitesi oluşturucusu geliştiricisinin bakış açısı

    Low-code çözümlerinin, harici "high-code" API’lerle etkileşime girebilecek bir çıkış yoluna sahip olması gerekir. SQLPage bunu sqlpage.exec ile sağlıyor. Low-code platformundaki yükseltmelerin özel implementasyonları bozabilmesi bir sorun. Low-code araçlarının çoğu veriyi rehin alırken, SQLPage kullanıcıların hâlâ tam kontrole sahip olduğu bir veritabanının üzerine bir katman ekliyor.

  • Kurumsal düzeyde low-code araçlarına karşı görüş

    Büyük şirketlerin kullandığı low-code araçlarına karşı. Büyük şirketler uygun geliştirme ekiplerini, planlamayı ve organizasyonu karşılayabilmeli. Maliyeti oluşturan şey kodun kendisi değil; kötü geliştiricilerin kötü araçlarla kötü kararlar vermesi.

  • Low-code ve soyutlama katmanları hakkında bakış açısı

    "Low-code", doğrudan arayüz kurulabilen kod yüzeyinin küçük olduğu anlamına gelse de gerçekte çok fazla kod gizlidir. Soyutlama katmanları amaçla iyi örtüştüğünde güçlüdür, ancak sızıntı olduğunda ya da uyumsuz kaldığında sorun yaratabilir. Genel olarak low-code, belirli kullanım amaçlarına göre yazılmış kodu soyutlar ama pratikte yine de belirli bir alan deneyimi gerektirir.

  • Bubble/Airtable kullanarak MVP oluşturma deneyimi

    Ukraynalı bir ekipten MVP geliştirme teklifi almış, ancak bir stajyer işe alıp Bubble/Airtable kullanarak ürünü iki ayda geliştirmiş ve altı ay içinde ücretli müşteriler kazanmış. Neredeyse iki yıldır geleneksel bir stack’e geçmek için bir neden bulamamış.

  • Low-code öğrenim içeriği geliştirme sürecine dair korku hikâyesi

    Önemli bir şirket, pazarlama ve satış çalışanlarına yönelik şirket içi eğitim içerikleri geliştirmek için low-code bir eğitim içeriği oluşturma yazılım paketi kullanmış. Birkaç yıl sonra içeriklerin güncellenmesi gerektiğinde, geliştirmede kullanılan yazılım ya da işi yapabilecek araçlar artık ortada olmadığından sorun yaşanmış.

  • Low-code uygulamalarında sürüm yönetimi yapılabilir mi sorusu

    Low-code implementasyonlarının sürüm kontrolüne alınıp alınamayacağı, sorun çıktığında kök nedenin bulunup bulunamayacağı ve ücretsiz araçlarla belirli bir commit’e geri dönülüp dönülemeyeceği sorgulanıyor. Çoğu durumda bu tür özellikler olmadığından ciddi kullanım için uygun görülmüyor.