Prof. Dr. Ali Hikmet Doğru

Hepimiz programlamayı öğrenirken önce bir zorlanırız. Sonra bu zorluklar yerlerini yavaş yavaş bir tatmin ve güçlenme duygusuna terk etmeye başlar. Programlama yetkinliğimiz arttıkça özgüvenimiz de artar ve dünyanın her türlü problemini çözebileceğimiz doğrultusundaki bir gelişmeye doğru yönelir. Ancak, yazdığımız programlar büyüdükçe büyür ve eğer başından beri profesyonel bir ortamda yönlendirilmiyorsak, çok gecikmeden duvara çarparız: Yordamsal bir karmaşıklık olmadığı halde programın büyüklüğü sonunda hatalarımızla başa çıkamaz bir duruma geliriz ve ‘sistemimizi’ bir türlü tam düzgün çalışır bir konuma getiremeyiz.

Çok hızlı kod yazıyorsak, bir hafta sonunda bir iki bin satırlık bir programı oluşturabiliriz. Ancak bunun iki katı büyüklüğe çıkabilmesi için haftalar, belki aylar geçecektir. Genelde belimizi büken gerçek, ‘geliştirme karmaşıklığı’nın büyüklük ile üstel bir bağlantı ile artış göstermesidir. Diğer taraftan 1970’lerde binlerce satır büyüklükler yeterli olurken, şimdi piyasada 100 M (yüz milyon) satır sayısı üzerinde birçok projenin bulunması doğal bir olgu haline gelmiştir. Programcılığın dışında yaklaşımlar ile bu canavarın yönetilmesi gerekmektedir. Yazılım mühendisliği alanı, bazen ümitsiz gibi görünebilen bu görevi üstlenmiştir. 1650’lerde başladığını sayabileceğimiz bugünkü anlamda programcılık, ve daha sonraları onu destekleyen mühendislik yaklaşımları ile yapılan ‘geliştirme’, doğal olarak bir değişim macerası yaşamıştır. Hep birlikte bu maceranın ilginç, hissedilen, fakat tam olarak hepimizin isimlendirmediği bir özelliğine bakalım…

On kapı bugün, yüz kapı haftaya

Bir zamanlar inşaat sektörümüzde kullanılmış bir reklam kampanyasından alınma sözler... Artan ihtiyacı karşılamak için ‘doğrusal’ın üzerinde geliştirme kapasitesi artımlarına gereksinimimiz vardı. Bu da tıpkı zamanındaki telefon santrallerinde insan operatörleri kullanımı yerine otomasyona geçilmesi gibi bizim sahamızda da otomasyona geçilmesi gereğini ortaya koymuştur. Önceleri programlama dillerinde kavram düzeyini arttırarak yeni diller icat edildi. Daha sonra programlama düzeyinin üzerinde, gerekli etkinliklerin organizasyonu için süreç modelleri düzeyinde mekanizmalar bulundu. Hatta, kodlama dahil, insanın yapacağı işleri otomatik olarak yapacak araçlar geliştirildi. Günümüzde, otomatik kod üretme kabiliyetinin yaygınlaşması ve oturması süreçlerini yaşamaktayız.

Programlama etkinliğinin üzerinde farklı teknikler bugün can alıcı yazılım mühendisliği uğraşları olarak karşımıza çıkmaktadır. Farklı coğrafyalarda farklı isimlerle bu tür kabiliyetler kurumsallaşmaya doğru gitmektedir. Örneğin, Avrupa’da ‘compositional’ (birleştirimsel) yaklaşımlar terminolojisi kullanıldı. Yeni yöntemler, büyük sistemlerin daha az program yazarak geliştirilmesini hedeflemekte idi. Bunlara örnek olarak:

• Model güdümlü geliştirme (Model Driven Development),
• İlgiye Yönelik Geliştirme (Aspect Oriented Development),
• Bileşene Yönelik Geliştirme (Component Oriented Development) ve
• Servis Odaklı Mimari (Service Oriented Architecture) verilebilir. Önemli olan, gereksinim ortaya konduktan sonra çok kısa sürede çok büyük yazılım ürününün hazır edilmesidir – bu hedefe varmak için yeni kod üretiminin olduğu kadar, mevcut kod parçalarının bulunup birleştirilmesi de geçerli bir tekniktir.

Tekerleğin yeniden bulunması

