Yaşayan Bir Organizma: Yazılım
Bir önceki yazımda, gelişme süreci devam eden yazılımlarımızı nasıl kontrol altında tuttuğumuza küçük de olsa ışık tutmaya çalışmıştım. Bahsi geçen teknoloji ve süreçler reel yaşam döngüsüne başlamış olan projelerimizde vücut bulmakta. Peki, yaşam döngüsünün başında — geliştirme sürecinde — kodlarımızı ve aksiyon süreçlerini nasıl kontrol altında tutmaya çalışıyoruz?
[X] Driven Development
Öncelikle açık yüreklilikle itiraf etmeliyim ki, iç süreçlerimizde bir standart olarak “[X] Driven Development” yönelimlerine meyilli değiliz. Günümüzde bu yönelimlerin varlığı, standart olarak kabul edilme zorunluluğu, yararlılığı sürekli olarak tartışılıyor. Bizler de kendi içimizde bu tartışmaları haliyle gerçekleştiriyoruz. Evet, yazılımlarımızın alıp verdiği nefes herkes tarafından duyulacak şekle büründüğünde ortaya koyduğumuz bir kontrol mekanizmamız var, ama arka tarafta — üretim bandında — kalite standartlarımızı nasıl belirleyebiliriz? Ekip olarak son dönemlerde üzerinde fazlasıyla kafa yorduğumuz en büyük soru işaretinin bu olduğunu gönül rahatlığıyla ifade edebilirim.
Ara başlıkta ifade ettiğim bu yönelimlerden en meşhur iki tanesini hepimiz ismen de olsa tanıyoruz. TDD (Test-Driven Development) ve BDD (Behavior-Driven Development). Bu iki kardeş kavram ve kavramların canlandırılması ile ilgili internet mecrasında onlarca makale, röportaj, kod örneği mevcut. Yazının bazı bölümlerinde de bu kaynaklardan birkaçını sizlere sunmak isterim. Dolayısıyla fazlaca tekrara düşmemek üzere, kişisel olarak ilgimi çeken ve bazı geliştirmelerimde (özellikle “bazı” kelimesine dikkat çekmek istedim, ben de henüz bunu bir yönelim olarak içselleştiremedim) referans noktamı oluşturan bir kavrama dikkat çekmek istiyorum:
Behavior-Driven Development (BDD)
Nam-ı diğer “Davranışa Dayalı/Davranış Yönelimli Geliştirme”.
Türkçeleştirmeye çalıştığımızda aslında nihai varlığını çok net bir şekilde ifade ettiğini düşündüğüm bir yöntem. Temel prensibi: Davranış. Bu kavramın Wikipedia’daki tanımı bizi “anlamlandırma” noktasına hızlıca yönlendiriyor aslında:
“Davranış, psikolojik anlamda canlıların dış dünyaya karşı gösterdikleri her türlü bilişsel, duyuşsal ve psikomotor (bedensel-fiziksel) tepkilerin genel adıdır.”
Bu noktada akla gelen ilk soru şu oluyor tabii ki: “Yazılım ve canlılık?” Aslında yazılımlar bilişim evreninin en eski canlıları. Şu anda kullandığımız onlarca yazılımın kökenini araştırdığınızda çıkan sonuçlara eminim şaşıracaksınız.
Yazıyı yazdığım bilgisayarın işletim sistemi olan Windows 10'un atalarından Windows 1.0 ilk sürümünü 1987 yılında gerçekleştirmiş. 1990'lı yıllardan bu yana hizmete devam eden binlerce web sitesi hala ayakta. “İnternet Mahir”i duymayan kalmış mıdır?
Yazılım davranışı nedir?
Nesne yönelimli programlama (Object Oriented Programming — OOP — ) kavramına aşina olanlar “Behavior” kavramını muhakkak duymuşlardır. Şöyle bir tanım içerisinde bu kavram kendisine yer bulur: “Sınıflar (class) genellikle özellik (property) ve davranışlardan (behavior) oluşur.” Bizler de yazılımlarımızı geliştirirken sınıflardan ve sınıf ailesine ait kavramlardan çoğunlukla yararlanırız. Bu şekilde uygulamalarımız ve kullanıcılar arasında etkileşimler sağlar, veri kaynaklarımızla iletişime geçeriz. Bir form uygulamasında butona basılma aksiyonu bir “davranış” iken, bir web uygulamasında metin alanına girilen değerin doğrulamadan geçirilmesi de bir yazılımsal “davranış”tır. Tam bu noktada BDD denilen kavram hayatımıza giriyor. Bu davranışların neden olacağı sonuç merkezli testler yönelimli yazılım gerçekleştirme. Yani “SENARYO” merkezli geliştirme.
Test-Driven Development’tan bahsediyorsun!
Evet bundan bahsediyorum. TDD vs. BDD konseptini hiçbir zaman sindiremedim. Bence — ki bir çok görüş de bu şekilde — BDD aslında bir TDD. TDD’de araç ve gerecimizi test ederken, BDD’de bu araç ve gereçle gerçekleştireceğiniz eylemin senaryosunu test edersiniz. Ama yine TEST edersiniz. Yöntem farklı olsa da iki yönelim de aynı referans noktayı işaret eder.
BDD ile ne kazanırız?
En büyük kazanç, müşteri (bu bazen projenin analisti olur, bazen ise teknik olmayan gerçek bir müşteri) ile ortak bir dilde buluşmak olduğunu düşünüyorum. BDD yönteminde işler “Senaryo — Scenario — ” denilen anahtar kelime üzerinden yürüyor. İstenen davranışın senaryosu, ilgili kişi tarafından geliştiriciye iletiliyor ve iletilen bu senaryo geliştirici tarafından test fonksiyonlarına yükleniyor. Bahsi geçen senaryoların tabii ki bazı yapısal özellikleri mevcut. Bu yapısal özelliklere bir çok teknik makaleden ulaşmanız mümkün. En güzel özetleyen yerlerden bir tanesi yine Wikipedia. Müşterinizden bir takım boşlukları doldurmasını isteyebilirsiniz ya da serbest bir senaryo konseptini, BDD feature yapısına kendiniz çevirebilirsiniz. Örnek bir senaryoyu şu şekilde göstermek mümkün:
Gördüğünüz gibi “Feature”, “Scenario”, “Given”, “When”, “Then” gibi saklı anahtar kelimeleri ayrı tutarsak aslında günlük dilden farksız bir test senaryosu karşınıza geliyor. Size düşen ise bu senaryoyu test edecek ilgili sınıfı oluşturmak ve testi çalıştırmak.
Yukarıdaki test senaryosunun bağlı bulunduğu projeye Github hesabımdan erişebilirsiniz.
BDD’yi projelerimizde nasıl canlandırırız?
Bu yönelim için hemen hemen her programlama diline özgü kütüphaneler mevcut. .NET uygulamalarında kullanmak üzere Specflow, Python uygulamalarında ise Behave kütüphanesi bunlardan sadece ikisi. Vermiş olduğum Github linkinde de örnek olarak bir Python uygulaması seçtim. Bu proje üzerinden gerekli testlerinizi gerçekleştirebilirsiniz.
Gün Sonu
Yazımın girişinde de belirttiğim gibi henüz bu yönelimi tam anlamıyla içselleştirebilmiş ve kendi yazılım sürecimin standart bir parçası haline getirebilmiş değilim. Şu anda en temel hedeflerimden bir tanesi de bu. Bu yolda da edindiğim bazı tecrübeleri sizlere kısa da olsa aktarmak istedim. Umuyorum ki bu konuyu kendisine dert etmiş kimi meslektaşlarıma yardımcı olabilmişimdir. İlerleyen yazılarda daha temel ve teknik örneklerden de yararlanmayı planlamaktayım.
O zamana dek herkese sevgiler. En kısa sürede tekrar görüşmek dileğiyle.
