Yazılım geliştirirken karşılaştığımız problemler ya da karşılamamız gereken ihtiyaçlar ne kadar farklı olsada, bir noktada bu problem ve ihtiyaçlara bakış açısı ortak hale geliyor. Belli kalite özelliklerini korumak ve katma değer katan çözümler oluşturabilmek için bu ortak nokta da prensipler ile karşılaşıyoruz. Bir kaç önceki yazımda ortaya atılan bu prensiplerden bahsetmeye başlamıştım. Şimdi bir kaç tanesinden daha bahsetmek istiyorum.

DRY – Don’t Repeat Yourself

Geliştirdiğimiz yazılımlarda, -hatta biraz daha derine girim; sınıflarda/metodlarda asıl katma değeri oluştururuz. Yani temelinde, bir metod içerisindeki yazdığımız algoritma ya da oluşturduğumuz obje modeli karşılamamız gereken ihtiyacın ya da çözülmesi gereken problemin cevabıdır. Çözmeye çalıştığımız problemler büyüdükçe ve karmaşık hale geldikçe, daha önce kullanmış olduğumuz cevapları tekrar kullanmaya başlarız. Bu noktada DRY prensibi dur der. Kendini tekrarlama diye karşımıza çıkar.

Geliştirdiğimiz yazılımlarda, çözüm olarak oluşturduğumuz yapıların yazılım içerisinde tek bir tane olması gereklidir.  Bunun önüne geçemezsek, bir problem için, aynı çözümün birden fazla versiyonu kodun içerisinde kendine yer bulur… Gelişir, gelişir, büyür ve kodun bakımını zorlaştırır. E-mail validasyonu yapan bir yapı ile aynı validasyonun daha farklı bir string operasyonu ile yapılıyor olması, yazılım içinde de tutarsızlığa yol açar. Sonra uğraş dur…

Kod yazarken, daha önce benzer bir çözüme benzediğini düşüyorsanız, o çözümü re-use edilebilecek hale getirmek en uygunu olacaktır.  DRY prensibini uygulamak için code-generation araçları ve kod dökümantasyonu oluşturan araçlardan faydalanmak kolaylık sağlayacaktır. Referans kitabı olarak arasıra danıştığım, David Thomas-Andrew Hunt ikilisinin yazdığı, The Pragmatic Programmer kitabını DRY prensibi ile ilgili olarak şiddetle tavsiye ederim. Uygulanabilirliği konusunda güzel ip uçları içermekte.

SoC – Seperation Of Concerns

SoC, yazılımdaki elemanların kendilerine özel olmasını, sorumluluklarının kendilerine ait olup, başka elemanlar ile paylaşmamasını söyler. Sorumlulukların ayrı olmasının gerekliliği bu prensibin altını çizdiği temel noktadır.  Yazılımı geliştirirken, “sınır” diyebileceğimiz kavramlar bu sorumlulukları bir birinden ayıran en net ifadeler olabilir. En basitinden, layer ve tier kavramları ile belli sorumlulukları bir birinden ayırırız. Birazcık daha içeri girersek, yazılım bileşenlerimizin namespace’leri de, sorumlulukları ayırmak için kullanabileceğimiz sınırlardır diyebiliriz.

Genelde bu sorumlulukları belirlerken, çok küçük parçalara kadar inmeye çalışırız. Çok küçük parçalardan daha önemli olan sorumluluk kümelerinin net ve ayrı olabilmesidir. Einstein’nın bir lafı vardır çok hoşuma giden,  “Make everything as simple as possible, but not simpler.” Her şeyi basit yap ama daha basit yapma…Benzer şekilde sorumlulukları küçük parçalara ayır ama daha da küçültme şeklinde bu konu için yorumlayabilirim. Sorumluluk kümelerini iyi oluşturamazsak, ayrık ayrık bir sürü parça sistemde kaybolur gider. Bu da çok iyi bir şey değil.

Yazılım içindeki bileşenlerin bir birine bağlılık derecesi(coupling) ve bileşenler içerisindeki sorumluluk ilişksi(cohesion), SoC prensibi için önemli iki kavramdır. Bileşenlerin bağlılık derecesinin düşük olması ve bir bileşen içindeki sorumluluk ilişkisinin yüksek olması her zaman tercih edilmelidir. Yani low-coupling, high-cohesion olmazsa olmaz… Bu sayede bağlılık derecesi düşük olursa, sorumlulukar bileşen başına dağılmış olacağından yazılımın kontrolü bizim elimizde daha kolay olacaktır.  Bileşenler içerisindeki sorumluluklarında bir birlerine yakın olması, re-usebility’i ortaya çıkaracaktır.

SoC prensibi, geliştirdiğimiz yazılımları genişletebilir yapabilmenin de en önemli noktasıdır. Sorumlulukları ve bağlılıkları iyi ayırabilmeyi söylediğinden dolayı, yazılımlarımızın esnek ve genişleyebilecek alt yapıda olmasına ön ayak olur.

Bu iki önemli prensip de yazılım geliştirmede oldukça önemli konuların altını çiziyor. Pratik olarak zaman zaman dikkat etmesi zor olsa da, gerçekleştirildiği takdirde oldukça faydalı sonuç vereceklerdir.

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….

KISS – 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…