İnsanlar neden hâlâ VBA kullanıyor?

 (sancarn.github.io)
3 puan yazan GN⁺ 2023-11-16 | 1 yorum | WhatsApp'ta paylaş
  • Birçok kuruluşta Excel iş süreçlerinin temeli hâline geldiği için, küçük bir otomasyon gerektiğinde VBA fiilen varsayılan seçenek oluyor
  • Örnek kuruluştaki 13 veri platformu ve çeşitli otomasyon araçlarına rağmen, gerekli veri kaynaklarına geniş kapsamlı erişebilen araçlar VBA ve PowerShell ile sınırlı kalıyor
  • CyberSecurity, Python, Ruby, Node, Rust gibi üst düzey dillerin kurulumunu reddetti; alternatif olan Power Platform ise veri erişilebilirliği ve karmaşık algoritmaların bakımı konusunda sınırlamalar gösteriyor
  • Lotus Notes ve IBM BPM geçiş örnekleri, IT öncülüğündeki sistemlerin desteğin sona ermesi, tamamlanmamış geçişler ve bakım boşlukları karşısında kırılgan olabileceğini gösteriyor
  • VBA eski ve zayıf yönleri olsa da Office’in içinde geldiği için herkesin erişimine açık; SME’lere iş mantığını ve veri geçişini doğrudan doğrulayabilecekleri bir kontrol sağlıyor

VBA’nın seçilmeye devam etmesinin doğrudan nedeni

  • 2021’deki /r/vba anketinde VBA kullanıcılarının çoğu, VBA’yı başka seçenekleri olmadığı için kullandıklarını söyledi
  • Birçok kuruluş tüm iş süreçlerini Excel üzerinde yürütür; az miktarda otomasyon gerektiğinde çoğu zaman ilk tercih VBA olur
  • “Altyapının bir kısmını elektronik tablolarla kontrol ediyorlar” eleştirisinin arkasında, kuruluşun sunduğu araçlar, veri erişilebilirliği ve bakım yapısındaki kısıtlar vardır

Veri erişilebilirliği ve otomasyon araçlarının kısıtları

  • Örnek kuruluştaki mühendislik birimi çeşitli otomasyon platformlarını kullanabiliyor
    • OnPrem: PowerShell, Excel’de VBA / kısıtlı OfficeJS / OfficeScripts / PowerQuery, PowerBI Desktop, SAP Analysis for Office
    • OnCloud: PowerApps, Power BI, premium olmayan PowerAutomate
    • Sandbox ortamı: ArcGIS için ArcPy, MapInfo için MapBasic, InfoWorks ICM için Ruby, ArcGIS Online
  • IT tarafından yönetilen veri platformları D1den D13e kadar uzanıyor ve jeo-uzamsal DB, SAP DB, telemetri platformu, SharePoint, Lotus Notes, IBM BPM, dosya sistemi, Hydraulic Model Information gibi sistemleri içeriyor
  • Gerekli veri kaynaklarına bağlanabilen otomasyon platformları kabaca VBA ve PowerShell ile sınırlanıyor
    • Power BI Desktop kuruluşa alınmış olsa da VBA’nın eriştiği tüm platformları kapsayamıyor
    • Erişim kapsamı aynı olsa bile Power BI süreç otomasyonu için kullanımı zor; başka veri kümeleriyle çalışmak için CSV üretip SharePoint’e kaydetme yöntemi kullanılıyor
    • Bu CSV üretimini de bazı durumlarda VBA üstleniyor
  • VBA’nın bazı OnCloud servis bağlantıları doğrudan denemelere dayanıyor; SAP BW4HANA ve diğer bulut servisleriyle de VBA üzerinden arayüz kurulabileceği düşünülüyor, ancak kimlik doğrulama gereksinimleri ve protokoller henüz çözülmüş değil

Üst düzey dillerin ve Power Platform’un sınırları

  • Kuruluş, iş otomasyonu için Python, Ruby, Node, Rust gibi üst düzey diller kullanmak istiyordu; ancak ekip genelinde ya da iş birimleri genelinde kurulum taleplerinin tamamı CyberSecurity tarafından reddedildi
  • Ret gerekçesi, son kullanıcılara üst düzey programlama dillerine erişim vermenin şirketin teknoloji stratejisi vizyonuyla çelişmesiydi
  • Alternatif olarak anılan PowerAutomate ve PowerApps, gerekli verilere neredeyse hiç erişemiyor
  • Veri erişimi mümkün olsa bile Power Platform çoğu süreci yürütmek için yetersiz kalıyor
    • Gerekli algoritmalar karmaşık olduğundan PowerAutomate çözümlerinin bakımı zorlaşıyor ve IT personeli için bile anlaşılması güç olabiliyor
    • Örnek olarak projection algorithms anılıyor
  • Sonuçta pratikte geriye kalan araçlar PowerShell v3 ve VBA oluyor
    • PowerShell v3 class söz dizimini desteklemiyor ve modül kurulumu da mümkün değil
    • VBA ise modern ölçütlere göre makul bir dil hâline getirmek için yüzlerce saat harcanarak open source VBA libraries oluşturulan hedef hâline gelmiş

