KISS, YAGNI, DRY ve Soc –> Her developerin bilmesi gereken kısaltmalar

Merhaba’lar,

Yazılımı ilk öğrenirken kabaca kodlar yazmışızdır. Sonra başkalarının yönlendirmeleri ile algoritmalarımızı, kodumuzu yontmaya çalışmışızdır. Bir süre sonra ise şu tasarım deseni, şu yazılım prensibine göre kodumuzu yazmamız gerekiyor deriz. İşte bu yazımızda bizde artık yazılım prensiblerine gireceğiz.

DRY – Don’t Repeat Yourself

Bu prensibimizin ana düşüncesi kodun asla tekrar etmemelidir.

Geliştirdiğimiz yazılımlarda, -hatta biraz daha derine girersek; sınıflarda/metodlarda bütün işlerimizi halletmekteyiz. 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 problemi cevaplamaktadı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üşünüyorsanız, o çözümü re-use edilebilecek hale getirmek en uygunu olacaktır.

Referans kitabı isterseniz, David Thomas-Andrew Hunt ikilisinin yazdığı, The Pragmatic Programmer kitabını DRY prensibi ile ilgili olarak şiddetle tavsiye ederim.

Örnek olarak;

DRY kullanılmayan bir kod parçacığı,

{!{code}!}czoyNzU6XCIvL2Zsb3cgQQ0KbGV0IHVzZXJuYW1lID0gZ2V0VXNlck5hbWUoKTsNCmxldCBlbWFpbCA9IGdldEVtYWlsKCk7DQpsZXR7WyYqJl19IHVzZXIgPSB7IHVzZXJuYW1lLCBlbWFpbCB9Ow0KY2xpZW50LnBvc3QodXNlcikudGhlbigvKmRvIHN0dWZmKi8pOw0KDQovL2Zsb3tbJiomXX13IEINCmxldCB1c2VybmFtZSA9IGdldFVzZXJOYW1lKCk7DQpsZXQgZW1haWwgPSBnZXRFbWFpbCgpOw0KbGV0IHVzZXIgPSB7IHVze1smKiZdfWVybmFtZSwgZW1haWwgfTsNCmNsaWVudC5nZXQodXNlcikudGhlbigvKmRvIHN0dWZmKi8pO1wiO3tbJiomXX0={!{/code}!}

DRY kullanılan bir kod parçacığı,

{!{code}!}czoxODU6XCJnZXRVc2VyKCl7DQoJcmV0dXJuIHsNCgkJdXNlcjpnZXRVc2VyTmFtZSgpOw0KCQlwYXNzd29yZDpnZXRQYXNzd29yZCh7WyYqJl19KTsNCgl9DQp9DQovL2Zsb3cgQQ0KY2xpZW50LnBvc3QoZ2V0VXNlcigpKS50aGVuKC8qZG8gc3R1ZmYqLyk7DQovL2Zsb3cgQg0KY3tbJiomXX1saWVudC5nZXQoZ2V0VXNlcigpKS50aGVuKC8qZG8gc3R1ZmYqLyk7XCI7e1smKiZdfQ=={!{/code}!}

Andrew Hunt ve David Thomas, “The Pragmatic Programmer” adlı kitaplarında bu prensipten şöyle söz etmişlerdir:

Bir sistem içinde bilginin her bir parçası tek, kesin ve güvenilir olmalıdır.

Diğer bir deyişle:

Sistemin fonksiyonel davranışları, kodun tek bir parçası içerisinde tutulmaya çalışılmalıdır.

KISS – Keep It Simple, Stupid

Yukardaki resim ‘in sonucundan çok önemli olan sizin kafanızı karıştırmak için işlemler yapılması. Aslında soldaki işlemde sağdaki işlemde aynı kapıya çıkıyor.

Bu prensibin ana düşüncesi Gereksiz karmaşıklıktan uzak durarak, yazdığımız kodun bizden sonrakilerin kolaylıkla anlayabilmesini/geliştirebilmesini sağlamasıdır. Kısaca KISS, basitlik ve sadeliğin altını çizen yazılım geliştirme prensibidir.

Bu ifade Kelly Johnson tarafından kullanılmıştır ve şöyle bir açıklama getirmiştir:

Eğer sistemlerinizi kompleks yapmak yerine onları daha basit tutarsanız sisteminiz en iyi şekilde çalışacaktır. Bu nedenle tasarımda hedef nokta basitlik olmalı ve gereksiz karmaşıklıktan kaçınılmalıdır

Basitlik, kulağa olumsuz bir durummuş gibi gelse de, karmaşık problemleri çözmek adına çoğu zaman çok kritik bir ihtiyaç haline gelebiliyor. 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 KISS. 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 / Buna İhtiyacın Olmayacak

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çınmakta her zaman fayda olacaktır.

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.