SOLID-DRY-KISS Yazılım Geliştirme Prensipleri

3 min readSep 5, 2021

Yazılım geliştiriciler olarak mesleki felsefemizi oluşturan ve “Spagetti Kod” yerine “Temiz Kod” yazabilmemizi sağlayan prensipler vardır. Fakat nitelikli yazılım geliştirici olmak için bu prensiplerin yalnızca teoride bilinmesi yeterli değildir. Pratiğe dökerek, geliştirdiğimiz her yazılımda bu prensipleri göz önünde bulundurmamız gerekir. Çünkü sadece makinelerin anlayabileceği değil, insanların da anlayabileceği şekilde kod yazabilmesi bir yazılım geliştiricinin işini kaliteli ve doğru yaptığının göstergesidir. Bu sebeple yazılım geliştirilirken SOLID-DRY-KISS yazılım geliştirme prensipleri göz önünde bulundurularak sürdürülebilir, tekrar kullanılabilir, test edilebilir ve kolay okunabilir kod yapısı oluşturulmalıdır.

SOLID

Single Responsibility Principle (Tek Sorumluluk Prensibi)

Geliştirilen bir yazılımda herhangi bir güncelleme yapılmak istendiğinde “Bunu değiştirirsem hangisi etkilenir?” sorusunu sormaya gerek duymadan özgürce güncelleme yapılabilmesi için uygulanması gereken prensiptir.

Her fonksiyonun yalnızca bir işi yapması gerekir. Örneğin “process” adında bir fonksiyon oluşturup ekleme, güncelleme ve silme işlemlerinin hepsini bu fonksiyonun içine yazmak yerine “add”, “update” ve “delete” olarak farklı fonksiyonlar kullanılması gerekir. Böylelikle herhangi bir kod yapısında güncelleme yapılması gerektiğinde diğer fonksiyonlara dokunulmadan yalnızca ilgili fonksiyon güncellenebilir. Bu durum yazılım geliştiricilere hem zaman tasarrufu hem de kolay okunabilir kod yapısı sağlar.

Open/Closed Principle (Açık/Kapalı Prensibi)

Geliştirilen yazılımdaki nesnelerin geliştirmeye açık ama değişime kapalı olması gerekir. Yazılımda herhangi bir güncelleme yapılması durumunda temel nesnenin değişime kapalı tutulması gerekir.

Bir nesne ek özellik kazandıysa bu nesne genişletilebilir fakat temel nesne değiştirilmemelidir. Örneğin kullanıcıların temel bilgilerinin alınabileceği “BaseUser” sınıfı oluşturulup, kullanıcının iletişim bilgilerinin alınabileceği “ContactUser” sınıfı oluşturarak, “BaseUser” sınıfını “ContactUser : BaseUser” şeklinde genişletebiliriz. Bu yapıda temel nesne değiştirilmemektedir, yalnızca genişletilmektedir.

Liskov’s Substitution Principle (Liskov’un İkame “Yerine Geçme” Prensibi)

Miras alarak türemiş olan sınıfların önce miras aldıkları nesnenin tüm özelliklerini kullanması, sonra da kendi özelliklerini barındırması gerekir. Eğer oluşturulan sınıf, miras aldığı nesnenin tüm özelliklerini kullanmazsa ortaya gereksiz kod blokları çıkar. “Temiz Kod” yazılabilmesi için gereklidir.

Interface Segregation Principle (Arayüz Ayrıştırma Prensibi)

Bir arayüze gereğinden fazla iş yüklemek yerine bu işler için birden fazla arayüzler oluşturulmalıdır. Bu prensibin amacı nesnelere, ihtiyacı olmayan özellik veya fonksiyonlar içeren arayüz uygulamamaktır.

Tek Sorumluluk Prensibi’nden farkı, Tek Sorumluluk Prensibi sınıflar hakkında bir prensiptir.

Dependency Inversion Principle (Bağımlılık Tersine Çevirme Prensibi)

Alt sınıfların üst sınıfları etkilememesi, sınıflar arasındaki bağımlılıkların olabildiğince az olması gerekir. Özellikle yüksek seviyeli sınıflar, düşük seviyeli sınıflara bağlı olmamalıdır. Her ikisi de soyut kavramlara bağlı olmalıdır. Örneğin insan kaynakları yönetim sistemi geliştirilirken kullanıcı bilgilerinin tutulduğu “User” sınıfı soyut bir sınıf olarak “Employee” sınıfına genişletilmelidir. Böylelikle sınıflar arası bağımlılık azalır.

DRY — Don’t Repeat Yourself (Kendini Tekrar Etme)

Kod yapılarında tekrara düşmek “Temiz Kod” açısından düşünüldüğünde önemli bir hatadır. Özellikle fonksiyonların sürekli kendini tekrar etmesi kod yapısını karmaşıklaştırmakta ve zaman kaybı ortaya çıkarmaktadır. Bu sebeple kod yazarken ürettiğiniz çözümün daha önce ürettiğiniz bir çözüme benzediğini düşünüyorsanız, iki benzer çözüm yerine o çözümü yeniden kullanılabilir hale getirmeniz daha uygun olacaktır.

Kod yapılarında tekrara düşmemek okunabilirlik açısından da önemlidir. Örneğin admin paneli geliştirilirken her sayfaya “header” ve “footer” kodlarını yapıştırmak yerine “header” ve “footer” yapılarını ayrı dosyalar şeklinde oluşturarak bu yapıların okunabilirliğini artırmak gerekir.

KISS — Keep It Simple, Stupid (Basit Tut, Aptal)

Basit, karmaşıktan daha zor olabilir.
Steve Jobs

Zor olanın basitleştirmek (sadeleştirmek) olduğunu anlayabilen yazılım geliştiricilerin bu prensibi göz önünde bulundurması gerekir. Karmaşık çözümler, dışarıdan bakan bir yazılım geliştiricinin anlayabileceği şekilde basitleştirilmelidir. Özellikle çevik yazılım geliştirebilmek için çözümleri basitleştirebilmek önemlidir.

Not: Farklı kaynaklarda bu prensibin adının farklı versiyonları da kullanılabilir.

Yazılım geliştiricilerin yazılım geliştirirken uygulaması gereken SOLID-DRY-KISS yazılım geliştirme prensiplerini anlattım. Aslında yazılım geliştirme prensiplerinin temel amacı, bir yazılım projesinde yazılım geliştiricilerin kendilerinden sonra gelen yazılım geliştiricilerin de yazılan kod yapılarını kolay bir şekilde anlayabilmelerini ve ek bir özellik istendiğinde geliştirilen yazılımın kolay bir şekilde güncellenebilmesini sağlamaktır.

Sürdürülebilir, tekrar kullanılabilir, test edilebilir ve kolay okunabilir “Temiz Kod” yazabilmek için yazılım geliştirme prensiplerini uygulamayı unutmayın.

Kaynakça