Yazılımı Anlamak Üzerine

C++’ın babası olan Bjarne Stroustrup, “The C++ Programming Language” isimli kitabında şöyle der: “Design and programming are human activities; forget that and all is lost.” ya da Türkçesiyle: “Tasarım ve programlama insani işlerdir; bunu unutun, herşey kaybolur. ”

Ben bu cümleyi eskiden bu yana şöyle anlıyorum: Yazılımı tasarlamak olsun, programlamak olsun, öyle uzaylıların yaptıkları işler değildir, tamamen insani faaliyetlerdir, fırıncının ekmeğini yapması gibi ya da futbolcunun futbolunu oynaması ya da bir öğretmenin öğrencilerini eğitmesi gibi, doğrusuyla, yanlışıyla, tamamen insan ve tabi çevresinin işin içinde olduğu faaliyetlerdendir. Eğer bu geçeği unutursak, yazılımı geliştirmeyi, elit, ayrık yani doğal insani ortamından koparılmış gibi ele alırsak, ortada yazılım falan kalmaz. Nitekim üstad bu cümleyi şöyle bir paragrafta söylüyor:

“Too often, we forget the human aspects of system building and consider the software development process as simply ‘‘a series of welldefined steps, each performing specific actions on inputs according to predefined rules to produce the desired outputs.’’ The very language used conceals the human involvement! Design and programming are human activities; forget that and all is lost.”

Yani

“Çok sıklıkla, sistem inşa etmenin insani taraflarını unutuyoruz ve yazılım geliştirmeyi “önceden tanımlanmış kurallara göre girilen verilerden istenen çıktıları üretmek için özel işlemleri yapacak şekilde kurgulanmış, her biri iyi tanımlanmış adımlardan oluşan bir seri” gibi düşünüyoruz. Kullanılan programlama dilinin kendisi, insanın katkısını saklıyor. Tasarım ve programlama insani işlerdir; bunu unutun, herşey kaybolur.”

Evet yazılımı tasarlarken ya da geliştirirken, fildişi kulelerde, her türlü şeyin düşünüldüğü, son derece formal ortamlarda çalışmıyoruz biz. Bakkal Hasan amcanın kendi ortamında bir problemi çözerken kullandığı araçlar ve yöntemlere benzer şeyler kullanıyoruz biz de. Durum Amerikan filmlerinde gördüğümüz şu cümleyle de güzel bir şekilde açıklanabilir: “It is not rocket science!”

Stroustrup’un yukarıdaki paragraftaki şu cümlesi bizim yazılıma sanki uzaydan gelme bir şeymiş, rocket sciencemış gibi davranmamızın sebebini açıklıyor sanırım: “Kullanılan programlama dilinin kendisi, insanın katkısını saklıyor.” Yani kullandığımız programlama dilleri, araçlar, sistemler vs. aşırı karmaşık ve matematiksel yapısından dolayı olayı yani yazılım geliştirmeyi, mistik, kaotik ve esoterik, sadece ehlinin anlayacağı bir iş, olarak görmemize, kurgulamamıza ve dışarıya yansıtmamıza sebep oluyor. Yani yazılımcılar olarak bizler sanki sabah akşam kapalı kapılar ardında, orta çağın büyücüleri gibi, başkalarının gördüğünde “vuuuuuuu, çok etkilendiiimmm” cinsinden laflar söyleyeceği işler yapıyoruz. Halbuki üstad diyor ki, bu bir yanlış anlamadır, kullandığımız dil vb. araçlar böyle bir algı oluşturabilir ama bu yanlıştır. Her insani faaliyet gibi yazılım geliştirme de son derece insanidir. Örneğin şunu diyor Stroustrup:

“…

–  There are no ‘‘cookbook’’ methods that can replace intelligence, experience, and good taste in design and programming.

–  Experimentation is essential for all nontrivial software development.

…

It is easy –  and typically expensive –  to underestimate any of these points. It is hard to transform the abstract ideas they embody into practice. The need for experience should be noted. Like boat building, bicycling, and programming, design is not a skill that can be mastered through theoretical study alone.”

Yani

“…

–  Tasarım ve programlamada insan zekası, tecrübesi ve estetiğinin yerine geçebilecek hiç bir reçete metot yoktur.

–  Deneme – yanılma, basit olmayan her yazılım projesi için asıldır.

…

