En Basit Çözümü Oluşturma Yetisi Nasıl Kazanılır?

Yıllar içinde yazılımcının beyni karmaşık çözümler üretmek için programlanır. Soyutlama yetisi onun müşteri gereksinimi olarak tabir edilen o karmaşanın içinde çabukça şablonlar ve veri yapıları keşfetmesini sağlar. Bu yüksek derecede problem çözme yetisine sahip beyin, kendisinden basit çözümler beklendiğinde, tökezleyip kalır, çünkü programcının gözü yıllarca karmaşık yapılarla uğraşmaktan çok basit çözümleri göremez hale gelmiştir.

Programcı olarak en sık karşılaştığımız problemlerin başında karmaşa nehrinin akıntısında kendimizi kaybederek, doğrudan karşı kıyıya çıkmak yerine, akıntıyla birlikte kilometrelerce aşağıda karşı kıyaya çıkmak, yani beklenenden çok daha çetrefilli çözümler üretmek gelir. Hangi programcıya sorarsanız sorun, iki nokta arasındaki en kısa mesafe nedir sorusuna düz çizgi cevabını alırsınız. Bu çizginin bir ucunun müşteri gereksinimi, diğer ucunun ise programcı tarafından bu gereksinimi tatmin etmek için oluşturulan çözüm olduğunu düşünürsek, programcılar tarafından oluşturulan çoğu çözümün bir çizgi değil, poligon veri bir yapı olduğunu görebiliriz.

Bu madalyonun bir yüzü. Diğer bir yüzü de programcının müşteri gereksinimini anlamadığı durumda nasıl çözümler ürettiği ile ilgilidir.

Kulak misafiri olduğum bir beyin fırtınası seansından örnek vermek istiyorum. Üç senior programcı bir araya gelerek, muallakta kalmış bir müşteri gereksinimi hakkında çözüm üretmeye çalışıyorlar. Ortaya kapsamlı bir çözüm çıkartıyorlar. Akla gelebilecek bilumum senaryolar bu çözümün bir parçası. Kısa bir zaman sonra müşteri ile iletişimi koordine eden yönetici geliyor ve bu çözümün gereğinden fazlasını kapsadığını, müşteri gereksiniminin çok daha basit bir çözümle tatmin edilebileceğini söylüyor. Hatta if/else ihtiva eden sözde kod (pseudocode) oluşturarak, çözümün basitliğine işaret ediyor. Akabinde programcılardan gerçekten böyle basit miymiş gibi söylemler işitiyoruz.

Bu üç programcının müşterinin ne istediğini tam olarak bilmemeleri ve mümkün olan en kapsamlı çözümü oluşturmaya gayret etmeleri, onların gereğinden çok daha karmaşık bir çözümü ortaya koymalarına neden oldu.

İki boolean değişkeni parametre olarak kabul eden bir metot düşünelim. Programcı olarak bu metot gövdesinde dört değişik kombinasyonla baş etmek zorundayız. Parametre sayısı üçe çıktığında, kombinasyon sayısı sekize çıkar. Programcıların çözüm üretirken uyguladıkları düşünce tarzı ne yazık ki metot örneğinde parametre sayısını azaltmak yerine, metodun kabul ettiği parametre sayısını artırma yönündedir. İç güdüsel olarak mümkün olan en geniş kapsamlı çözüme kavuşabilmek için her türlü değişkene değer atayarak, kullanılırlar. Her değişken mümkün olan ama gerekli olup, olmadığı tam olarak bilinmeyen bir senaryo ya da senaryonun bir parçasıdır. Değişken sayısı arttıkça, oluşturulmaya çalışılan çözümün karmaşası ve kapsama alanı artar. Belli bir parametre sayısından sonra beynin o karmaşaya hakim olması ve çözüm üretmesi mümkün değildir. Daha az parametre kullanarak çözüm bulmak zaruri hale gelir. Daha az parametre demek, çok daha basit bir çözüm ortaya koymak demektir. Basit çözüm demek KISS prensibini uygulamak demektir.

KISS prensibi mümkün olan en basit çözümü uygulamanın gerekliliğini ifade etmektedir. Bu çözümü oluştururken müşterinin yerine kafa yormak yerine, onunla birlikte çözüme ulaşmak için kafa yormak daha gerçekçi ve müşteri tarafından kabul gören bir çözümün oluşmasını kolaylaştıracaktır.

KISS prensibi en basit çözümü tercih etmemizi söylemektedir. Bu çözüme ulaşmak için kullanabileceğimiz iki yöntem bulunmaktadır. Bunlardan birincisi böl ve yönet yöntemedir. Büyük bir problemle uğraşmak yerine, o problemi daha küçük parçalara bölerek, alt problemler için çözümler oluşturabiliriz. Bu çözümler bir araya geldiğinde büyük problemin çözümünü oluştururlar.

Bir diğer yöntem ise çevik süreç olan Extreme Programming’in sahip olduğu Travel Light prensibidir. Az yükle yolculuğa çıkmak, seyahat esnasında yüke değil, yolculuğun kendisine konsantre olunmasını kolaylaştırır. Az yük daha hızlı yol katedilmesini sağlar. Hızlı yol alabilmek, neticelerin somutlaşmasını ve müşteri ile olan diyaloğun oluşturulan prototipler aracılığı ile kıymetli geri bildirimler doğurmasını sağlar. Hızlı yol alabilmek için mümkün olan en basit çözüm ile başlanarak, müşteriden gelen geri bildirim yardımı ile bu genel çözümü daha spesifik hale getirmeye çalışılmalıdır.

Genel bir çözümü müşteri gereksinimleri doğrultuşunda daha spesifik hale dönüştürürken, kod bakımı ve geliştirilmesinin her zaman kolay olması gerektiği konusundaki hassasiyet yitirilmemelidir. Tasarım prensipleri bu konuda yol gösterici olma niteliğini taşımaktadırlar. Örneğin Open Closed prensibi (OCP) kod değişikliği yapmadan uygulamaya yeni davranış biçimleri eklemeyi mümkün kılmaktadır. Stratejik kapama yöntemi uygulandığında uygulamanın gelecekte meydana gelebilecek değişikliklere karşı direnci artırılabilir.

Mümkün olan en basit çözümü oluşturmak için kullanabileceğimiz metotların başında test güdümlü yazılım gelir. Test güdümlü yazılım programcıdan her test için en basit implementasyonu oluşturmasını ister. Her yeni test ile implementasyon yeniden yapılandırma (refactoring) teknikleri kullanılarak yoğrulur ve test için gerekli yapının oluşması sağlanır. Oluşan yeni yapı da en basit çözüm prensibi ile uyumludur. Programcı sadece üzerinde çalıştığı testi tatmin edecek kadar kod yazar. Bu açıdan bakıldığında programcılar en basit çözümü oluşturmak için gerekli disiplini test güdümlü yazılım yaparak edinebilirler.

EOF (End Of Fun)
Özcan Acar