Teknik borç, teknik kirlilik adına ne derseniz deyin biliyoruz ki biriktikçe işimizi zorlaştıracaklar. Bunu hepimiz yaşadık; yeni bir projede başlarda her şey çok kolay ve çok hızlı ilerledi ama öyle bir an geldi ki değişikliğin adını bile duymak istemez olduk ve sistemlerimizin yeniden yazılması gerektiğini telaffuz etmeye başladık.
Bir geliştirme yapmak zamanla daha zor olacaksa; değişikliği bağrımıza bastığımız, çevik yöntemler ne kadar makul? Her detayı etraflıca düşünmek, bin düşünüp bir söylemek daha mantıklı değil mi? Çevik öncesi dönemde tam da bunu yapmaya çalışıyorduk; isterleri detaylıca inceliyor, sayfalarca dökümanlar üretiyor, detaylı sistem tasarımları yapıyor, geliştirmeye ancak o zaman başlıyorduk. O dönemlerin sorunlarını burada listelemeye gerek yok sanırım.
Çevik yöntemler ancak değişikliklerin maliyeti artmayıp sabit kaldığında ya da zamanla azaldığında sürdürülebilir olacaklar. Bu da sistemlerimizin iç kalitesini yüksek tutmakla; teknik pratikleri yerinde ve zamanında uygulamakla mümkün.
Bu teknik pratiklerin bazılarını farklı kaynaklardan derlemeye çalıştım:
- Yalın ve kademeli tasarım (Simple and evolutionary design)
- Düşük bağımlılığa sahip bir mimari (Loosely coupled architecture)
- Kod iyileştirme çalışmaları (Refactoring)
- Kod standartları
- Yalın ve temiz kod (Clean code)
- Eşli programlama (Pair programming)
- Test yönlendirmeli geliştirme (TDD)
- Sürekli entegrasyon (CI)
- Güvenlik gibi kaygıları öne almak (Shift left)
- Sürüm kontrol sistemleri (Version control)
- DevOps pratikleri
- Doğru ve yeterli test otomasyonu
Teknik pratiklerin yeterli olgunlukta olmadığı bir ortamda çeviklik ancak sözde kalacaktır. Çevik yöntemlerin başarılı olabilmesi için süreçler kadar teknik pratiklere de önem vermeli; bunları öğrenmek, uygulamak ve içselleştirmek için gerekli koşulları oluşturmaya özen göstermeliyiz.
Recep Karabıçak 