Basit Tasarım

Yaklaşık 9 ay kadar önce Yenibiris.com’dan 3 arkadaş TDD eğitimi almıştık. Eğitimi artık bu alanda guru sayılan J.B.Rainsberger’den (Joe) aldık. Kendisi Kanada’lı bir yazılım geliştirme danışmanı. Yani şirketlerin yazılım geliştirme ekibine “O şöyle bir sorun yaratır, şu patterni kullan”, “Daha önce falanca yerde böyle birşey olmuştu, şöyle çözdük” gibi ahkamlar kesen bir insan.

Meslek, ilk bakışta “ukalalık”, “kendini beğenmişlik”, vs gibi düşünülse de böyle olmadığı açık. Ama bu düşünce yüzünden böyle bir meslek Türkiye’de yok. Zaten sektörün hali ortada. Bu konuyu geçelim. Gelelim konu başlığımıza.

Efendim eğitimin başlamasını müteakip Joe bize ilk şu listeyi yazdı:

Simple Design

1. Passes tests
2. Minimize duplication
3. Maximize clarity
4. Reduces size
5. One thing at a time

Bu 5 madde uygulanırsa sonuç : Modüler tasarım.

Maddelere gelirsek:

• Passes test : TDD de testlerin geçmesi zaten işin temeli. Tasarımın %85 ini oluşturur ve Joe’ya göre (katılmamak elde değil) zamanla otonomik bir hale dönüşüyor. Yani, nasıl yürürken hangi ayağımızı ne zaman öne atacağımızı düşünmeden hareket edip kendi haline bırakıyorsak, zamanla yazılan testlerin geçmesini sağlamak ta aynı şekilde kendi haline bırakılır.
• Minimize duplication : Daha önce yazdığım Bu kod kokuyor isimli makalede bahsi geçmişti. Aynı kod projenizde birden çok kez geçiyorsa ki bu zaman zaman olur. Bunları refactor edip minimize etmeliyiz.
• Maximize clarity : Kodumuzda anlamsız değişkenler, açıklayıcı olmayan class ya da method isimleri bulunmamalı. Asla ve asla kodumuza comment yazmamalıyız. Comment yazılmış kod, açıklayıcı değildir. Kodumuzu öyle bir yazmalıyız ki commente ihtiyaç duymadan kod kendini anlatabilmeli.
• Reduce size : Bu madde 5 i içindeki en önemsiz. Ama aklımızın bir köşesinde bulunmalı. Ne kadar çok kod yazarsak maintenance yapılacak o kadar çok satır olacak demektir. Kodumuzu mümkün olduğunca kısa tutmakta fayda. Tabi bunu yaparken dozu iyi ayarlamalı, şokunu çıkarmamalıyız.
• One thing at a time : İşte bu 5 maddenin en zoru. Aslında olay şu. Her seferinde tek bir şey yapmalıyız. İhtiyacımız oldukça kod yazmalıyız. Aksi takdirde YAGNI olacaktır.

Tecrübeli fakat TDD kullanmayan yazılımcıların bu 5 maddede en çok sonuncusunda zorlandığını öğrendik Joe’dan (Eğitimdeki örneklemelerde bizzat ben) . Sebebi de yıllarca kompleks yapılar tasarlamışlar, Presentation Layer a bi textbox koymak için; bir yandan BL yazarken, diğer yandan DAL yazarak projeler geliştirmişler. Şimdi adama diyorsun ki “dur bakalım. önce falanca classın bilmemne fonksiyonunu yaz. Database ile ilgimiz yok!!!”

E doğal olarak, eğer gelişimden hoşlanmayan bir insansa, “uğraşamam ben bununla” diyerek kestirip atabiliyor.

TDD development aşaması uzun ve keyifli, maintenance ve bugfixing aşaması ise hemen hemen hiç yok diyebileceğim kadar kısa ve zahmetsiz oluyor. Bunu ekip olarak, son yazdığımız servisleri TDD ile yazarak yaşadık.

TDD yi seviyoruz.