Hiç bir pencereyi kırık bırakma!!

Amerika’da yapılan bir araştırmada bir binanın şehrin orta yerinde nasıl çürümeye başladığı araştırılmış. Hani şu filmlerde olur ya etrafında herşey normal görünürken içinde evsizlerin yada ne yaptığı belirsiz insanların yaşadığı uğursuz binalar, işte bu binalar nasıl oluyor da bu hale geliyor araştırılmış arkadaş.

Araştırmada çıkan sonuçlardan biri, binanın genel durumuyla ilgili. Eğer ki bina sürekli titiz bir bakım içerisindeyse, uzun yıllar sağlıklı olarak ayakta kalabiliyor. Mesela arada sırada her binanın camları kırılır, bu camları siz inatla tamir ettiğiniz sürece binanın sınıfı ve canlılığı olduğu gibi kalmaya devam eder. Ama eğer bir kırık camı bir kaç günden uzun süre tamir etmezseniz, diğerleri de o pencereye bakarak bu binanın terk edilmeye başladığını düşünürler ve başka camları kırmaya başlar millet. Bir süre sonra da binadaki hasar öyle bir boyuta gelmiştir ki eskiden binanın sakini olanlar da tamir etmeye üşenir ve binadan taşınırlar, onların yerine de artık ne idüğü belirsiz tipler yerleşmeye başlar.

Bu olayı enteresan bir biçimde yazılım projelerinde de benzetme olarak kullanıyorlar. Örneğin güzel bir proje hazırladınız ve üretim seviyesine getirdiniz. Bu aşamadan sonra yazılım canlı bir süreç olduğundan (gene güzel bir benzetme), bu organizmanın üzerinde değişiklikler olmaya devam ediyor. İşte burada dikkatli olmak gerekiyor ve hiç bir pencereyi kırık bırakmamak gerekiyor.

Örneğin kullanılmayan bir değişken mi gördünüz, hemen kaldırın gitsin. Uzun bir kod blokunun yorumlanarak silindiğini mi fark ettiniz? Silin gitsin, versiyon kontrol araçları ne güne duruyor? Bir kod parçasının iki-üç yerde kopyala yapıştır kullanıldığını mı gördünüz? Hemen onu bir metod haline getirin ve metod çağrısı olarak kullanın. Kodunuz üzerinde bu şekilde titiz davrandığınız zaman, projedeki diğer çalışanlar ve özellikle yeni katılanlar da bu dikkati, özeni göstermeye kendilerini zorunlu hissedeceklerdir. Bu sayede binanız asla terkedilmeyecek ve şanıyla birlikte yaşlanmaya devam edebilecektir.

İyi çalışmalar!

İz Mermileri ve Yazılım Projeleri

Herkese merhaba,

Andrew Hunt ve David Thomas’ın ibretlik çalışması The Pragmatic Programmer kitabında enfes bir bölüm okudum geçenlerde. Bu bölümün en azından Türkçe yorumunu sizlerle paylaşmam gerektiğini düşünüyorum.

Askerlikte, gece çatışmaları ayrı bir önem taşır çünkü genelde hedefinizi işler son raddeye gelinceye kadar göremezsiniz. Çatışma çıktığında işler karışır ve özellikle makinalı tüfek kullanan tim elemanlarının azami dikkat etmesi gereken bir kaç dakika yaşanır. Makinalı tüfek erinin, ateş etmeye başlamadan önce karşı tarafın ateşinin en azından yönünü tespit etmesi gerekir ki kendi elemanlarını vurmasın. Peki bu nasıl yapılır, ses ve iz mermileri ile yapılır. Sesin geldiği yöne bakarsınız ve sonra iz mermilerinin çıktığı yere hedef alırsınız.

Fakat burada Hazır Ol, Nişan Al ve Ateş! emrinden farklı olaylar gelişir. Karanlıkta nişan alabilmeniz çok uzun sürer bir kere, tüfeğin gezinden baktığınızda zaten karanlık olan dünya iyice karanlıklaşır ve herşey görünmez olur. Bu yüzden burada sırayı değiştirmek gerekir, Hazır Ol, Ateş Et, Nişan Al ve Tekrar Ateş Et! emrini uygularsınız. İz mermileri her 10 yada 20 mermide bir fosfor taşıyan mermilerdir ve tüfekten çıktığı andan itibaren arkasında iz bırakarak hedefe ilerler. Siz de bu iz mermileri sayesinde nereyi vurduğunuzu bilir ve gerekirse nişanınızı ona göre yeniden düzenlersiniz. Ve eninde sonunda hedefi vurursunuz, tabii o sizi daha önce vurmadıysa :). Bu arada denizci olarak askerlik yaptım, bunları da sadece teorik olarak dinledim komutanlarımdan :).

Yazılım projelerinde de benzer bir yaklaşım uygulayabiliriz(hayat fazla derecede askerliğe benziyor ya ona da ayrıca bitiyorum 🙂 ). Diyelim ki yeni bir projeye başlıyorsunuz. Ve ilk deneyeceğiniz işler olacak. Bu durumda, herşeyi baştan tasarlayıp, inciğine kadar detaylandırıp, uzun uğraşlardan sonra tasarımın tamamını ortaya koyabilirsiniz. Bu en temel yazılım mühendisliği çalışma şeklidir ve herkesin aklına ilk bu çözüm gelir.

Fakat bu kadar tasarımda ya hata yaptıysanız? Başa dönmeniz için yeterli vaktiniz kaldı mı? Takımın morali ne durumda? Hali hazırda müşterileriniz varsa onlara ne söyleyeceksiniz? Patronunuza da açıklama yapmanız gerektiğini unutmayın. Sonuç olarak bayağı bir stresse gireceğiniz kesin gibi görünüyor :). Peki bunun yerine ne yapabilirdik?

Bunun yerine, bizi zorlayacak sistemin tek başına çalışabilecek en küçük iskeletini ortaya çıkarabilirdik. Bakın burada prototiplerden bahsetmiyorum çünkü prototip kodlar kullanılmaz, atılır. Burada sistemin en küçük ve basit mimarisinin çıkarılmasından söz ediyorum. Diyelim ki akıllı bir telefondan uzaktaki bir sunucuya bağlanıp, çalışanlarınıza işler atayıp, onlara e-posta yoluyla haber verebilen ve geri besleme alabilen bir çözüm hazırlamanız gerekiyor. Burada ilk olarak, akıllı telefondan uzak sunucuya bağlanıp, oradaki veritabanına veri girip, sonuç olarak boş bir mail gönderen bir iskelet yazılım hazırlamalısınız. Görebileceğiniz gibi bu bir prototip değil, esas sisteminizin en temel parçasını çıkarmış oluyorsunuz. Bunun üzerine diğer akıllı telefonları desteklemeyi, iş tipleri girmeyi, değişik mail adreslerine zamanlı olarak mail atmayı, alınan cevabı işlemeyi de yapabilirsiniz.

Yani sistemin en temel halini en çabuk şekilde hazırlarsanız, projeniz büyük ihtimalle başarıya ulaşacaktır.

Sistemin diğer özelliklerini uygulamayı da kolaylıkla yaparsınız çünkü elinizde en basit işlemin hazır örneği bulunmaktadır. Kolaylıkla yaparsınız çünkü moraller yüksektir, her adımda hedefe yaklaşırsınız.

Aynı izli mermiler gibi…