Yazılım projelerinin yönetimi üzerine ders çıkarılabilecek bir hikaye

Bir gün ofisimde çalışırken, bir yazılım evi sahibi ve yöneticisi, telaş içinde bana ulaştı. Müşterileri için geliştirdikleri sisteme en son yaptıkları değişiklikleri devreye aldıklarında yaşadıkları ve kendilerini bir hayli zora sokan bir performans probleminin çözümü için bana ulaşmıştı. Bana telefonda söylediği şey, yeni yaptıkları deployment’tan sonra 10-15 dakika içinde, sistem cevap veremez hale geliyor ve nihayetinde de çöküyordu. Sistem, Tomcat üzerinde çalışan ve doğal olarak Java ile geliştirilmiş, web ara yüzlü ve kurum içinde (intranette) pek çok kullanıcısı olan operasyonel bir bilgi sistemiydi.  Bundan dolayı sistemi kullanan müşterilerine karşı çok zor durumda kalmışlardı ve kendini çaresiz hissediyordu. Sistemin son kullanıcılarını eski sürüme yönlendirerek hiç olmazsa işlerin devam etmesini sağlıyorlardı.

Bu konuşmadan yaklaşık 15-20 dakika sonra, yaptığımız telefon görüşmeleri sayesinde, sıkıntılı olan sisteme erişmiş haldeydim. Ayrıca bu sistemin koduna da erişim sağladım. Sistem yöneticisi yardımıyla kabaca ne olup bittiğini anladıktan sonra bir kaç ufak ayarlama ile Tomcat’i tekrar başlattım ve ertesi sabah, kullanıcıların gelip sistemi kullanmaya başlamalarını bekledik. Tabi, ertesi sabah, çalışma saati başladığında 10-15 dakika içinde sistem yine çalışamaz hale geldi ve JVM de bize bir dump üretti.

Elimdeki JVM dump'ı ve sistemin Java kodları vardı, yaklaşık 15-20 dakikada, hadi abarttım diyeyim, yarım saat içinde problemin sebebini, koddaki satırını, hatta çözümünü belirlemiştim. Sonuçta problem, gözden kaçan çok basit bir kodlama hatasından kaynaklanıyordu. Kodun sorunlu parçası sonsuz döngüye giriyor ve her döngüde üretilen yeni nesneler GC tarafından toplanamadığından, çünkü nesneler bir torbaya (collection) konuyordu, belleği şişiriyordu.

Müşteriye durumu açıkladım, yapılması gerekeni de belirttim ve onlar da sistemi sorunsuz bir şekilde devreye aldılar. Onların derdi çözüldü, benim keyfim arttı ve bu işten para da kazandım.

Ama sanırım bu kısa hikâyeden ders alınması gereken diğer bazı hususlardan bahsetmeden geçemeyeceğim. Neler mesela? Bu hikâyeden yazılım geliştirme ile ilgili olarak çıkarılabilecek olan dersler şunlar:

1. Eğer kodunuzu daha sakin kafayla, ne yaptığınızı düşünerek yazarsanız, çok yüksek ihtimalle böyle bir hata yapmazsınız.
2. Eğer yazdığınız kodun birim testini yaparsanız, bu türden problemleri asla yaşamazsınız.
3. Yazdığınız kodu makinanıza deploy edip, geçerli ve doğru verilerle çalışırsanız ki biz buna smoke test diyoruz, problemleri çabuk yakalarsınız.
4. Eğer kod gözden geçirmeleri (review) yaparsanız, sizin gözünüzden kaçsa bile, belki yorgundunuz, ailenizde veya sosyal hayatınızda stresli durumlar vardı, muhtemelen arkadaşlarınızın, daha tecrübeli olanların gözünden kaçmaz.
5. Eğer sistemin entegrasyon testini yaparsanız, bu türden problemlerle çok daha az karşılaşırsınız.
6. Eğer sistemin fonksiyonel testini yaparsanız, tester’larınızla, bu türden problemleri muhtemelen müşteri karşısına çıkmadan yakalarsınız.
7. Yukarıdaki üç testi (entegrasyon testi, fonksiyonel test ve smoke test) ve gözden geçirmeleri yaparsanız, bunlardan herhangi biri ya da tamamen informal bir gözden geçirme yapılsa bile, kesinlikle bu problem müşterinin önüne gelmeden ve çok daha ucuza (nerede bulduğuna göre değişir) çözersiniz.

Bunlar, yazılım süreçlerini doğru yönetmekle ilgili olarak yapılabilecek çıkarımlar. Genel prensipler açısından ise şöyle çıkarımlarda bulunabiliriz:

Belki 40-50 kişilik geliştirme ekibi ve sistem yöneticisinden oluşan bir yazılım evinin ürettiği yüz binlerce belki bir kaç milyon satırlık koddaki bir performans problemini bulmak yarım saati geçmeyen bir süre alıyorsa, bu durumun yazılım evinin sistemsel bir problemi olduğu açıktır. Sıklıkla sanıldığı gibi, bu iş zekâ ya da yetenek işi değil. Bu durum, sistemi tasarlayan, kodlayan ve deploy eden geliştirme ekibinin içinde hiç bir şekilde bir performans yönetimi farkındalığının olmamasıyla açıklanabilir. Ya da bu durum, bu ekipte merak edip Java’nın performans problemlerini araştıran, etrafındakileri bu konuda bilgilendiren meraklı kişilerin olmadığı şeklinde de yorumlanabilir. Bu durum, sistemi tek tek developer’ların geliştirdiği ama kesinlikle “bir geliştirme ekibinin” geliştirmediği şeklinde de yorumlanabilir. Ayrıca bu durum, gerekli temel bilgiye ve problemi bulup, analiz edip, çözme yetkinliklerine sahip bir kişinin, pek çok insanın günlerce, belki haftalarca, aylarca, bilinçsizce problemle cebelleşmesinden çok daha etkin bir şekilde sonuca ulaşabileceğini de gösterir.

Kaynak:

http://www.javaturk.org/alelade-hikayeler-i-kucuk-bir-performans-problemi/