6 Haziran 2015 Cumartesi

Hatalar İle Nasıl Başa Çıkılır?

Bırakın artık hata çözmeyi Allah aşkına. Çöz çöz bitmedi bir türlü...


Daha önce yayınladığım "Scrum Ekipleri ve Hata Kayıtları" başlıklı yazımda takımların hata kayıtlarına karşı kullanabilecekleri bazı çözümlere değinmeye çalışmıştım. Bu yazım, daha hatalar ortaya çıkmadan nasıl çözülür hakkında olacak.



Hataları oluştukça çözmek hatta bu konuda çok başarılı olmak, kaliteli bir uygulamaya veya memnun müşterilere sahip olmanızı sağlamaz. Hata çözümündeki başarısı ile müşterileri memnun etmeyi düşünen geliştiriciyi ve hataları giderdiği için geliştiricisine minnet duyan müşteriyi hiç anlayabilmiş değilim. Sektör genelinde hatalar normal kabul edildiğinden midir yoksa müşterinin bizden başka çalacak kapısının olmamasından mıdır bilinmez bizim sektörde hatalar yeterince önemsenmez. "Sistem çalışmıyor!", "Ekranım dondu!" veya "Maalesef şu an işleminizi gerçekleştiremiyorum!" gibi cümleler bilişim sektöründe olağan karşılanır.

İlk evlendiğimde evimize aldığımız 2 tane dolabın çekmeceleri aynı hizada olmadığı için marangozu düzeltene kadar evden göndermemiştim. Tüm çekmeceler düzgün açılıp kapanıyor (yani çalışıyor) sadece 2-3 milimetrelik ufak bir fark ile biri diğerinden aşağıda duruyordu. Sonuçta para ile bu işi yaptırmıştım ve birebir istediğimin teslim edilmesini bekliyordum. Sipariş ettiğimiz buz dolabının bazı rafları soğuk olmasa, veya fırınımızın bir gözü bazen yanmazken bazen de yemeği yaksa herhalde aldığımız ürünü anında geri iade ederdik. Bir daha da o markadan alış veriş yapmazdık.

Sektör olarak hangi sebeplerden ötürü böyle olduğumuz hakkında (şimdilik) konuşmayı düşünmüyorum. Onun yerine bu duruma düşmemizi engelleyecek bazı yardımcılardan bahsedeceğim.

1. Yardımcı: Kendimiz

Evet doğru. Eğer elimizde hatası çok olan bir uygulama varsa bize en çok yardımcı olacak kişi kendimiziz. Elimizdeki uygulama ister yeni yazılmış ve 783 tane hata ile size devredilmiş olsun, isterse 12 yıldır çalışan ve artık kumaştan çok yaması olan bir elbise gibi olsun veyahut geliştirmesine yeni başlanmış olsun her durumda başvuracağımız ilk yardımcı kendimiziz.

Bir geliştirici geliştirdiği uygulamayı daha kaliteli yapmakla yükümlüdür. Tabii böyle söyleyince kuru bir laf oluyor. Herkes elinden geldiğince kaliteli uygulama geliştirir değil mi. Doğru. Ama sadece istemek yeterli olmaz. Bu konuyu zihnimizde canlı tutmalı ve diğer yardımcılara baş vurmalıyız. "Ah yine mi hata çıktı? O kadar da dilek tutmuş, Allah'a dua etmiştik hata çıkmasın diye!". Tamam duanın ilk aşaması olan sözlü duayı yaptın. Ama fiili duayı yapmazsan ne fayda. Yani hata olmamasını istedin ama istemenin yanı sıra ne yaptın? Sadece testçinin yapılan tüm hataları yakalayacağına güvendiysen gel bir de aşağıdaki yardımcılara bakalım.

2. Yardımcı: Geliştirme Yardımcıları

Eğer ben kod yazan bir kişi isem öncelikle işimi kaliteli yapacağım. Baştan savma ve hızlıca yazılmış bir kod ile zamanı çok iyi kullandığımı veya yöneticimi etkilediğimi düşünebilirim. Ama çoğu zaman yanılıyorumdur. Yazılan kod hatalı olmasa bile elbet biri bir gün kaportayı açacak ve yazılan kod üzerinde bakım çalışması yapacak veya üzerine yeni fonksiyonlar bina edecek. (Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. John F. Woods) Bu tür yazılmış kodlar en iyi ihtimalle, hatasız çalışsa bile ilerde başka hatalara sebebiyet verecektir. Temiz ve belirli standartlara uygun yazılan kodun kafamızı daha az ağrıttığı konusunda hepimiz hem fikirizdir.