Hızlı geliştirmenin bir yolu, yazılmış kodların bulunup birleştirilmesidir: Büyük bir proje, bileşenlerden oluşturulabilir ve yeni program yazımı işi çıkmadan, yalnızca tümleştirme çabası ile geliştirilebilir. Daha önce yazılmamış bir algoritma düşünebiliyor musunuz? Özel durumlarda yeni kodlama tabi ki yapılacaktır. Hele uyarlama, ‘yeniden kullanılabilirlik’ konusu dile getirildiğinde hemen akla gelen bir konudur. Ancak, ‘katı’ mühendislikler bu problemi çoktan çözmüşler ve yeni ürün tasarlanırken önceden geliştirdikleri yapı taşlarını kullanmakta ve ürünün her ayrıntısını sıfırdan üretmemektedirler. Yazılım endüstrisinde ise özellikle daha az deneyimle işe başlayanlar, ucuz olacak ya da tamamen kontrolümüzde olacak savları ile her satırı baştan yazmaya eğilimli olurlar. Halbuki, kullanılabilecekleri ‘parçalar’ makul fiyatlara satın alınabilecek şekilde pazardadırlar. Genelde ise sıfırdan geliştirmek daha pahalıya mal olmaktadır.

Uzun dönemde, bir program biriminin ilk başta düzgün çalışması yanında, güvenilirliği, bakım kolaylığı gibi işlevsel olmayan ancak nitelikle ilgili yönleri öne çıkar. Toplam maliyeti de bu etkenler daha fazla belirler. Dolayısı ile, yeni yazılacak kod, diğerlerine göre daha fazla risk taşımaktadır ve pahalıdır.

Program yazamayacak mıyım?

Bu yazıda çizilen tablo, artık programcılığa gerek kalmayacağı, programların bir şekilde otomatik olarak üretileceği şeklinde belirebilir. Ya her türlü programcık yazılmıştır, yeni ürün için bunlar akıllı yöntemlerle bulunup tümleştirilecektir, ya da üst düzeyde bir grafik ortamda yapılacak belirtim, otomatik olarak koda dönüştürülecektir. Bu yaklaşımlar, azımsanmayacak bir oranda ticari yazılım üretimine imzalarını atmaktadırlar. Çoğumuzun karşısına çıkmış olabilecek olan grafik ara yüzü örneğini ele alırsak, sürükle bırak işlemleri ile tanımladığınız bir ara yüz, programınızın parçası olarak çalışabilmekte ama bu masum çizim parçacıklarının ne tür kodlara otomatik olarak dönüştürüldüklerini biliyor muyuz?

Bir de kişisel hatıra. Öğrencilik çağlarımdan beri, günümün hatırı sayılır bir kısmını program yazmaya ayırarak hocalık dönemime kadar geldim. Sonraları, vaktimin çoğunu sözünü ettiğim tekniklerin geliştirilmesi için ayırır oldum. Derken bir gün, eskiden hayat tarzı olduğu gibi, aklıma gelen bir sorunun çözümünü bulmak için bir program yazma planı çok doğal olarak gündemimde belirdi. Bilgisayarıma uzandım ve yeni bir dilin derleyicisini aradım, yoktu. Diğer olası birkaç derleyici arayışım da hüsran ile sonuçlandı! Eskiden, işletim sistemimiz, bir de küçük BASIC derleyicisi içerirdi. Onun da artık yeni sistemlere dahil edilmediğini gördüm. Yani ben, derleyicisiz program yazıp deneyemeyecek bir durumda idim! Durumu kabullenmekte zorlanmıştım. Sonra kontrollü olarak, kendimi kaptırmadan da olsa biraz kodlamaya dönmeyi ihmal etmedim. Kendi hikayemi dünyada gelişen teknolojik eğilimi anlatmak üzere bir örnek olmak için değil de, program yazamayacak olma ile ilgili bir psikolojiyi sunmak için aktardım.

Robotlar dünyasında insan

Cevap, daha genel bir konu olan otomasyon sonucunda insanların yapacağı işlerin etkilenmesi ile ilgilidir. Büyük yazılım projelerinin ön adımlarındaki bir sorun, otomasyon projesinin insanların işlerinin yerine geçeceği ve iş kaybı endişesi ile karşılaşılmasıdır. Bu da doğal olarak projelerin başarısını etkilemektedir. Sosyal boyutu ile birlikte ele alınmış bir otomasyon projesi, önceden niteliksiz işlerde çalışan elemanlarının, proje sonunda eğitim de görüp daha nitelikli işler yapması ile sonuçlanmalıdır. Bu sonuç herkesi mutlu edecektir. Felsefi açıdan bakıldığında, büyük risklerin de bulunmasına karşın, yaygın otomasyon tüm insanlığın daha az ve daha zevkle çalıştığı fakat daha çok kazandığı bir ortamı hazırlıyor olsa gerek.

Geçmiş evrimimizden bir örnek: Hesap makinaları yaygınlaştı, ama ‘’gelin çarpım tablosunu artık öğrenmeyelim’’ demedik. Profesyonel hesaplamalarımızda elden geldiğince bu tür araçları kullansak da, çarpma yapmasını biliyoruz. Programlama da bileceğiz. Her ne kadar endüstriyel program üretimi daha çok robotlar tarafından üretilecek olsa da. Bir kayda değer gelişme, programcılığın daha üst düzeyde, daha etkin ve belki daha zevkli olarak yapılması olacaktır.

Zevkli programlamalar dileyerek ayrılıyorum.