Etkili Bir Yazılım Tasarım Dokümanı Nasıl Yazılır?

İyi bir tasarım dokümanı (design doc), yazılım geliştirme süreçlerinde ekiplere aylar hatta yıllar kazandırabilir. Yanlış bir mimari üzerinde kod yazarak vakit kaybetmeden önce kritik kararların etraflıca düşünülmesini sağlar. Google ve Microsoft gibi teknoloji liderlerinde edinilen deneyimler, projelerin detayları değişse de temel prensiplerin aynı kaldığını göstermektedir: Bir tasarım dokümanı, çözülmeye çalışılan zor teknik problemleri netleştirir ve ekip arkadaşlarından erken aşamada geri bildirim almayı kolaylaştırır.

Ne Zaman Bir Tasarım Dokümanı Yazmalısınız?

Proje ne kadar karmaşık veya yüksek riskliyse, tasarım dokümanı hazırlamak o derece değerlidir. Yeni bir projeye veya özelliğe başlamadan önce şu 6 soruyu değerlendirmelisiniz:

Tasarımı hayata geçirmek için birden fazla kişinin koordineli çalışması gerekecek mi?
Proje üç aydan fazla tam zamanlı geliştirme süresi alacak mı?
Uygulama üretim ortamında (production) birkaç yıl boyunca çalışacak mı?
Proje ekipler arası iş birliği (cross-team collaboration) gerektiriyor mu?
Projenin hedefleri ve gereksinimleri belirsiz mi?
Tasarım aşamasında önlenebilecek felaket boyutunda riskler (güvenlik açıkları, yasal riskler vb.) mevcut mu?

Pratik Çıkarım: Bu sorulardan tek birine "evet" yanıtı veriyorsanız tasarım dokümanı hazırlamak harcanan efora kesinlikle değer. İki veya daha fazlasına "evet" diyorsanız, bir doküman oluşturmak projenin başarısı için zorunludur.

Tasarım Dokümanına Ne Kadar Yatırım Yapılmalı?

Tasarım dokümanı tek sayfalık özet bir not olabileceği gibi, beş farklı ekibin onayını gerektiren 50 sayfalık kapsamlı bir belge de olabilir. Kod testlerinde olduğu gibi dokümantasyonun da evrensel tek bir kuralı yoktur. Ayrılacak efor düzeyi; ekibin hedeflerine, risk toleransına, teslim tarihlerine ve mühendislik kültürüne bağlı olarak belirlenmelidir. Bazen yapılması gereken en doğru yatırım sıfırdır.

Bir Tasarım Dokümanının Bileşenleri

Her ufak ayrıntıyı dokümana eklemek geliştirme sürecini hantallaştırır. Kapsamlı ve etkili bir tasarım dokümanı şu 23 bileşeni içermelidir:

Başlık (Title)
Metaveriler (Metadata)
Amaç (Objective)
Arka Plan (Background)
İlgili Dokümanlar (Related documents)
Hedefler (Goals)
Kapsam Dışı Hedefler (Non-goals)
Senaryolar (Scenarios)
Diyagramlar (Diagrams)
Sözlük (Glossary)
Kısıtlar (Constraints)
Hizmet Seviyesi Hedefleri (SLOs)
İzleme ve Uyarı Sistemleri (Monitoring / alerting)
Zaman Çizelgesi (Timeline)
Arayüzler (Interfaces)
Bağımlılıklar ve Altyapı (Dependencies / infrastructure)
Güvenlik (Security)
Gizlilik (Privacy)
Yasal Hususlar (Legal considerations)
Loglama (Logging)
Açık Konular (Open issues)
Çözülen Konular (Resolved issues)
Değerlendirilen Alternatifler (Alternatives considered)

İnceleme Sürecini Yönetmek ve Yanlış Yapmanın Maliyeti

Tasarım dokümanını kod yazmadan önce hazırlamak ve ekip incelemesine (review) açmak, yanlış mimari seçimlerinin doğuracağı fahiş geliştirme maliyetlerini önler. Doküman üzerinde fikir birliği sağlamak, geliştiricilerin uygulamayı hayata geçirirken doğru yolda kalmasını ve ortak vizyonla ilerlemesini temin eder.

Orijinal kaynağa buradan ulaşabilirsiniz.