Bakım güvencesi olarak VBA

  • 2000’lerde birçok sistem IBM Lotus Notes veritabanları üzerine kuruldu
  • Lotus Notes, 2019’da HCL tarafından satın alındıktan sonra destek sürekliliği sarsıldı ve resmi desteğin Haziran 2024’te sona ermesi planlanıyordu
  • 2019’dan itibaren teknoloji ekibi çeşitli sistemleri yeni teknolojilere taşımaya çalıştı; kuruluş, tek bir Lotus Notes DB’nin yerini almak için IBM Business Process Manager tabanlı bir sistem geliştirmeye büyük bütçe ayırdı
  • Plan, D11e tüm D10 verilerini doldurduktan sonra D10u arşivlemekti; ancak 2023’teki durum farklıydı
    • Resmi desteğin sona ermesine 8 ay kalmıştı
    • Teknoloji ekibi IBM BPM destek sözleşmesini kaldırdı
    • Hem IBM BPM hem de Lotus Notes DB için bir yedek sistem görünmüyor
    • IBM BPM çözümü bakım eksikliği yaşıyor ve gerektiği gibi çalışmıyor
    • Amaca uygun olmayan bir çözüm IBM BPM’e zorla yerleştirilmiş durumda
    • REST API var, ancak teknoloji ekibi ve SME’ler için neredeyse işe yaramıyor
      • Bazı REST çağrıları string olarak kodlanmış JavaScript kullanıyor
      • Diğer çağrılarda XML içindeki JSON içine HTML koymak gerekiyor
      • DB tabloları adla değil GUID ile sorgulanıyor
      • Hangi GUID’nin hangi tabloya veya sürece karşılık geldiğine dair dokümantasyon yok
    • D10 verileri gerçekte D11e taşınmadığı için iş birimi 1 değil 2 sistem kullanıyor
    • D11 veri modeli de D10 verilerini düzgün desteklemiyor
  • SME’ler araçları her gün kullanan ve sistem değişikliği ihtiyaçlarına karar veren kişilerdir
  • SME’ler VBA kullandığında, sistemi ihtiyaç duydukları ölçüde doğrudan kontrol edip sürdürebilir; bu da IT sistemlerinde garanti edilmeyen bir bakım güvencesi işlevi görür

Kontrol ve SME iş birliği sorunu

  • Yakın tarihli bir projenin amacı, iş biriminin kritik elektronik tablosunun yerini alacak yeni bir entegre IT sistemi oluşturmaktı; başarılı olursa D6nın önemi C seviyesine düşecekti
  • İlk şartname basitti
    • NodeJS sunucusu ve MySQL veritabanı
    • React UI
    • Yöneticilere ve SME’lere codebase ve git erişimi verilmesi
    • IT ile SME’lerin sistemi iş birliği içinde kurması
  • Teknoloji ekibi farklı talepler ortaya koydu
    • Yöneticiler ve SME’ler koda erişemeyecekti
    • Frontend, “Strategic Vision”a uygun olarak Microsoft PowerApps ile kurulacaktı
    • Backend, “Strategic Vision”a uygun olarak Microsoft Azure Pipelines ile kurulacaktı
  • SME açısından bu talepler çeşitli sorunlar doğuruyor
    • Teknoloji ekibi saha işini anlamadığı için iş mantığını ve hesaplamaları anlamakta zorlanır
    • İş mantığını geliştirici yazdığında hataya açık olur
    • Teknoloji ekibi özel teknoloji projelerini sık sık sahipsiz bırakır; bakım ve iyileştirme kaynakları kaybolur
    • SME’lerle iş birliği yapılırsa en azından bir ekip sistemin bakım kaynaklarını koruyabilir
    • SME’lerin çıktılara güvenebilmesi gerekir; ancak kod görünmüyorsa tüm edge case’lerde çalışıp çalışmadığını doğrulamak zordur
    • Unit test’ler olsa bile kod görünmüyorsa testlerin gerçekten var olduğunu ve sık çalıştırıldığını doğrulamak güçtür
    • SME’ler mevcut legacy sistemleri iyileştirip sürdürür ve sistemler arası etkileşimler hakkında çok fazla bilgiye sahiptir
    • Tüm verilerin yeni sisteme doğru biçimde taşındığını ve temsil edildiğini doğrulamak için backend erişimi gerekir
  • Kod VBA’da kaldığında SME’ler ve iş birimi kontrolü elinde tutar
  • Teknoloji ekibi iş ekiplerine neredeyse hiç kontrol devretmez; SME’ler ise yazılımın düzgün biçimde modüler geliştirildiğini ve gevşekçe birbirine bağlanmış bir teknoloji yığınına dönüşmediğini kontrol edebilir

Tanıdık ortam içinde kullanıcı deneyimi

  • Çoğu mühendis günlük işlerinde elektronik tablo kullanır
  • VBA, elektronik tablonun içine gömülü olduğu için tanıdık bir ortamda yabancı bir araç sunabilir
  • Yabancı bir ortamda yabancı bir araç sunmaktansa, tanıdık bir ortamın içine yeni özellikler eklemek kullanıcı için daha güçlü olabilir

