Pragmatik Programcı — 3

Pragmatik programcı notlarımın devamıdır.

Yazılım Düzensizliği

Bir yazılımdaki düzensizliğin artmasını “Software Rot” yani yazılım çürümesi olarak isimlendiriyoruz. Daha iyimser hali olarak “Technical Dept” yani teknik borç tabirini kullanıyoruz. Bu tabir ile aslında bir gün bu borcu ödeyeceğimizi ima ediyoruz. Muhtemelen çoğu durumda ödenmeyecek.

Ne şekilde kullanılıyor olursa olsun, çürüme ya da borç kontrolsüz bir şekilde yayılabiliyor.

Bazı projeler düzenli bir şekilde devam etmesine hatta ekibin çok kaliteli olmasına rağmen çürüme olabiliyor. Bazı projeler ise bütün zorluklara ve aksiliklere rağmen düzensizliklerle çok iyi mücadele ederek oldukça başarılı bir şekilde ortaya çıkabiliyor.

Peki bu nasıl mümkün oluyor?

Araştırmacılar bir yerdeki düzensizliğin başka düzensizlikleri tetiklediğini keşfediyorlar.

Bir kırık pencere uzun bir süre tamir edilmezse, o civarda yaşayan sakinlere mekanın terk edildiği izlenimini verir. Yetkililerin orayı umursamadığı hissini doğurabilir. Dolayısıyla bir başka pencere kırılabilir, insanlar çöplerini atabilir, duvarlarına resimler karalayabilir. O mekan, sahibinin isteği dışında onarılmayacak derecede hasar görür ve terkedilmişlik hissi gerçekleşir.

Psikologların yaptığı araştırmaya göre umutsuzluk bulaşıcı olabilir. Bozuk olarak bırakılmış şeyler, hiçbirşeyin düzeltilemeyeceği, kimsenin umursamadığı ve kaderine terk edildiği izlenimini pekiştirir. Takımda bu tarz negatif duyguların yayılması kısır bir döngüye sebep olur.

İpucu: Küçük sorunları (kırık pencere) görmezden gelerek yaşamayın

Kötü kodu, kötü tasarımı, yanlış kararları düzeltmeden bırakmamalıyız. Fark edilir edilmez bunları düzeltmeliyiz. Eğer hemen düzeltmeye zamanımız yoksa, bunu en öncelikli yapılacaklar listesine eklemeliyiz. Hasar giderek büyümeden aksiyon almalıyız.

Çok temiz koda, düzgün fonksiyonaliteye sahip sistemlerin bile küçük olarak görülen sorunların olduğu gibi bırakılmasıyla çürümeye başladığı, teknik borçların arttığı görülebilir. İhmalkarlık bu süreci hızlandırır.

Bir kırık pencere kodun tamamının bozulmaya başlaması için yeterlidir. Böyle bir projede çalışınca çoğu kişi genelde “Zaten kod temiz değil, temiz yazmaya çalışmanın önemi de yok.” gibi düşünerek projenin zamanla yönetilemez bir boyuta gelmesine neden olur.

Tam tersi, çok temiz yazılmış bir projede ise çoğu kimse bu düzeni devam ettirmek, temiz, anlaşılır yazmak için ekstra gayret sarfeder.

• Projede birkaç kırık pencere bulup, ekip arkadaşlarımızla sorunun ne olduğu ve nasıl düzeltilmesi gerektiği konusunda tartışabiliriz.

Taş Çorbası

Bu bölümde kitaptaki bir hikaye ile devam edelim. Bu hikaye yapılması gereken bir şeyi yapmak için karşılaşabileceğimiz bir zorluğu nasıl aşabileceğimize güzel bir örnek olabilir. Takımda nasıl sinerji oluşturabileceğimiz ve insanları bizim gördüğümüz, ortaya çıkacağına inandığımız bir şeye nasıl dahil edebileceğimizi çok güzel anlatıyor:

Üç asker savaştan eve dönüyormuş ve yolda aç kalmışlar. Bir süre sonra ileride bir köy görmüşler, bu da morallerini biraz olsun düzeltmiş. Çünkü köylülerin onlara yemek vereceğinden neredeyse eminlermiş. Ancak köye vardıklarında kapıların kilitli, pencerelerin ise kapalı olduğunu görmüşler. Yıllarca süren savaş nedeniyle köylüler yiyecek sıkıntısı çekiyor, ellerindekini ise saklıyorlarmış.

Askerler yılmadan bir tencere su kaynatmış ve içine dikkatlice üç taş koymuşlar. Köylüler, şaşkınlık içinde dışarı çıkıp askerleri izlemeye başlamışlar.

“Bu taş çorbası,” demiş askerler.

“Yalnızca taş mı koyuyorsunuz?” diye sormuş köylüler.

“Kesinlikle, ama bazıları birkaç havuç eklersek daha lezzetli olduğunu söyler…”

Bir köylü hemen koşarak sakladığı havuçlarla dolu sepetiyle geri dönmüş. Birkaç dakika sonra köylüler tekrar sormuş:

“Bu kadar mı?”

“Şey,” demiş askerler, “Biraz patates çorbaya daha iyi bir kıvam katacaktır.”

Bir başka köylü koşarak patates getirmiş. Sonraki bir saat boyunca askerler, çorbayı daha da güzelleştirecek malzemeleri sıralamışlar: et, pırasa, tuz ve otlar. Her seferinde başka bir köylü depolarından malzeme getirmiş. Sonunda büyük bir tencere dolusu buharı tüten çorba hazırlanmış. Askerler taşları çıkarıp, köydeki herkesin yediği ilk doyurucu yemeği hep birlikte paylaşmışlar.

Taş Çorbası hikâyesi birçok önemli ders içerir. Askerler, köylüleri kandırarak onların merakını kullanır ve onlardan yiyecek alırlar. Fakat daha da önemlisi, askerler köyde bir katalizör görevi görerek köylüleri bir araya getirir. Bu sayede, herkesin tek başına yapamayacağı bir şeyi başarmalarını sağlarlar. Bir tür sinerjik sonuç doğar ve sonunda herkes kazanır.

Bazen başlamak ya da başlatmak istediğimiz bir işe başlamakda zorlanabiliriz. Herkes elindeki kaynakları, imkanları saklayabilir. Bu durumda elimizi taşın altına sokmalı ve ne istediğimizi, yaparak göstermeliyiz. Onların meraklarını celbetmeliyiz. Sonra eksik olan noktaların eklenmesi, tamamlanması durumunda nasıl güzel olacağından bahsetmeliyiz. İnsanlar devam eden bir başarıya dahil olmanın kolay ve güzel olduğunu bilirler.

İpucu: Değişim için katalizör ol

Köylülerin Bakışıyla

Köylüler taşlara o kadar çok odaklanmışlardı ki başka şey düşünmüyorlardı. Biz buna nerdeyse her gün kanabiliyoruz. Birşeyler ansızın karşımıza çıkabiliyor.

Semptomları görebiliyoruz. Projeler kaçınılmaz olarak kontrolden çıkabiliyor. Çoğu yazılım felekatleri farkedilemeyecek kadar küçük başlar, proje gecikmelerinin çoğu günbegün yaşanabilir. Sistemler her özellik ve her yama sonrası öyle değişir ki sonunda orjinal yazılımdan eser kalmaz. Bu sıklıkla takımın moralini bozan küçük şeylerin birikimidir.

İpucu: Büyük resmi her zaman hatırla

Kaynar suya atılan kurbağa ile soğuk suya atılıp yavaş yavaş kaynatılan kurbağanın hikayesini bilirsiniz. Bu kurbağa problemi, kırık pencere probleminden farklı tabi ki. Kırık pencere probleminde insanlar düzensizliğe karşı savaşma isteklerini kaybederler çünkü kimse umursamaz. Kurbağa probleminde ise kimse değişikliği farketmez.

