Karmaşık problemleri yazılım ile çözerken, teknik olarak ne kadar fazla bilgiye sahip olsak da, çeşitli noktaları atladığımızda daha fazla karmaşıklık yaratan çözümler ile karşı karşıya gelebiliyoruz. Java’nın JDK’sını çok iyi bilmemize  ya da .NET Framework’ün tüm özelliklerini gözü kapalı sayabilmemize ya da javascript ile client’lar da takla atıp, avuda kalkmamıza rağmen, neden hala yazılım sorunları ile uğraşıyoruz? Ya da geliştirme süresince neden sorunlar ile karşılaşıyoruz?

Teknik yetkinlik dışında, temel bazı prensip ya da tecrübeleri anlama konusunda eksik kaldığımızda, bir çok sorun karşımıza “dann” diye çıkacaktır, çıkıyor da hatta… Bu yazıda yazılım geliştirirken, düşünme şeklimize yön verecek, yol gösterecek bir kaç prensipten bahsetmek istiyorum, -ki eminim bir çoğunuz da adı gibi biliyordur, ya da en azından duymuştur. KISS,YAGNI,SOC,TDD,WET….

overengineeringKISS – Keep It Simple, Stupid

KISS, basitlik ve sadeliğin altını çizen, bence, en önemli yazılım geliştirme prensibi. Basitlik, kulağa olumsuz bir durum çağrıştırsa da, karmaşık problemleri çözmek adına çoğu zaman çok kritik olabiliyor. Basit düşünmek, düşünebilmek problemin temel sebebini görebilmek adına oldukça önemli. Kolay bir yol ile çözülebilecek problemleri ya da başka bir ifade ile, bir kaç satır kod ile geliştirilebilecek bir metodu,  gereksiz ifadeler ile karmaşık hale sakın getirmeyin der bu prensip basitçe. Bunu derken, ihtiyacı en basit şekilde düşünerek, gerçekten ihtiyaca yönelik özellikleri öne çıkarmanın da altını çizer.  Bir sistem ne kadar karmaşık olursa, onun sürdürebilirliğini sağlamak o kadar zor olur.  Tabi, bu prensibi ele alırken, kalite özelliklerini mutlaka dikkate almak gerek. Basit olacak diye kalite özelliklerini görmezden gelirseniz sonuçta ortaya çıkan şey “basit” değil “sığ” olur.

YAGNI – You Ain’t Gonna Need It

YAGNI, ihtiyacımız olmayacak şeyleri sisteme dahil etmemeyi söyleyen bir prensip. KISS’e oldukça benziyor belli noktalardan aslında.  Geliştirme aşamasında, bazen öngörülü(?) davranıp ileride lazım olabileceğini düşündüğümüz sınıfları,metodları yazarız. Bu, hem ileride lazım olabilir(?) öngörüsü, hem de yaptığımız geliştirmeyi daha büyük görmek istememizden kaynaklanıyor aslında.  E-mail atabilmemizi sağlayan bir sınıf ihtiyacımız olduğu zaman “Öyle bir sınıf yazdım ki, hem SMS atıyor, hem e-mail, hem de Push Notification gönderiyor” diye havalara girdiğimizde, zamanı geldiğinde gerçekler tokatı yapıştırır. YAGNI, bu tokatın gelmemesini sağlayan en önemli prensip.  Yazılımlara, sanatsal yönümüzü de kullanarak geliştirdiğimiz/eklediğimiz her özellik, temelinde ekstra maliyet olarak karşımıza çıkacaktır. Talep edilmemiş olmasına rağmen, geliştirdiğimiz bu özellikler ek test eforu, dökümantasyon ve sonrasında da bakım kavramlarını da dikkate almamızı gerektirecektir.  Ek özellikler ile alengirli bir yazılım yapalım derken, aslında daha karmaşık ve daha da karmaşıklığa giden bir yazılım geliştirme ihtimalimiz o kadar artar. O yüzden, ihtiyaç olarak belirtilmemiş geliştirmelerden kaçıyoruz…

Çok fazla karambole gitmemesi için bu prensiplerden parça parça bahsediyor olacağım…O yüzden KISS ve YAGNI ile şimdilik bu kadar. Devamı çok yakında…