Bir Excel Tablosuyla Başlayan Hikâye

Grafirio Geliştirme Günlüğü — Bölüm 1

Bazı projeler büyük bir fikirle başlar. Benimki ise yıllar önce önüme gelen Excel raporlarına bakarken başladı. Yöneticilik yaptığım dönemlerde şirketin durumunu anlamak için pek çok rapor inceliyordum. Satırlar, sütunlar, rakamlar... Hepsi bir şey anlatıyordu ama benim istediğim, o rakamların ne söylediğini daha hızlı anlayabilmekti.

Excel'e karşı özel bir düşmanlığım yoktu. Hatta oldukça güçlü bir araç olduğunu düşünüyordum. Fakat bir şirketin satışlarının nasıl gittiğini, üretimin artıp artmadığını veya geçen aya göre neyin değiştiğini anlamak için sürekli tablolar arasında dolaşmak bana yorucu geliyordu. Ben bu bilgileri grafiklerde görmeyi seviyordum. Zaten o dönem kendi küçük projelerimde dashboard hazırlamak da hoşuma gidiyordu.

Bir süre sonra aklıma başka bir soru takıldı: Bunu yalnızca kendim için değil, bir fabrika sahibi için de yapabilir miydim? Sabah telefonunu açtığında fabrikasının durumunu görebilse, üretimini ve cirosunu takip edebilse nasıl olurdu? Üstelik bunu yaparken SQL bilmesine veya veritabanının nasıl tasarlandığını anlamasına gerek kalmasa...

Fikir güzeldi. Fakat yazılımcı olmanın kötü bir tarafı var: Bir fikri düşündükten hemen sonra onu nasıl geliştireceğinizi de düşünmeye başlıyorsunuz. Ben de çok geçmeden ilk problemle karşılaştım. Her fabrikanın kullandığı yazılım ve veritabanı birbirinden farklıydı.

Her müşteriye ayrı yazılım mı geliştireceğim?

İlk düşündüğüm çözüm, fabrikaların mevcut sistemleriyle konuşabilecek bir ara yazılım geliştirmekti. Bu yazılım fabrikanın veritabanına bağlanacak, ihtiyaç duyulan bilgileri alacak ve hazırladığım dashboard'a gönderecekti. Böylece fabrika sahibi, mevcut yazılımını değiştirmeden benim hazırladığım ekranları kullanabilecekti. Kâğıt üzerinde oldukça mantıklı görünüyordu; sonuçta benzer entegrasyonlar yazılım dünyasında yıllardır yapılıyordu. Ancak işin içine farklı müşteriler girdiğinde durum değişiyordu. Bir fabrikanın veritabanında satış bilgileri üç tabloda tutulurken başka bir fabrikada aynı bilgiye ulaşmak için bambaşka ilişkiler kurmak gerekebiliyordu. Üstelik mesele yalnızca tablo isimlerinin farklı olması değildi. Her şirketin kendine özgü iş kuralları vardı. Birinde ciro hesabına dahil edilen bir işlem, başka birinde farklı değerlendirilebilirdi. Dolayısıyla her müşterinin veritabanını ayrıca incelemek, sorguları hazırlamak ve entegrasyonu test etmek gerekecekti.

Bir noktada kendime şu soruyu sordum: Ben gerçekten bir ürün mü geliştiriyorum, yoksa her yeni müşteri için yeniden yazılım geliştireceğim bir iş mi kuruyorum? Çünkü ilk müşteriye özel entegrasyonu hazırladıktan sonra iş bitmeyecekti. Veritabanı değiştiğinde sorguların güncellenmesi gerekecek, yeni ihtiyaçlar ortaya çıktığında yeni geliştirmeler yapılacaktı. Müşteri sayısı arttıkça bakım yükü de büyüyecekti. Henüz ortada çalışan bir ürün yokken gelecekte uğraşacağım sorunları düşünmeye başlamıştım. Benim istediğim şey, her fabrikaya özel entegrasyon yazmak değildi. Farklı veritabanlarını anlayabilen ve bu verilerden anlamlı raporlar oluşturabilen ortak bir sistem geliştirmekti. Tabii bunu söylemek, nasıl yapılacağını bildiğim anlamına gelmiyordu. O dönemde elimde bu problemi çözebilecek bir yöntem yoktu. Dolayısıyla fikir bir süre kafamın bir köşesinde kaldı.

