Yari Cevik Tasarim

Çevik süreçler genel olarak, sistemin ön tasarım ile geliştirilmesinin yerine, tasarımın test ve programlama içinden geliştirilmesini söylüyor. Bu kural genel olarak doğru bir kural. Fakat istisnaları var.
Son zamanlarda üzerinde çalıştığım iş akışı otomasyonu projesinde, farklı bir yöntem izliyorum. Önce dokümantasyon ile birlikte, sözde kod benzeri mantıksal bir tasarımı çıkarmaya çalışıyorum. Gayet verimli oluyor. Program ve testin yararı, mantıksal adımlardaki boşlukları tümüyle gidermek oluyor. Fakat ister istemez, üst seviye hızlı bakıştan biraz ödün vermek gerekiyor. Ayrıca kod bir kere yazıldıktan sonra, mevcut kod evrime engel oluyor.
Dinamik diller, type inferencing, otomatik refactoring desteği mevcut kodun evrilmesini kolaylaştırıyor; fakat yine de bu araçlarla bile değişim düşüncenin hızına yetişemiyor. Ne var ki, aklın da kapasitesi çabuk doluyor. Tasarım kararlarının sayısı belirli bir miktarın üzerine çıkınca, zihin bunları takip edemiyor.
Bu yüzden, şöyle bir yöntem izliyorum: Eğer tasarım gerektiren zor bir problem üzerine çalışıyorsam, önce sözde kodlarla mantıksal tasarımı geliştiriyorum. Aklımın kaldırabileceği kadar karmaşıklığa varınca, program ve testleri yazıyorum. Sonra bir sonraki tasarım problemi için yeniden, mantıksal tasarımı elle yapmaya geri dönüyorum. Çevik ilkelerin tavsiye ettiği gibi, bu da yine devirli bir tasarım süreci. Fakat çevik ilkelerden farkı, önce tasarım, sonra program/test.
Gerçi bu usul çok yeni bir farklılaşma da sayılmaz. Yıllardan beri çevik yöntemlerden sayılan Jeff de Luca ve Peter Coad’ın FDD (feature driven development) yöntemi de önce tasarım, sonra programlama çevrimini tavsiye ediyor.