Data Vinci 32 : X Driven Development – dunno
Posted on March 26, 2018 by Görkem Özdoğan
Bu yazıda yazılım geliştirme yaklaşımlarına değineceğim. BDD ,TDD , DDD gibi kısaltmaları görmüş veya duymuşsunuzdur. “bididi”, “tididi” şeklinde konuşmalar içerisinde geçen bu kavramlar nedir? bu yazının ana niyeti olacak. Yazılım geliştirme disiplinleriyle ilgili birçok fütüristik yaklaşım önerilmekte ve çoğu kendi içerisinde tutarlı teoriler içermektedir. Fakat olay “Napolyon – komutan” hikayesindeki gibi “barut bitti.” seviyesinde ise bu yaklaşımları tartışmak, ele almaya çalışmak gerçekçi olmayacaktır. İçinde bulunduğum şartlardan izole bir şekilde sizlere bu kavramları aktarmak istiyorum. Zannedersem en yaygın bilinen “Driven Development”, Test Driven Development bu yüzden onunla başlamak istedim.
Ünlü yazılımcı “Kent Beck” tarafından akredite edilen yaklaşımda, adından anlaşıldığı gibi “Test-First” yani önce testlerin yazılması önerilir. Yazılan testler çalıştırılır, hata alan testler düzeltilir ve kodu daha sonra yazılır. Sonrasında testler tekrar çalıştırılır ve kod gözden geçirmeleri yapılır. Test güdümlü yazılım geliştirme yaklaşımı bu döngüyü kullanmaktadır basitçe. Her disiplinin içerdiği faydalar ve sıkıntıya yol açan bakış açıları TDD’de de mevcut.
Barutu bitmiş yazılımcı bakış açısında önce test yazmak, sonra o testi geçebilen kodu yazmak işi uzatıyor izlenimi yaratabilir. Fakat KISS ve YAGNI gibi pratikleri uygulamak esas olan TDD yaklaşımında aslında yazılmaması gereken kodları yazmayarak daha az zaman harcamak mümkün olabilir. Barutu bitmiş bir yönetim anlayışında ise unit test zaten tamamen saçmalık gibi değerlendirilir, konuyu açmaya bile gerek yok.
Unit test yazılmış olması, test otomasyonu yapılıyor olması veya elle yapılan son kullanıcı testlerinin yapılmasına gerek olmadığı anlamına gelmiyor. Buradaki kaygımız kodun testi ile ilgili.
Bu testlerin yazılması için çeşitli framework ve araçlar mevcuttur. Microsoft ürün yelpazesinde ve programlama dillerinde çalışılıyorsa bu araçlar : Nunit, MS Test, XUnit olabileceği gibi. Java tabanlı bir ortamda Junit, TestNg olabilir, Python’da ise PyUnit vb. kullanılır. Görüldüğü üzere her çalışma ortamı için farklı araçlar kullanılabilir. Genellikle Türkiye’de TDD uygulan-a-mıyor. İstisnalar kaideyi bozmaz diyerek “genelleme” yaptığımı da belirtiyim. Benim bilmediğim, gidip görmediğim diyarlarda bu metotları uygulayarak geliştirme yapan illa ki vardır.
Bu yaklaşımda TDD’den yola çıkarak, teknik test gereksinimlerini iş isterlerine uyarlanmış olarak değerlendirmeyi hedef almaktadır. Bir nevi hibrit yaklaşım güder. TDD’den gelen teknik gereksinimler ile Domain Driven Development’daki yaklaşımları harmanlar. TDD’den farklı olarak “neleri test etmeli, neleri etmemeliyim?”, “Neleri ne kadar test etmeliyim?”, “Testin başarısız olduğunu nasıl anlarım?” gibi sorulara cevap aramaktadır. Sınıfları, metotları test etmek yerine, senaryoları test etmeyi amaçlar. Bunu yaparken “given-when-then” yapısı kullanılır. Yani,
Olayın tetiklenme zamanı
Bir senaryo üzerinden test yapılması, paydaşlar ile iletişimin arttrılmasını sağlar. BDD’de yazılan testler doğal olarak insan diline daha yakın olacaktır. Yine çeşitli araçlar ve diller ile bu testlerin yapılması sağlanmaktadır. Gherkin, Cucumber gibi adını duymuş olabileceğiniz araçlar kullanılmaktadır.
BDD yaklaşımı uygulamak için TDD‘de uygulayabiliyor olmak gerekir. ( https://softwareengineering.stackexchange.com/a/111844/255653)
Konu güzel ve ilgi çekici, zaten TDD’den sonraki adım olarak BDD geliyor denilebilir. Lâkin banana. Uygulayanı görmedim, duymadım:)
Yine benzer kaygılar taşıyan bir model, yazılımcının iş kurallarını kendine göre değerlendirip bir model kurması sonucu, nihayi sonucun çok dışında absürd bir süreci işleten uygulamalar… Bundan kaçınmak için “Domain” yani alan uzmanlığının, yazılım geliştirme sürecine doğru bir şekilde aktarılması gerekir. DDD yaklaşımı bu ihtiyaca karşılık olabilecek bir model kurmadır diyebiliriz. Bunun yine “ortak dil“, -aynı konu hakkında aynı şeyin düşünülmesi- gerekmektedir. Bu amaçla DDD’de bir takım desenler ortaya konulur. Repository, Entity, Aggragate Root, Service, Factory, Value gibi…
Nihai amaç, Business Katman’ının (Domain) mümkün mertebe soyutlamak, bu arada da gerçek dünya gereksinimlerini tam anlamıyla karşılayabilecek, yekpare bir çözüm sunabilmektir. Bu yaklaşımı uygulamayabilmek için ön gereksinimler Tasarım desenleri ve Kurumsal tasarım desenlerine hâkimiyet. DDD uygulamak için gerekli bilgiye vakıf olunmadığı durumlarda faydadan ziyade zarar olacaktır. Çünkü bu teorik kurguyu oluşturmak için geçen vakit, pratik bir çıktı üretmemekte. DDD’yi aldım çaktım projeye çok iyi oldu, çok güzel oldu gibi bir süreç işlemeyecektir. “Domain” bilgisinin şart olduğunu da ekleyelim.
Yazının başlığında da belirttim birçok “driven development” türevi var. Hepsinin kendine özgü bir felsefesi, fayda ve zararları var. En yaygın olarak bilinen mahşerin 3 atlısı bunlar. Bunun yanında daha az bilinen Agile model driven, Documentation Driven, Hammock Driven, Prototype Driven, Asshole Driven, Fear Driven, YOLO driven, Community Driven, Kervan yolda düzülür Driven, Stackoverflow Driven liste uzar gider:)
Kaynak bölümünde paylaştığım YOLO driven development’dan bahsedilen komik bir yazı var ,okumanızı tavsiye ederim.
YOLO = You Only Live Once…
TDD,BDD,DDD gibi yazılım geliştirme yaklaşımlarına kısaca değindiğim bir yazı. Detaylı araştırmalar için bir takım linkleri kaynak kısmında paylaştım. Barutunuz bitmediyse göz atmanızda fayda var.
What is Model-Driven Development (MDD)?