Öğrenmek için başladığım başka bir proje

Bu süreçte mesleki olarak farklı konulara yönelmeye başlamıştım. Özellikle yazılım mimarisi ilgimi çekiyordu. Clean Architecture, mikroservisler, servisler arası iletişim ve farklı sorumlulukların birbirinden ayrılması gibi konuları daha iyi anlamak istiyordum. Bir konuyu yalnızca okuyarak öğrenmek bana pek yeterli gelmiyor. Özellikle mimari konularda örnekleri incelemek faydalı olsa da işin içine girip bir şeyler geliştirmediğiniz sürece bazı problemleri göremiyorsunuz. Bu nedenle öğrendiklerimi uygulayabileceğim bir proje hazırlamaya karar verdim ve mikroservis tabanlı bir e-ticaret sistemi geliştirmeye başladım. İçerisinde satın alma işlemlerinin de bulunduğu çeşitli modüller vardı. Eğitim kaynaklarından yararlanıyor, örnekleri inceliyor ve bazı bölümleri kendi yaklaşımımla geliştiriyordum.

Burada önemli bir ayrıntı var: Bu proje başlangıçta Grafirio değildi. Hatta Grafirio'ya dönüşmesi için hazırlanmış bir altyapı da değildi. Tamamen mimari konuları öğrenmek amacıyla geliştirdiğim bir deneme projesiydi. Zaman içerisinde servislerin nasıl haberleştiğini, sorumlulukların nasıl ayrıldığını ve farklı bileşenlerin birlikte nasıl çalıştığını daha iyi anlamaya başladım. Bir yandan da yıllardır aklımda duran dashboard fikri ara sıra kendini hatırlatıyordu. Henüz iki projeyi birleştirmiş değildim. Ancak daha sonra Grafirio'yu geliştirmeye başladığımda bu eğitim projesinde hazırladığım yapıdan yararlanabileceğimi fark edecektim.

Bir veritabanını anlamak neden bu kadar zor?

Yazılım geliştirirken karşılaştığım başka bir problem de bu fikrin yeniden gündeme gelmesine neden oldu: Karmaşık veritabanları. Yıllar içerisinde farklı veritabanlarıyla çalıştım. Bazılarının yapısı oldukça düzenliydi. Tabloların isimlerinden ne işe yaradıklarını anlayabiliyor, ilişkileri rahatlıkla takip edebiliyordunuz. Bazılarında ise durum tam tersiydi. Bir bilgiye ulaşmak için önce hangi tabloda tutulduğunu bulmanız, ardından o tablonun diğerleriyle ilişkisini çözmeniz gerekiyordu. Üstelik bazen alan isimleri bile ne anlama geldiklerini açıklamıyordu. Yazım hataları, tutarsız isimlendirmeler ve karmaşık ilişkiler işi daha da zorlaştırıyordu.

Bu tür veritabanlarında SQL yazmak bazen problemin en kolay kısmı olabiliyor. Asıl mesele, hangi verinin neyi temsil ettiğini anlamak. Yanlış ilişkiyi kurduğunuzda sorgu sorunsuz çalışabilir ama döndürdüğü sonuç yanlış olabilir. Daha kötüsü, sorgu hata vermediği için yanlışlığı hemen fark etmeyebilirsiniz. Böyle durumlarda veritabanını daha önce geliştirmiş birine soru sormak veya mevcut kodları inceleyerek iş kurallarını anlamaya çalışmak gerekebiliyor. Bu da zaman alıyor.

Bir gün bu problemle yıllardır aklımda duran fikir arasında bağlantı kurdum. Fabrikalar için hazırlamak istediğim sistemin önündeki en büyük engel, veritabanlarının birbirinden farklı olmasıydı. Ben ise günlük işlerimde zaten bu farklılıkları anlamaya çalışıyordum. Peki bu işi bir yazılıma yaptırabilir miydim? Daha önce hiç görmediği bir veritabanına bağlanan, tabloları inceleyen, ilişkileri keşfeden ve hangi alanın ne anlama geldiğini öğrenebilen bir sistem geliştirmek mümkün müydü?