Her zaman bir gözümüz büyük resimde olmalı. Sadece kendi yaptığımızı değil aynı zamanda sürekli etrafımızda olanları da gözden geçirmeliyiz.

Taş çorbasında köylüleri aldatmayla yavaş yavaş iyiye doğru giden bir değişim söz konusuyken, yavaş yavaş ısıtılarak aldatılan kurbağa ile de kötüye doğru giden bir değişim söz konusudur. Bence ikisi de büyük resmi hatırlamakla ve unutmakla alakalı olabilir. Değişim için katalizör olurken bu iki hikayeyi hatırlamalı ve hangisine sebep olduğumuzu tarafsız bir şekilde değerlendirmeliyiz.

Yeterince iyi bir yazılım

En iyiyi çabalarken, sıklıkla iyi olanı bozarız. Shakespeare, King Lear 1.4

Mükemmel iyinin düşmanıdır. Voltaire

Keşke kalite üzerinde gerçekten bir kontrolümüz olsaydı. Fakat dünya gerçek mükemmeli üretmemize izin vermeyecektir. Zaman, teknoloji ve mizacımız hep aleyhimize.

Fakat bu durumun bizi bloklamasına izin vermeyelim. Ed Yourdon’ın bir makalede tanımladığı gibi, yeterince iyi bir yazılım — kullanıcılar için, sonraki yazılımcılar için, kendi iç huzurumuz için yeterince iyi olan — yazma konusunda kendimizi disipline edebiliriz. Böylece daha üretken olduğumuzu ve kullanıcıların da daha mutlu olduğunu görebiliriz.

“Yeterince iyi” özensiz ve kötü üretilmiş bir kod demek değildir. Bütün sistemler başarılı olmak için kullanıcılarının ihtiyaçlarını karşılamalıdır. Burada savunulan şey basitçe kullanıcıların sürece dahil olması ve ürettiğimiz şeyin ihtiyaçlarına ne zaman yeterince iyi olduğuna karar verebilmeleridir.

Kullanıcıları Trade-Off(değiş-tokuş, ödünleşim) sürecine dahil edin

Hiç sisteminizin kullanıcılarına yazılımlarının ne kadar iyi olmasını istediklerini sordunuz mu? Eğer bir oto-pilot ya da geniş bir alanda kullanılan low-level bir kütüphane yazıyorsanız, gereksinimler daha zor ve seçenekler daha az olacaktır.

Ancak, yepyeni bir üründe çalışıyorsak bu sefer de farklı kısıtlamalarımız olacaktır. İşin içine çok fazla birim/kişi dahil olacak ve teslim tarihi, nakit akışı kısıtlamaları gibi şeyler planlanacak/konuşulacak. Beklentileri görmezden gelerek uygulamaya yeni özellikler eklemek profesyonelce bir yaklaşım olmayacaktır. Aynı şekilde gerçekçi olmayan deadline’lar verilmesi ve bu nedenle temel kodsal/sistemsel gereklilikleri kaldırmak da profesyonelce değildir.

Sistemin kapsamı ve kalitesi, sistemin gereksinimleri olarak tartışılmalıdır.

İpucu: Kaliteyi bir gereksinim meselesi yap

Bugünün harika yazılımı sıklıkla yarının mükemmel yazılımına tercih edilir.

Ne zaman duracağınızı bilin

Nerede duracağımızı bilmezsek bütün çabalarımız boşa gidebilir. Bir resme sürekli yeni bir katman, detay eklerlenirse, bir zaman sonra resim görünmez olur.

Gayet iyi bir uygulamayı aşırı süsleyerek, aşırı şekilde düzeltmeler yaparak bozmayalım. Bırakalım mevcut hali ile bir süre devam etsin. Mükemmel olmayabilir, olsun. Endişelenme, hiçbir zaman mükemmel olmayabilir.