Sonuç: VBA’nın zayıf yönleri ve gerçekçi seçim

  • Kuruluşların elektronik tablo ve VBA seçmesinin çeşitli nedenleri var
    • Güvenlik kaygıları nedeniyle IT’nin sunduğu alternatifler zayıf kalıyor
    • Alternatif araçlar kaynak sistemlere düzgün bağlanamıyor ve genellikle hâlâ geliştirme aşamasında oluyor
    • Bazı kullanım senaryolarını yansıtmayan IT stratejisi sorunları var
    • Güvenlik ve bakım kaygıları nedeniyle SME’lerle iş birliği yapmak istemiyorlar
    • Kullanıcılar, yöneticiler ve SME’ler yedek sistemler konusunda yeterince eğitim almıyor
    • Kullanıcılar ve SME’ler sistemin iş mantığı üzerinde belirli düzeyde kontrol istiyor
    • Office’e dahil olduğu için herkesin kullanabildiği tek uygulanabilir teknoloji
  • VBA’nın zayıf yönleri yok değil
  • mataroa’daki yazıda kısmen doğru noktalar var
  • Bazen yönetim berbat olabilir; ancak kuruluşlardaki birçok kişi, kendilerine verilen araçlar içinde doğru olanı yapmaya çalışır

İlgili okumalar