O dönemde büyük dil modelleri giderek daha fazla konuşuluyordu. Bu modellerin doğal dili yorumlama ve kod üretme yetenekleri dikkatimi çekiyordu. Ancak benim ilgimi çeken şey yalnızca yapay zekâya SQL yazdırmak değildi. Asıl merak ettiğim, veritabanının yapısını anlayıp anlayamayacağıydı. Eğer tabloların ne işe yaradığını ve birbirleriyle nasıl ilişkilendiğini anlayabilirse her müşteri için sıfırdan entegrasyon geliştirme ihtiyacını azaltabileceğimi düşünüyordum.

Fikrin projeye dönüştüğü nokta

Yapay zekânın veritabanlarını anlamak ve analiz süreçlerini otomatikleştirmek için kullanılıp kullanılamayacağı konusunda hâlâ bazı şüphelerim vardı. Kafamdaki fikir güzeldi ama bunun gerçekten uygulanabilir olup olmadığından emin değildim. Bu nedenle üniversitede doçent olarak görev yapan bir arkadaşımla konuyu detaylıca değerlendirmeye başladık. Yapay zekânın hangi işlemleri üstlenebileceğini, hangi aşamaların otomatikleştirilebileceğini ve karşılaşabileceğimiz teknik problemleri konuştuk. Bu görüşmeler sonucunda fikri yalnızca tartışmakla kalmayıp nasıl geliştirebileceğimize ilişkin bir yol haritası oluşturduk.

Aslında Grafirio'yu gerçekten geliştirmeye karar verdiğim nokta burasıydı. Daha önce aklımda bir fikir vardı ve bu fikri hayata geçirmek için farklı yöntemler düşünüyordum. Ancak artık üzerinde çalışabileceğim somut bir plan bulunuyordu. Mimari konuları öğrenmek için geliştirdiğim mikroservis altyapısını bu plana göre uyarlamaya ve Grafirio'nun ihtiyaç duyacağı bileşenleri geliştirmeye başladım. Elbette bütün soruların cevabını bulmuş değildik. Fakat artık neyi deneyeceğimi ve hangi problemleri çözmeye çalışacağımı biliyordum.

Geliştirme süreci ilerledikçe bu kez altyapı problemiyle karşılaştım. Birden fazla servisi çalıştırmak, veritabanlarını yönetmek ve uygulamayı kendi bilgisayarımın dışında erişilebilir hâle getirmek için sunucu kaynaklarına ihtiyacım vardı. Üstelik bu kaynakları yalnızca uygulamayı yayımlamak için değil, geliştirme ve test süreçlerinde de kullanmam gerekiyordu. Kendi imkânlarımla bunu sürdürülebilir biçimde karşılamak kolay görünmüyordu. Bunun üzerine projeyi bir sunuma dönüştürerek Microsoft'la iletişime geçtik. Görüşmeler sonucunda Azure üzerinde kullanabileceğim kaynak desteği sağlandı. Bu bir nakit yatırım değildi; doğrudan altyapı ihtiyacımı karşılamaya yönelik bir destekti.

Azure desteğiyle birlikte geliştirdiğim servisleri bulut ortamına taşımaya başladım. CI/CD süreçlerini hazırladım ve uygulamanın dağıtımını gerçekleştirdim. Kullanıcıların sistemle etkileşime geçebilmesi için bir web arayüzü de gerekiyordu. Frontend benim ağırlıklı uzmanlık alanım olmadığı için bu tarafta yapay zekâ araçlarından yararlandım. İlk arayüz oldukça basitti ama artık üzerinde çalıştığım fikri yalnızca kod seviyesinde değil, çalışan bir uygulama olarak da deneyebiliyordum.

Bir fikrin ilk çalışan hâli

İlk web arayüzünü hazırlayıp servisleri Azure üzerinde çalıştırdığımda, yıllardır aklımda dolaşan fikir ilk kez somut bir uygulamaya dönüşmüştü. Elbette önümde hâlâ çözmem gereken çok problem vardı. Ama başlangıçta yalnızca Excel raporlarına bakarken düşündüğüm şeyin, bir gün gerçekten geliştirdiğim bir uygulama olması benim için önemliydi.

Artık mesele Grafirio'yu yapıp yapamayacağım değil, onu ne kadar doğru geliştirebileceğimdi. Bunun cevabını ararken de yapay zekâya verdiğim sorumlulukları yeniden düşünmek zorunda kalacaktım.