Bu noktaları gözden kaçırmak kolaydır ve sıklıkla pahalıdır. Soyut fikirleri pratiğe dökmek zordur. Tecrübeye olan ihtiyacımıza dikkat edilmelidir. Gemi inşa etme, bisiklete binme ve programlama gibi tasarım da sadece teorik çalışmayla elde edilebilecek bir yetkinlik değildir.”

Peki neden durup dururken bunlardan bahsediyorum ki? Yazılım ile ilgili olarak çalışırken, tasarlarken ya da programlarken sıklıkla, bağlamımızı aşırı soyut tuttuğumuzu ve bu durumun da problemi anlamakta dolayısıyla da doğru düzgün bir çözüm üretmekte bize sıkıntı çıkardığını görüyorum. Eğer problemimizi bir insani durumun sonucu olarak ele alıp, daha anlaşılır bir ifadeyle, problemimizi yeryüzüne indirip, tamamen günlük hayattan figürlerle ifade edemediğimizde, durumu anlamakta ciddi bir sıkıntıya girdiğimizi hatta doğrudan problemi ıskaladığımızı düşünüyorum.

Ne demek istediğimi size bir örnekle açıklayayım: Yazılımla alakalı kavramları ya da teknikleri anlatırken, bu kavram ve teknikleri ne kadar örneğin benimle çevremdeki insanlar arasındaki ilişkiler ya da iyi bilinen bir filmde resmedilmiş ve akılda kalmış sahne cinsinden ifade edebilirsem, insanların beni o kadar rahat anladıklarını görüyorum. Daha anlaşılır şekilde örneğin, sıklıkla tasarım kalıplarını (design patterns) hem anlatma hem de uygulama durumunda kalıyorum, eğitimlerde ya da danışmanlıklarda. Proxy (vekil) tasarım kalıbını ele alalım mesela. Bu kalıbı, tamamen yazılım kavramları üzerinden anlatmaya çalıştığımda, insanların, yazılımcıların yani, anlar gibi görünmelerine rağmen, gerçekte anlamadıklarını farkediyorum. Nasıl anlıyorum bunu? Onlara bir problem verip bunu az önce anlattığım proxy kalıbıyla çözmelerini istediğimde, yazılımcıların yarısından fazlası çözmekte zorlanıyor. Ama aynı kalıbı buradaki örnekte olduğu gibi, başbakan ve vatandaşlar cinsinden anlattığımda ise aynı kişilerin daha başarılı bir şekilde bu çözümü yeni durumlara uygulayabildiklerini farkettim. Bu durum Stroustrup’un şu cümlesiyle daha rahat anlaşılabilir: “Soyut fikirleri pratiğe dökmek zordur. Tecrübeye olan ihtiyacımıza dikkat edilmelidir. Gemi inşa etme, bisiklete binme ve programlama gibi tasarım da sadece teorik çalışmayla elde edilebilecek bir yetkinlik değildir.”

Evet yazılım soyuttur ama neticede bu dünyadandır ve zihnimizin “benzerlikler üzerinden çalışma” yeteneğinden faydalanarak, soyut olan yapıları somut, elle tutulan ve gözle görülenler cinsinden ifade ederek, daha insani boyuta indirgeyebiliriz. Çünkü proxy tasarım kalıbının çözdüğü şey ile bir insanın bir başka insana örneğin bir avukata vekalet vererek çözdüğü aslında aynı şeydir, aynı problemdir. Tıpkı, visitor (ziyaretçi) kalıbının çözdüğü problemin, örneğin bir evdeki kişilerin hepsinin ayrı ayrı terziye giderek ölçü verip elbise diktirmeye kalkmalarının yarattığı enerji kaybı ve bürokrasiyi ortadan kaldırmak amacıyla, terziyi eve çağırmalarıyla aynı olması gibi.

Tüm bu “insani” yaklaşımlar, problemin kendisini anlamaya yönelik çalışmalardır. Yazılımın soyut bir yapıda olması, yazılımı anlamak ve çözümlemek için tamamen soyut yapılardan hareket etmemizi gerektirmez. En azından problemi tanımlayıncaya ve ona her boyutuyla hakim oluncaya kadar, problemi soyut düzlemden somut ve insani düzleme çekebiliriz. Böyle bir yaklaşım bize daha aşina olduğumuz bir zeminde hareket etme kabiliyeti vereceği gibi “Deneme – yanılma, basit olmayan her yazılım projesi için asıldır.” şeklindeki prensipleri, hem yazılıcıların hem de yöneticilerinin anlamalarını sağlayacaktır.

Üstadlardan öğreneceğimiz çok şey var.

Toplam görüntülenme sayısı: 924