1 yorum

 
GN⁺ 2023-11-16
Hacker News yorumları

  • Şirketlerde, envanter dışı yazılım onayı almak için yönetim, üst yönetim, proje kaydı, bütçe, proje yöneticisi ataması vb. süreçlerden geçmek zorunda kalmadan kullanılabilecek bir geliştirme ortamı zaten Excel’in içinde var.
    Ağ veri deposu ve web arayüzü de istiyorsanız SharePoint’i eklersiniz. Çözüm bu son kullanıcı yönünden çıkar ve o çözüm VBA ile yapılır.

    • Şirket denen distopik ortamda, kendi cihazınıza yazılım isteyebileceğinizi ya da kurabileceğinizi varsaymamalısınız. Yalnızca zaten mevcut olanı kullanabilirsiniz; bunu değiştirmek için bürokrasiyle savaşmanız gerekir ve buna değmez.
      Eskiden Word VBA ile yapılmış korkunç bir rapor motoru, dosya paylaşımından rapor tanımlarını okur, şablon parçalarını kesip yapıştırır ve sonra çıktı üretirdi. IT, şirketten ayrılan birinin PC’sini geri almadığı için o makineyle bütün gün .doc dosyaları döndürüp mühendislik raporları üretilirdi; bu, CAD/CAM yazılımının raporlama seçeneğini satın almaktan çok daha hızlı ve ucuzdu. O seçenek en az 18 ay, danışmanlar ve proje bütçesinin tükenmesini gerektirirdi.
      İnsanlar Excel VBA ile korkunç işler yapılıyor diye sövdüğünde, nedenin yığının daha üst katmanlarında olma ihtimali yüksektir. Bir başka neden de “maymun çekici”dir: Maymuna çekiç verirseniz her şeye vurduğu gibi, elinizdeki tek araç VBA ise her şey VBA çözümü gibi görünür. Şimdi biraz daha evrimleşmiş primatlar olduk.
    • Bir departman yöneticisinin bir şeye ihtiyaç duyup geliştirme ekibini rahatsız edemediği ya da etmek istemediği için “Bu ne kadar zor olabilir ki?” diye başladığı sahneyi en az iki kez gördüm. Sonra bir bakmışsınız birkaç yüz satırlık VBA ortaya çıkmış ve kendi ihtiyacını çözüyor.
      Sonraki aşamada Jim de çalıştırmak istediği için betik kopyalanıyor, Jane farklı bir VBA sürümü kullandığı için üzerinde değişiklik yapılıyor ve artık “şunu da ekleyelim!” denerek genişliyor. Sonunda 1500 satırlık yamalı bohçaya dönüşüyor ve bakımını geliştirme ekibine devretmeye çalışıyorlar.
    • Bir arkadaşım Excel ile kendi işinin tamamını otomatikleştirmiş. Bir günlük işi 15 dakikada bitirip geri kalan zamanda dinlendiğini söylüyor.
      Şirket bilgisayarı çok sıkı kilitli olduğu için hiçbir şey kuramıyor, beyaz listede olmayan sitelere de gidemiyor ama Excel var.
    • Visual Basic’in kendisi de çok güçlü bir dil. Excel makroları gibi ortamlarda bu gücün epey büyük kısmını ortaya çıkarabilirsiniz ve birçok şirketteki power user gerçekten bunu yapıyor.
      Eski “Emacs işletim sistemi” paradigmasını başka bir bağlama uygulamaya oldukça benziyor.
    • VBA orada duruyor ve çalışıyor. Kod yazıp yineleme yapmak için çok erişilebilir ve sezgisel bir dil; dış bağımlılık kurulumları, kütüphane cehennemi veya derleme adımlarıyla zaman kaybetmeniz gerekmiyor.
      Bu yüzden VBA’nın şirketlerde hâlâ çok değerli olması şaşırtıcı değil. Başka araçların ve dillerin, olgun derleme süreçlerinin bulunduğu ortamlarda bile ürün yöneticilerinin VBA ile insanın ağzını açık bırakacak kadar karmaşık iş analizleri yaptığını gördüm; ellerindeki sorun için doğru araç oydu.

  • Profesyonel geliştiricilerin de Excel/VBA’yı yardımcı araç olarak çok kullandığını görünce şaşırmıştım.
    Birkaç yıl önce büyük bir hedge fonla çalışırken bir veri analisti kendi yaptığı Excel modelini göndermişti; .xlsm uzantısını görünce içinde VBA kodu var diye düşündüm. “Bakalım makro kaydetme kovboyları ne yapmış” dedim ama içeride bolca VBA vardı ve yazarı Caltech bilgisayar bilimi mezunu, Python’ı çok iyi bilen bir veri analistiydi.
    VBA, veritabanından veri çekip sayfalara koymak, formüller oluşturmak ve güzel görünecek şekilde biçimlendirmek için kullanılıyordu; birkaç UserForm da vardı. “VBA mı? Orada başka ne kullanıyorsunuz, çırçır makinesi ve buharlı kepçe mi?” diye takıldım; ama beklediğimin aksine Excel ve VBA’yı bayağı övdü, buna şaşırdım.
    Söylediği şu söz aklımda kaldı: “Excel, hesaplamanın ima ettiği bağımlılık yapısını anlamayı kolaylaştırıyor. Bunu Python ile yapmış olsaydım bütün gün sorulara cevap veriyor olurdum.”

    • Geliştirici olarak deneyim kazandıkça işe uygun aracı kullanmanın önemi artıyor. Tembel çözümün anlaşılmaz bir fikir yığınından çok daha iyi olduğu zamanlar var.
    • VBA’nın sorunları var elbette (https://sancarn.github.io/vba-articles/issues-with-vba.html), ama en kötü araç olmaktan çok uzak. Örneğin PowerAutomate gibi şeylerden daha iyi.
      VB6’nın oldukça büyük bir topluluğu var ve https://twinbasic.com/ son dönemde VBA ve VB6 topluluklarını birleştirme konusunda çok yardımcı oldu. Bu yüzden geliştirici topluluğunda küçük bir diriliş bile olabilir.
    • Yürüttüğüm iş büyük ölçüde Google Sheets’e dayanıyor. Değerleri enjekte edip hesaplanmış değerleri okuyarak, oldukça karmaşık iş mantığını elektronik tablo biçiminde tanımlayabiliyoruz; iş ve finans ekipleri de bunu kolayca ayarlayabiliyor. Herkes bu çözümden çok memnun.
    • Excel pek çok iş için harika bir arayüz ve bir yere kadar insanların veriyi anlamasına yardımcı oluyor. Öte yandan insanlar o veri modeline alışkın olduğu için, işler biraz karmaşıklaşınca soru sormak yerine kendilerini suçlama eğiliminde de oluyor.
      İsveç’te yanında 38 sayfalık kullanıcı kılavuzu bulunan 3GB’lık Excel/VBA emeklilik tahmin modeli bile var. Ancak bunu Excel’in çok iyi kullanıldığı bir örnek olarak görmek zor: https://www.pensionsmyndigheten.se/statistik-och-rapporter/p...
    • Büyük bir üniversite hastanesinin ameliyat öncesi yatış kliniği Excel ile yürütülüyordu.
      VBA güçlüdür; prototipleme ve yineleme hızlıdır. Hatta VB6’nın CRUD uygulamalarının zirvesi olduğu bile söylenebilir.

  • “Şaşırtıcı olduğu için”
    Eskiden JP Morgan ağında 20 binden fazla Access veritabanı olduğunu duymuştum. Çeşitli şirketlerdeki veri analistleri bir gün her gün yaptıkları işten sıkıldı ve “makro kaydet” düğmesine göz attı. Bazıları bunun oldukça kullanışlı olduğunu düşünüp kullanmaya devam etti. Daha akıllı davranıp makronun ürettiği koda bakan, biraz öğrenip onu değiştirmeye çalışanlar da çıktı.
    Az sayıda kişi veri yapıları ve algoritmalara kadar öğrenip Django’yu taklit eden kimlik doğrulama ve yetkilendirme sistemleri yaptı, UserForm arayüzünü sıfırdan yeniden oluşturdu; Markdown, SAX ayrıştırma, özel kaydırma çubukları, günlükleme ve hatta oyunlar bile uyguladı.
    Cevap muhtemelen veri analistlerinin her gün yaptıkları işten sıkılmış olması.

    • IT departmanı fildişi kulesinden çok fazla prosedür dayatıp insanları gölge IT’ye itmiş de olabilir. Büyük şirketlerde analistlerin kendi yaptıkları Frankenstein’ı düzgün bir seviyeye çıkarabilecek becerisi olmasına rağmen “projeyi başlatmanız, ticket, takvim ve gereksinimler oluşturmanız gerekiyor” gibi şeylerle engellendiğini gördüm.
      Elbette herkesin gelip öğrenmesi gereken bir şeyi desteklemek zorunda kalmak geçerli bir endişe. Ama iş birimleri sorunlarını çözecek araçlara erişebildiği sürece, “sıkılan” insanlar bir yol buluyor. Sürtünme çok fazla.
    • “Makro kaydet” işin özü. Microsoft C#, JavaScript, Python vb. dillere geçse bile, o düğmeyi koyduğu sürece bu mümkün olur.
    • Finansta başlayıp veri mühendisliği ya da sistem uygulama tarafına geçen birçok kişiyle aynı deneyim.
      Excel içinde belli ölçüde karmaşık bir şey yapıp ağ paylaşımına koymak, IT’den geçip bir IDE kurmaktan, bir şeyler yapmaktan, güvenlik süreçlerinden geçip dağıtmaktan daha kolay olduğu için bunun yakın zamanda biteceğini sanmıyorum. Her sorun bir Jira projesi ve aşırı karmaşık bir çözüm gerektirmez.
      Ancak büyük şeyleri VBA ile yapmaya tamamen karşıyım. Birkaç hücre değerindeki değişime göre bir sistemin küpünü sorgulayıp başka bir sistemdeki tablo verisiyle birleştiren küçük bir script sorun değil; ama bir noktadan sonra başka bir yere taşınmak gerekir.
      Çoğu proje için, sunucu lisansı olup otomasyon yapılabileceği varsayımıyla Alteryx+Tableau/PowerBI yığınını şiddetle tercih ederim.
    • Açıkçası ben de benzer bir şey yaptım, sonra C#’a geçtim ve şimdi sadece yazılım geliştiriciyim.

  • Analistler için basit bir CRUD arayüzü yapmam gerekiyordu.
    İlk sorun, analistlerin tüm CRUD adımlarını Excel içinde yapmak istemesiydi. Gerçek arayüz Excel olduğundan, Excel içinde çalışabilecek bir şeye ihtiyaç vardı.
    IT departmanı komut satırı erişimine izin vermiyordu, onaylanmamış geliştirme araçlarının kurulumunu da reddediyordu. Onay almak aylar sürebilirdi. Veritabanı yöneticileri mevcut Oracle DB’ye yeni bir DB eklenmesine sıcak bakmıyordu; IT departmanı da doğrudan DB işletmekten hoşlanmıyordu.
    Hatta Excel’e yeni bir eklenti koymak için bile IT görevlisine yalvarmak gerekiyordu. Şanslıysanız bir gün eklenti birden ortaya çıkıyordu; ama bunun bir gün mü, bir hafta mı, bir ay mı süreceği belli değildi.
    Bu yüzden gerçekçi tek alternatif VBA idi ve sonunda analistlerin iki haftada bir kullandığı geçici ama sabit çözümü ayağa kaldırmayı başardık.

  • Bir istihbarat kurumunda çalışırken Afganistan’a konuşlandırılmış kişiler için bir uygulama yapmam gerekiyordu. Kullanabilecekleri bilgisayarlar yalnızca kilitli Windows XP makineleriydi ve yeni bir şey kurmanın yolu yoktu.
    Zaten doğrulanıp kurulmuş Office’e bağlı oldukları için, Linux kullanan biri olarak ben de Office’e bağlı kaldım. Sadece saf VBA ile epey Frankenstein işler çıkarıp iyi geri dönüş aldım.

    • Orta Doğu’ya konuşlandırılmış biri olarak ben de aynı deneyimi yaşadım. Tamamen ağdan ayrılmış XP bilgisayarlarında VBA ile mümkün olan pek çok şeyi otomatikleştirdim.
    • Benzer ama aynı olmayan bir durumda, script etiketine JavaScript kodu koyduğum HTML dosyalarıyla idare etmiştim. Makine ağdan ayrılmış olmasına rağmen IE çalıştırma engelli miydi, yoksa VBA JavaScript’ten daha mı rahattı, merak ediyorum.

  • Kabul edelim, IT modern çağın bürokrasi departmanı; kendi yarattığı sorunlarla %95 meşgul, hizmet odaklılığı ise ancak %5 civarında. Dışarıdan bakan biri için süreçler opaktır ve genelde yardımcı olmaz
    IBM BPM açıklamasında şu kısmı okuyunca gerçekten güldüm; sorunun büyük bölümünü iyi özetliyor
    “IBM BPM’de bir REST API var, ama bu REST API teknik ekipler ve KOBİ’ler için neredeyse işe yaramaz. Bazı REST çağrıları string olarak kodlanmış JavaScript kullanır, bazıları ise XML içinde JSON içinde HTML ister. Veritabanı tabloları adla değil GUID ile sorgulanır. Hangi GUID’in hangi tablo/süreçle ilişkili olduğuna dair dokümantasyon yoktur”
    Pek çok şey saçma derecede karmaşık hâle geldiği için IT dışındaki kimse onlarla uğraşmak istemiyor; bazen IT içinde bile uğraşılmıyor. AJAX’tan itibaren geliştirme eforunun yarısı frontend kodu ve backend servisleri tasarlamaya gitmeye başladı; bunun son kullanıcı otomasyonu sorunuyla aslında pek ilgisi yok. Sonra durum daha da kötüleşti ve bugünün UI’ları modern görünüyor ama onları yapmakta kullanılan teknoloji stack’i kadar kullanıcı düşmanı
    Excel’de UI zaten “orada” duruyor; makro kaydedici denen bir kod üretici de var; IT departmanı da yetkilerimi sorgulamıyor ya da iş problemime yardımcı olmak için zamanı ve bütçesi olmadığını söylemiyor. Bu yüzden VBA, kullanıcıların IT departmanını baypas ettiği bir arka yol. Mükemmel değil ama diğer alternatiflerden daha iyi

    • VBA nihai çevik programlama dili. Şirket IT’si, yani bürokrasi departmanı Scrum, Squad gibi şeylere bağlanmışken, diğer departmanlardaki insanlar Excel/VBA ile işi bitiriyor
      Değişen bir şey yok. Geçen yüzyılda da bu oluyordu ve buna otomasyon adaları deniyordu. O zamanlar çevremde iyi bir strateji olarak görülürdü; departmanların önce kurcalamasına izin verilir, potansiyel görünürse sonra entegre edilirdi
    • Yeterince uzun ararsanız her departmanda kötü örnek bulabilirsiniz. IT’nin yönettiği şeyler arasında akıl almaz seviyeye yaklaşanlar var mı? Elbette var. Ama bu, gölge IT oluşturmak için iyi bir mazeret değil
      Birkaç analistin bir araya gelip kendilerine küçük bir VBA aracı hack’lemesi beni hiç rahatsız etmez. Bu ruh övgüye değer; hatta bunun sonucunda benim günlük işimi daha iyi anlamamı sağlayabilir
      Rahatsız eden şey, bu analistlerin bir noktada sistem mimarimin kendi kişisel projelerine bir şekilde uyum sağlamasını beklemesi. Dokümantasyon isteyince yok; mimari özeti yok; o canavarın repository erişimini isteyince “Repository nedir?” oluyor
      Neden kendi spreadsheet’lerinin benim işleme pipeline’ıma veri enjekte edemeyeceğini soruyorlar; YouTube videosunun yarısını izleyerek öğrendikleri REST kırıntısına göre benim controller yazmam gerektiğini düşünüyorlar. Toplantıda “Kimlik doğrulama gerektiği ne demek? IT neden işleri hep karmaşıklaştırıyor?” sorusu geliyor
      VBA olsun, low-code olsun, ne olursa olsun insanların araç yapması güzel. Ben de aynı şeyi yapıyorum; sadece buna shell script diyorum ve Git repository’sinde tutuyorum. Ama CLI aracımı prodüksiyon sunucusuna salmadığım gibi, bir kez bile code review’dan geçmemiş bir şeyi de öyle bırakmam
    • İlk düzenli yazılım mühendisliği işlerimden biri, bir bankanın trading floor’unda döviz trader’larının yanında oturup çalışmaktı
      Beni işe alan kişi piyasa riski yönetimi başkanıydı; görevi bankanın bir günde çok fazla para kaybetmemesini sağlamaktı. Resmî onaylı IT departmanının kendi algoritma uygulama kodunu doğru yazacağına güvenmediği için beni işe almıştı. Örneğin bir keresinde çarpmanın toplamadan önce geldiğini belirleyen operatör önceliğini anlamadıkları için hata yapmışlardı
      Piyasa riski hesaplamasına tüm işlemlerin girdi olarak verilmesi gerekiyordu; 2000’lerin başı olan o dönemde masanın altındaki PC’ye Apache ve Perl CGI kurup trader’ların işlem girdiği ve pozisyon takip ettiği küçük bir uygulama yaptım. Trader’lar bunu resmî IT çözümünden daha kolay kullanıldığı ve pozisyonları daha rahat gösterdiği için tercih etmeye başladı
      Birçok kurumsal ortamda IT’yi baypas etmenin yolunu bulmak önemli bir yetkinliktir. Excel’e dönersek, trader’lar hesaplama ve simülasyon için Excel kullanıyordu; biz de zaten yaptıkları işi değerlendirmek için Excel’e takılan araçlar sunmaya çalışıyorduk
    • Makalede bunun şirketin açık bir politika kararı olduğunu söyleyen bir cümle var
      “Son kullanıcıların üst düzey programlama dillerine erişmesine izin vermek, şirketin teknoloji stratejisi vizyonuna aykırıdır” deniyor
    • Cevap şu: Çünkü şirketlerin kurmamayı seçemediği tek programlama dili VBA
      “Enterprise” denen şeyin harikası bu. İnsanlar bunu bir avantaj ya da mazeret gibi her öne sürdüğünde şaşırıyorum

  • Yakın zamana kadar iyi bir alternatif olmadığı içindi. Gelecek yeni Office eklentileri modelinde: https://learn.microsoft.com/en-us/office/dev/add-ins/overvie...
    TypeScript hakkında ne derseniz deyin, en azından VBA’dan daha iyi. Ancak VBA’nın aksine doğrudan Excel’in içinde programlama yapılamaması büyük bir sorun. Bazen yeniden kullanılabilir ciddi bir eklenti projesi başlatmak istemezsiniz; sadece o anda bir şeyi düzeltmek için kabaca bir kez çalıştırılacak bir betik istersiniz. Bunu kullanırken Script Lab’i (https://learn.microsoft.com/en-us/office/dev/add-ins/overvie...) öğrendim; belki faydası olur.

    • “VBA’nın aksine doğrudan Excel’in içinde programlama yapılamaması” neredeyse anlaşmayı bitiren bir sebep
      Üstelik ortada bariz bir soru var. Eklentiler, yetkisi olmayan bir kullanıcı tarafından IT departmanı devreye girmeden kurulabiliyor mu? Bir elektronik tabloya gömülebiliyor mu? İlkinin yanıtı “hayır” ise gerçekten ölümcül; ikincisinin yanıtı “hayır” olsa bile benimsenmeyi olumsuz etkiler. Makroların ve VBA’nın avantajı, güvenlik ayarları hariç, her Excel kurulumunun ek kurulum olmadan bunları hemen çalıştırabilmesidir.
    • Yorumun sonundaki Script Lab bahsini görmemişim. Microsoft Script Lab ise tam olarak bunu yapabiliyor: https://www.microsoft.com/en-us/garage/profiles/script-lab/
      Diğer sorun, eklentiyi son kullanıcılarla paylaşmanın basit olmaması. Marketplace’e veya SharePoint’e yayımlamak gerekiyor; sideload için de SMB sunucusu ve GPO gerekiyor. Ancak pek bahsedilmeyen bir seçenek daha var: belgeye dahil ederseniz, ilk açılışta kullanıcı onayından sonra kurulmasını sağlayabiliyorsunuz.
    • Veri girişi veya görselleştirme için şık bir UI göstermek amacıyla iyidir; ama OfficeJS ne yazık ki VBA’nın yapabildiklerinin yarısını bile yapamıyor. Eklenti sisteminde FFI olsaydı sonsuza dek geçiş yapardım
      Bir başka büyük sorun da OfficeJS kullanmak için bir web sunucusu barındırabilmeniz gerekmesi. Genelde son kullanıcıların çoğunda böyle bir erişim yok.

  • VB(A), Python’a benzer. Güzel değildir ama işi görür. Güzel olduğunu düşünüyorsanız, muhtemelen daha iyi alternatiflerin çoğunu bilmeyecek kadar deneyiminiz azdır
    Gerçek işi bitirmenizi sağlayan iyi bir ekosisteme, yani araçlara, kütüphanelere ve entegrasyonlara sahip bir araç kullanışlıdır. Bir masaüstü uygulama geliştirme sistemi olarak Visual Basic, DB avantajlarını da ekleyen MS Access ile birlikte pek çok durumda çok faydalıydı. Bunun ötesine geçecek noktaya geldiğinizde muhtemelen “gerçek” bir çözüme ölçeklemek için paranız da vardı
    VBA tabanlı sistemlerle muazzam paralar kazanıldığına hiç şüphe yok. Finans geliştirmeyi çoğunlukla dışarıdan biri olarak yaptığım deneyime göre, gördüğüm en büyük Excel/VBA yeniden yazımı, 2008 civarında kredi temerrüt takaslarından büyük para kazanan bir şirkete aitti. Yeniden yazımdan önce çalışma kitabının açılması 5 dakika sürüyordu ama VBA ağır işlerin çoğunu yapıyordu. Bilgi sahibi kişiler şirket ve kendileri için primlerle büyük paralar kazanıyordu
    Buradan çıkarılacak ders, aracın ideal olup olmadığından çok, o aracı kullanmak üzere özel olarak eğitilmemiş kişiler için erişilebilir olup olmadığıdır. Python’ın istemci web tarayıcısı dışında 1 numara olmasının nedeni de bu. En iyisi olduğu anlamına gelmez; işi gördüğü ve erişilebilir olduğu anlamına gelir.

    • Python’ın güzel bir dil olduğu savunulabilir; sınıflar ve birinci sınıf fonksiyon desteği olan tam bir dil olmasına rağmen nispeten basit ve erişilebilir
      Ama popülerliğinin tek nedeni bu değil. En sağlam veri bilimi araçlarına sahip olduğu için ezici bir etki yarattı; Django ve Flask gibi makul web framework’leri de var. Pek çok üniversitede Java’nın yerini alarak “ilk öğrenilen dil” haline gelmesi de popülerliğinin artmasının bir nedeni. VBA için durum böyle değil.
    • Python güzel; boşluk kullanım biçiminin süslü parantezler, begin/end, if/else gibi blok gösterme stratejilerinden daha iyi olduğunu düşünüyorum
      Deneyim, güzel olup olmama konusunda öznel bir unsur olduğunu da bilmektir. VBA “zorlu” koşullarda evrildiği için tuhaflıkları bir ölçüde açıklanabilir.
    • Python Scheme değil ama programlama dilleri arasında kesinlikle güzel tarafta ve pek çok durumda daha iyi bir alternatif yok. Bunu onlarca dille yaklaşık 25 yıl programlama yapmış biri olarak söylüyorum.

  • VBA, nesne yönelimli programlamayı destekleyen gayet iyi bir dil. Kalıtım yok ama bileşim mümkün. Excel'e derinlemesine erişip onu denetleyebilir; olgun ve kararlı. Çünkü Microsoft artık onu pek değiştirmiyor
    “Gerçek programcıların” VBA'dan hoşlanmaması çoğunlukla iş birimi çalışanlarının yazdığı amatör işi spagetti VBA kodlarının çok olmasından ve programcılardan zaman zaman bunları debug etmelerinin istenmesinden kaynaklanıyor

    • Karşı argüman olarak, Excel, Word vb.'ye erişip onları denetleyebilmesi dışında VBA berbat bir dil
      Kod içindeki denetim karakterlerinin yerelleştirilmesi gibi tuhaf özelliklerle dolu.[1][2] Kodun İngilizce olmayan kurulumlarda da çalışmasını istiyorsanız, Application.International(xlDecimalSeparator) gibi yer tutucular kullanıp ilgili işleve geçirdiğiniz string'leri dinamik olarak oluşturmanız gerekir; bu da kodun okunabilirliğini ciddi biçimde düşürür. Bu yüzden kod bozulduğunda hata mesajları inanılmaz derecede faydasızdır ve geliştirici bunun VBA'nın olası bir sorunu olduğunu bilmiyorsa yeniden üretmek fiilen imkânsızdır. Yeniden üretmek için arayüz dilini, bilmediğiniz bir dile değiştirmeniz gerekebilir
      En azından Word'de, mevcut paragraftan sonra paragraf eklemek gibi en yararlı işlevlerin yaklaşık yarısı, tablo hücresinin son paragrafında kullanıldığında bozulur; bu yüzden bolca spagetti tarzı dolambaçlı çözüm gerekir
      DOM öğesinin innerHtml özelliğine başvurur gibi birden çok biçimlendirme içeren metin dizelerini alıp vermek istiyorsanız, hacky betik tabanlı seçme ve kopyala/yapıştır kullanmadıkça bu kolay değildir
      Başka bir tartışmada biri Bash ile karşılaştırmıştı; gerçekten katılıyorum. Hiçbir dille karmaşık şeyler yazılmamalı
      [1] https://stackoverflow.com/questions/20652409/using-vba-to-de...
      [2] https://stackoverflow.com/questions/29832281/vba-range-funct...
    • Bir VBA kitaplığı (https://github.com/sancarn/stdVBA) geliştirmeye çok büyük zaman harcadım ve VBA'yı seviyorum; ancak dil üzerinde ciddi kısıt oluşturan gerçek sorunlar var (https://sancarn.github.io/vba-articles/issues-with-vba.html)
      Bununla birlikte, VBA'nın gördüğü nefretin önemli bir kısmının VBA projelerinin durumundan kaynaklandığı da doğru (https://sancarn.github.io/vba-articles/why-is-vba-most-dread...)
    • On Error Resume Next gibi hatalı özellikler içeren bir ortama iyi gözle bakmamak bence adil

  • Excel'i ve elektronik tabloların tamamını düşündüğümüzde, dışarıdan bakan pek çok kişi elektronik tablo dilinin reaktif fonksiyonel programlamayı ne kadar iyi uyguladığını pek anlamıyor. React/Angular'ın 10'dan fazla sürüm boyunca doğru yapmaya çalıştığı şey tam da bu
    Ayrıca birçok kişi son kullanıcılar için elektronik tabloların neden bu kadar kullanışlı olduğunu anlamıyor ve bunun sonucunda gerçekte işleri daha da zorlaştıran daha kötü UI'lar sunuyor
    Bazen bir adım geri atıp, grafik arayüzlerin olmadığı dönemlerde bile eskilerin bazı şeyleri doğru yaptığını anlamak gerekir. İlk zamanlarda da işler yürüyordu ve şirketlerin çoğu zaman ihtiyaç duyduğu şey, tablo biçiminde bir görünüm ve bunun üzerinde reaktif fonksiyon hesapları yapabilme seçeneğidir. Küçük ve orta ölçekli bir işletmede çalışan bir arkadaşınıza sorarsanız doğrulayacaktır

    • Web geliştirmede harcanan emeğin önemli bir kısmı sunuma gider. Sadece veriye ihtiyacınız varsa elektronik tablolardan daha iyisini yapmak zor, buna katılıyorum
    • Excel, bugüne kadar icat edilmiş en iyi son kullanıcı IDE'si olarak görülebilir