Kırık Cam Teorisi
Yeni bir deste oyun kağıdı aldığınızda kağıtlar sıralıdır. İlk karmanızdan sonra kağıtların sırası bozulur. Peki sırası karışık bir desteyi alıp kardığınızda sıralı hale gelir mi? Muhtemelen hayır.. Üzerinde hiç kafa yordunuz mu bilmiyorum ama evren gerçekten düzensizliği seviyor ve özel bir çaba harcamazsak her sistemi düzensiz hale getirmek için elinden geleni yapıyor. Ludwig Boltzman'ın ortaya koyduğu termodinamik kanununa göre entropi herhangi bir sistemin evrenle birlikte düzensizliğe olan eğilimi demek. Peki entropiye karşı gelerek kurduğumuz sistemleri korumak için ne yapmalıyız?
Amerika'da, şehir merkezindeki bazı binalar gayet iyi durumdayken bazılarının harabe durumunda olmasının gerekçesini bulmak için yapılan araştırmalar ilginç bir tetikleme mekanizmasını ortaya çıkarmış. Bir bina nasıl harabeye döner? Cevap: kırık bir cam ile. Uzun sayılabilecek bir süre boyunca kırık kalan bir cam belli bir süre sonra bina sakinlerinin bilinç altında umursamama etkisi yaratıyor. Daha sonra bir cam daha kırılıyor, binanın boyası dökülmeye başlıyor, birisi sprey boyayla yazılar yazıyor ve bir bakmışsınız ki binanın eski halinden eser yok.
Kırık cam teorisi New York ve diğer büyük şehirlerin polis departmanları tarafından da farkedilmiş ve düzensizlikler henüz küçükken çözüm bulunması (kırık camların onarılması dahil) sorun büyüyünce uğraşmak yerine tercih edilen yöntem olmuş. Bu sayede suç oranlarında önemli düşüş gözlenmiş.
Ve şimdi işin yazılım tarafına gelelim. Fizik kurallarından etkilenmiyor gibi görünen yazılım projelerimiz ne yazık ki entropiden büyük darbe yiyor. Herhangi bir uzun soluklu yazılım projesinde yer alan tasarımcılar bilir ki projede o veya bu şekilde değişiklikler yapmaya başladıkça ürün çabucak çürümeye, kullanılmaz hale gelmeye başlar. Bir örnek verelim.
Müşteriden yeni bir istek gelir, yazılım tasarımcısı: "Yazılımın mimarisini tasarlarken bunu düşünmemiştik. O yüzden küçük bir üçkağıt yapıp koda şunu eklememiz gerekiyor. Evet çok şık olmadı ama ne yapalım." der. Müşteri velinimetimizdir ve gelen istek üzerine kod içerisinde pek hoş olmayan ama küçük sayılabilecek bir değişiklik yapılması uygun görülür. Sonuçta değişiklik ürünün tamamı ile kıyaslandığında çok minik kalacaktır ve göreceli olarak önemsizdir. Koskoca bir binada minik bir cam kırığının önemsiz olduğu gibi.. Daha sonra başka bir istek daha gelir ve başka bir tasarımcı ister istemez bir cam daha kırar. Ürün yavaş yavaş çürümeye başladıkça tasarımcılar üzerinde karşı konulamaz bir umursamazlık oluşmaya başlar. Bir süre sonra mimari bozukluklar sebebiyle yaptığınız bir değişiklik on hata oluşturur. Söz konusu hataları düzeltmek için değişiklikler yaptıkça bu sefer de başka hataların ortaya çıktığını görürsünüz, ve malum son.. Ürünü kurtarmak için artık çok geçtir.
Bu gibi durumlarda yazılım projelerimizi korumak için Refactoring yapabiliriz. Biraz önce verdiğimiz örnekte tasarımcı ürüne yeni özelliği eklemeden önce yazılım mimarisini gerektiği gibi değiştirseydi ve yeni özelliği mimari değişiklik bittikten sonra ekleseydi camı kırmamış olurdu. Tabi başka bir bedeli ödeyerek, refactoring bedelini. Hiç şüphesiz bazı durumlarda hemen yeni özelliği eklemek, örneğin bir saat alabilirken, önce mimari değişikliği yapmak bir hafta sürebilir. Bu durumda şu soruları sormamız gerekiyor "ürünümüz çürümeye terkedilecek kadar değersiz mi?", "Bu değişikliği şimdi yapmayıp zamandan kar edersek ileride daha fazla zaman harcamak zorunda kalır mıyız?" Hiç şüphesiz istisnalar dışında refactoring tercih edilen yöntem olmalıdır.
Refactoring elbette bununla sınırlı değil. Ortada bir değişiklik isteği yokken bile mimaride değişiklik yapmanız gerektiğini düşünebilirsiniz. Bu sayede örneğin bir birim emek harcayarak daha sonrası için on birim emeği ve ürünün kendisini koruyabilirsiniz. Elbette patronunuza gidip "Ürün hazır ve çalışıyor ama bazı yerleri daha iyi olabilirdi. Değiştirmek istiyorum ve en az bir hafta sürer" derseniz o günü mutsuz bitirmenizi sağlayacak şeyler duyabilirsiniz. Belki farklı bir şekilde anlatmayı deneyebilirisiniz. Örneğin "Ürünümüzü minik bir enfeksiyon kapmak üzere olan bir hasta gibi düşünün, bugün tedavi etmezsek daha sonra ameliyat gerekebilir veya daha kötüsü hastayı kaybedebiliriz.." Tabi burada eski bir mühendislik sözünü de hatırlatmakta fayda var "Eğer bozulmamışsa tamir etmeye kalkma" (if it ain't broke, don't fix it). Değişiklik her zaman hata yapma potansiyelini doğurur ve bazı tasarımcılar mümkün mertebe değişiklik yapmaktan kaçınırlar ki bu anlayışla karşılanacak bir davranıştır. İşte tam burada doğru (ama gerçekten doğru) tasarım yapmanın önemi ortaya çıkıyor.
Projelerin yoğunluğu nedeniyle bir çok tasarımcı eğitime gerekli önemi veremiyor veya gereksiz bir özgüvenle herşeyi gayet iyi bildiğini sanıyor. Eğitime gerekli zaman ayıranların çoğu ise sadece programlama dilleri, tasarım araçları vb. konularla ilgileniyorlar.
Farkına varmalıyız ki içerisinde yer aldığımız sektörde var olmak istiyorsak hatrı sayılır miktarda emeği doğru konulardaki eğitimimiz için harcamalıyız.
Amerika'da, şehir merkezindeki bazı binalar gayet iyi durumdayken bazılarının harabe durumunda olmasının gerekçesini bulmak için yapılan araştırmalar ilginç bir tetikleme mekanizmasını ortaya çıkarmış. Bir bina nasıl harabeye döner? Cevap: kırık bir cam ile. Uzun sayılabilecek bir süre boyunca kırık kalan bir cam belli bir süre sonra bina sakinlerinin bilinç altında umursamama etkisi yaratıyor. Daha sonra bir cam daha kırılıyor, binanın boyası dökülmeye başlıyor, birisi sprey boyayla yazılar yazıyor ve bir bakmışsınız ki binanın eski halinden eser yok.
Kırık cam teorisi New York ve diğer büyük şehirlerin polis departmanları tarafından da farkedilmiş ve düzensizlikler henüz küçükken çözüm bulunması (kırık camların onarılması dahil) sorun büyüyünce uğraşmak yerine tercih edilen yöntem olmuş. Bu sayede suç oranlarında önemli düşüş gözlenmiş.
Ve şimdi işin yazılım tarafına gelelim. Fizik kurallarından etkilenmiyor gibi görünen yazılım projelerimiz ne yazık ki entropiden büyük darbe yiyor. Herhangi bir uzun soluklu yazılım projesinde yer alan tasarımcılar bilir ki projede o veya bu şekilde değişiklikler yapmaya başladıkça ürün çabucak çürümeye, kullanılmaz hale gelmeye başlar. Bir örnek verelim.
Müşteriden yeni bir istek gelir, yazılım tasarımcısı: "Yazılımın mimarisini tasarlarken bunu düşünmemiştik. O yüzden küçük bir üçkağıt yapıp koda şunu eklememiz gerekiyor. Evet çok şık olmadı ama ne yapalım." der. Müşteri velinimetimizdir ve gelen istek üzerine kod içerisinde pek hoş olmayan ama küçük sayılabilecek bir değişiklik yapılması uygun görülür. Sonuçta değişiklik ürünün tamamı ile kıyaslandığında çok minik kalacaktır ve göreceli olarak önemsizdir. Koskoca bir binada minik bir cam kırığının önemsiz olduğu gibi.. Daha sonra başka bir istek daha gelir ve başka bir tasarımcı ister istemez bir cam daha kırar. Ürün yavaş yavaş çürümeye başladıkça tasarımcılar üzerinde karşı konulamaz bir umursamazlık oluşmaya başlar. Bir süre sonra mimari bozukluklar sebebiyle yaptığınız bir değişiklik on hata oluşturur. Söz konusu hataları düzeltmek için değişiklikler yaptıkça bu sefer de başka hataların ortaya çıktığını görürsünüz, ve malum son.. Ürünü kurtarmak için artık çok geçtir.
Bu gibi durumlarda yazılım projelerimizi korumak için Refactoring yapabiliriz. Biraz önce verdiğimiz örnekte tasarımcı ürüne yeni özelliği eklemeden önce yazılım mimarisini gerektiği gibi değiştirseydi ve yeni özelliği mimari değişiklik bittikten sonra ekleseydi camı kırmamış olurdu. Tabi başka bir bedeli ödeyerek, refactoring bedelini. Hiç şüphesiz bazı durumlarda hemen yeni özelliği eklemek, örneğin bir saat alabilirken, önce mimari değişikliği yapmak bir hafta sürebilir. Bu durumda şu soruları sormamız gerekiyor "ürünümüz çürümeye terkedilecek kadar değersiz mi?", "Bu değişikliği şimdi yapmayıp zamandan kar edersek ileride daha fazla zaman harcamak zorunda kalır mıyız?" Hiç şüphesiz istisnalar dışında refactoring tercih edilen yöntem olmalıdır.
Refactoring elbette bununla sınırlı değil. Ortada bir değişiklik isteği yokken bile mimaride değişiklik yapmanız gerektiğini düşünebilirsiniz. Bu sayede örneğin bir birim emek harcayarak daha sonrası için on birim emeği ve ürünün kendisini koruyabilirsiniz. Elbette patronunuza gidip "Ürün hazır ve çalışıyor ama bazı yerleri daha iyi olabilirdi. Değiştirmek istiyorum ve en az bir hafta sürer" derseniz o günü mutsuz bitirmenizi sağlayacak şeyler duyabilirsiniz. Belki farklı bir şekilde anlatmayı deneyebilirisiniz. Örneğin "Ürünümüzü minik bir enfeksiyon kapmak üzere olan bir hasta gibi düşünün, bugün tedavi etmezsek daha sonra ameliyat gerekebilir veya daha kötüsü hastayı kaybedebiliriz.." Tabi burada eski bir mühendislik sözünü de hatırlatmakta fayda var "Eğer bozulmamışsa tamir etmeye kalkma" (if it ain't broke, don't fix it). Değişiklik her zaman hata yapma potansiyelini doğurur ve bazı tasarımcılar mümkün mertebe değişiklik yapmaktan kaçınırlar ki bu anlayışla karşılanacak bir davranıştır. İşte tam burada doğru (ama gerçekten doğru) tasarım yapmanın önemi ortaya çıkıyor.
Projelerin yoğunluğu nedeniyle bir çok tasarımcı eğitime gerekli önemi veremiyor veya gereksiz bir özgüvenle herşeyi gayet iyi bildiğini sanıyor. Eğitime gerekli zaman ayıranların çoğu ise sadece programlama dilleri, tasarım araçları vb. konularla ilgileniyorlar.
Farkına varmalıyız ki içerisinde yer aldığımız sektörde var olmak istiyorsak hatrı sayılır miktarda emeği doğru konulardaki eğitimimiz için harcamalıyız.
Yorumlar