Bu konuda kafa yoran kişiler sağ olsun bazı teknikler geliştirmişler. Code Review, Pair Programming, Test Driven Development (TDD) bunlardan bazıları. Bu tür teknikleri kullanarak hataları daha oluşmadan bertaraf edebiliriz.

Ayrıca Code Refactoring yapmaktan korkmamalı gereksiz kodları sürekli temizlemeli, ihtiyaçlara göre kodları yeniden dizayn etmeli, performans sorunu oluşturabilecek veya karmaşık kodları düzenlemeliyiz. Böylece uygulamamız daha yavaş yaşlanacak ve ihtiyaçlara daha hızlı adapte olabilecektir.

Bu konuda kendini daha da geliştirmek isteyenler Software Craftsmanship etkinliklerini takip edebilirler.

3. Yardımcı: Test Yardımcıları

Normalde her yaptığımız değişiklik sonrası, hatta ufak bir hatanın çözümünde bile etkilenen tüm noktaların test edilmesi gerekir. Ama ciddi olalım ki kimsenin o kadar vakti yok. Yazılımcı ufak bir değişiklik yaptı diye tüm testlerimi en baştan yapamam. Hele hele etkilenen diğer noktaları tek tek yeniden test edemem. Etmem lazım, ama edemem. Yazılımcılar bazen günde 3-4 kere test ortamına geçiş yapıyorlar, herhalde her seferinde 3 haftada yaptığım testleri yeniden yapmam beklenemez. O zaman ne yapacağız? Ya geliştirme yapan arkadaşımın "Sadece ufak bir değişiklik yaptım." lafına itimat edeceğiz yada sadece olası bazı noktaları yeniden test edip işimize devam edeceğiz. (Ki zaten projenin veya sprintin bitmesine çok az bir vakit kalmış).

Bu noktada test otomasyonları, test yapan kişilerin zamanını bloke eden bir çok standart testi devralarak kişilerin daha karmaşık ve yeni senaryolar üzerinde yoğunlaşmalarına olanak sağlar.

Ayrıca test yapan arkadaşlar (bu kendimiz de olabiliriz) geliştiricilerden ürün bazlı testlerini kolaylaştıracak araç ve ekranları geliştirmelerini talep etmeliler. Mesela benim sürecim başka bir kaynaktan tetikleniyorsa, her test yapışımda başka birinden benim ürünümü tetiklemesini beklememeliyim. Test amaçlı olarak kendi sistemimi istediğim parametreler ile tetikleyebilmeliyim. Veya bazen teste başlayabilmek için veriyi uygun hale getirmek testin kendisinden daha uzun sürebiliyor. Bu tür durumlar için hazırlanacak test ekranı veya kodları testçinin daha fazla senaryoda daha fazla test yapabilmesine olanak sağlayacaktır.

4. Yardımcı: Yönetimsel Yardımlar

O kadar konuşup yönetime değinmesek olmazdı :).

Yönetim tarafından yapılacak en büyük yardımın kaliteli uygulama için çalışan takım ve kişilerin önünün açılması olduğunu düşünüyorum. Üstüne bir de bu konuda destekçi ve önder olurlarsa şahane olur. Çalışanlardan elde edilecek fayda her zaman çalışılan zaman ile doğru orantılı değildir. İnsanların efektif ve kaliteli üretime teşvik edilmesi ve gerekli teknikler ile donatılması elde edilecek faydayı arttırmanın yanı sıra kaybı da azaltır.

Eğer işler kaliteli yazılım üzerine planlanırsa, yani analiz, geliştirme ve test aktivitelerinin yanına  code review veya otomatik test oluşturma aktiviteleri de eklenirse ilerde çıkacak hatalar şimdiden giderileceği için beklenmedik zaman kayıplarından dolayı planlarda da kayma azalacaktır.


Burada yazdıklarım haricinde ekleme yapmak isteyen arkadaşlar beni çok memnun ederler. Lütfen olumlu/olumsuz yorumlarınızı esirgemeyin :).