Document(ion) Driven Development

     S.A. Arkadaşlar,

    Bugün biraz cahilliğime güleceğim, ayrıca birlikte düşüneceğimiz bir konu üzerine yazmayı düşünüyorum. Geçenlerde şirkette bir geliştirme yapacaktık, bu geliştirmeyi yapmadan önce yazılım mimarımız ile konuştuk (Gökhan abi) ve genel başlıkları kabaca çıkardık, bunu dokümante ettik. Daha sonra bu projeyi kullanacak diğer ekiplere sunduk, onların da fikirlerini alarak dokümantasyonu güncelledik. Son halinde hemfikir olduktan sonra da kodlamaya başladık. Buraya kadar her şey iyiydi, taa ki bu yazıya başlayınca kadar :) TDD'nin temel prensibi önce testi yazıp sonra kodunu yazmak üzerine nasıl kurulu ise biz de önce dokümantasyonu hazırladık sonra kodunu yazdık, buna da "Document Driven Development" (bazı yerlerde Document DD olarak da geçiyor) diyebiliriz diye kendi kendime düşünüyordum, ama böyle bir şey var mı diye başlığı arattığımda maalesef cehaletim yüzüme gün gibi çarptı. Böyle bir şey düşünebildiğime mi sevineyim yoksa bunu hiç duymamış olmama mı üzüleyim, açıkçası bilemedim. Hazırsak başlayalım.

    Yukarıda da bahsettiğimiz gibi projelerimizde ortak bir yapıya ihtiyacımız oldu, bunun isterlerini netleştirmeye çalıştık, diğer ekiplerle birlikte bu konu üzerine hemfikir olduktan sonra kodlamaya başladık. Bunu bize nasıl bir faydası oldu derseniz, öncelikle yapılan işi hemen kodlamak yerine (bayıldığımız ilke olan "kervan yolda düzülür" hatasına düşmedik) ekiple birlikte tüm isterleri toplamaya çalıştık, tabii ki kaçırdığımız noktalar olabilir veya daha sonra buna ek geliştirmeler yapabiliriz, ama ilk en azından ilk aşamada hangi ekibin tam olarak neye ihtiyacı olduğunu anladık ve bu vesileyle over-engineering (gereğinden fazlası düşünmek/tasarlamak) olmadan bu işi sadece ihtiyacımız kadar olan kısmı yaptık.

    Biz bu geliştirmeyi yapmadan dokümantasyonumuzu hazırladığımızı söylemiştik, ekip liderlerinin gözden geçirmesine sunduk, burada ekiplerden bir arkadaş daha önce kişisel olarak daha önceden bizim ilgilendiğimiz konuyla ilgilenmiş, bu dokümantasyonu tüm takıma sunsak belki buradaki bilgiyi daha önceden elde edebilirdik, burada böyle bir eksikliğimiz oldu ama tüm ekiple bunu tartışmak da bazen bizleri yavaşlatabiliyor. Bunları ekibin yapısına göre değerlendirmek daha doğru olacaktır.

    Yukarıda bahsettiğimiz proje çok daha kapsamlıydı ve bunu değiştirelim mi diye aramızda tekrardan konuştuk, fakat yukarıda da bahsettiğimiz gibi buna gerçekten ihtiyacımız var mıydı? İhtiyacımız olmayan şeylerin çoğunu düşünmeye şu aşamada içeri almaya gerek var mıydı? Biz yok olarak düşünüp yolumuza bu şekilde devam etme kararı aldık.

    Hem projenin tasarımı üzerine ekiple bu konuyu tartışmak hem de ihtiyaçları doğru şekilde anlamak açısından benim çok hoşuma giden bir yöntem oldu. Projenin kodlamasını bitirdiğimde kimseden ama bu da olacaktı şu da olmalıydı ya da bize neden haber vermedin şöyle bir isteğimiz de olacaktı gibi sorunların önüne geçmiş olduk. Ayrıca yorumları bir hafta boyunca bekledik herkes müsait zamanında yorumunu ekledi ve son kararı toplanarak verdik. Bunu da aslında çayın demlenmesine benzetiyorum. Yeterince süre beklediğimizde çay nasıl güzelleşiyorsa bu fikir de öyle güzelleşti, tabii çok bekleyip de çayı da yakmamak lazım :)

    Bu tarz bir geliştirmenin şöyle bir güzelliği de var, bu işi dokümantasyonuyla birlikte yaptığın için tekrardan buna üşenmeye şansın da olmuyor veya acil bastıran başka işlerden dolayı aman sonra yazalım konusu da ortaya çıkmıyor. Neden dokümantasyon/test yazmıyorsunuz sorularının cevabını eminim hepiniz çok iyi biliyorsunuzdur :)

    Her güzel işte olduğu gibi bunun da zorlukları tabii ki var. Dokümantasyon yazmayı veya geri dönüşlerde bulunmayı sevmeyen bir ekipte yer alıyorsanız bu tarz işleri yapmak gerçekten zor olabilir. Neyse ki bizim ekip bu konuda gerçekten iyi ve bu sizi yaptığınız işten daha çok keyif almanıza vesile oluyor.

    "Hafız olmak kolay, hafız kalmak zordur" derler, dokümantasyon yazmada da aslında bu şöyle geçerli. Dokümantasyonu yazmak kolay ama güncel tutmak zor olandır. Bu projeye eklemeler yapılmadan önce yine gidip ilgili dokümantasyon güncellenir mi yoksa o andaki aciliyete göre kod hemen yazılıp hayata devam mı edilir.

    Bu kullanımda kendimizce gördüğümüz artı eksi yönleri ele almaya çalıştık, benim gibi yazmayı ve geri dönüş (feedback) almayı seven biri için çok değerli ve bir o kadar eğlenceli bir tecrübe oldu. Bunu mümkün mertebe ekipçe kullanmaya özen göstereceğiz.

    Yazıyı kuran-ı kerim'in en uzun ayeti olan Bakara 282'nin yazmanın önemiyle ilgili olan kısmıyla bitirelim.

"Ey iman edenler! Belli bir vade ile karşılıklı borç alışverişinde bulunduğunuz vakit onu yazın. Hem aranızda doğruluğuyla tanınmış yazı bilen biri yazsın. Yazı bilen biri, Allah'ın, kendisine öğrettiği gibi yazmaktan kaçınmasın da yazsın. Bir de hak kendi üzerinde olan adam söyleyip yazdırsın ve her biri yazarken Rabbi olan Allah'tan korksun da haktan birşey eksiltmesin. Şayet borçlu bir bunak veya küçük bir çocuk veya söyleyip yazdıramayacak durumda biri ise velisi doğrusunu söyleyip yazdırsın."