Bir Ürüncü Gözünden S.O.L.I.D. Prensipleri

Berkay Vuran
4 min readDec 19, 2022

--

İş yapmanın pek çok yolu vardır. Bu yolların bazıları etkililiğe, bazıları verimliliğe, bazıları kurumsal gelişime; bazıları sürece, bazıları sonuca, bazıları politikalara odaklıdır. Bir de bir işi yapmanın -bağlamına göre- ‘en iyi’ yolu vardır. Endüstriyel psikoloji alanyazınında yer bulan ve 1880'lerde Taylor tarafından başlatılan ‘iş analizi’, bir işi yapmanın ‘en iyi’ yoluna odaklanır.

Bu yazı kapsamında yazılım geliştirme sürecinde ‘en iyi yol’lardan biri olan S.O.L.I.D. prensiplerini bir ürün meraklısı bakış açısıyla yorumlayacağım.

S.O.L.I.D. Nedir?

SOLID yazılım prensipleri; geliştirilen yazılımın esnek, yeniden kullanılabilir, sürdürülebilir ve anlaşılır olmasını sağlayan, kod tekrarını önleyen ve Robert C. Martin tarafından öne sürülen prensipler bütünüdür. Kısaltması Michael Feathers tarafından tanımlanan bu prensiplerin amacı;

Geliştirdiğimiz yazılımın gelecekte gereksinimlere kolayca adapte olması,

Yeni özellikleri kodda bir değişikliğe gerek kalmadan kolayca ekleyebileceğimiz

Yeni gereksinimlere karşın kodun üzerinde en az değişimi sağlaması,

Kod üzerinde sürekli düzeltme hatta yeniden yazma gibi sorunların yol açtığı zaman kaybını da minimuma indirmektir.

Her ne kadar bazı ‘bitti tanımları’ olsa da, sürekli bir devinim içerisinde olan yazılım geliştirme yaşam döngüsündeki karmaşıklığın önüne geçilmesini sağlayan S.O.L.I.D., ‘etkili’ ve ‘verimli’ geliştirme süreçleri için bir optimizasyon anahtarıdır.

S.O.L.I.D., şu 5 ilkenin baş harflerinden oluşur: ‘Single-Responsibility Principle’, ‘Open-Closed Principle’, ‘Liskov-Substitution Principle’, ‘Interface Segregation Principle’ ve ‘Dependency Inversion Principle’. Bahsedildiği üzere etkililik ve verimlilik üzerine odaklanmış S.O.L.I.D. prensiplerinin yazılım geliştirme sürecindeki kullanımlarına sn. Gökhan Ayrancıoğlu’nun buradaki yazı dizisinden ulaşabilirsiniz.

— — Spoiler — —
Yazının bundan sonraki bölümünde tamamen ürüncü şapkasıyla ilerleyecek, IMHO yapacağım.
— — Spoiler — —

S — Single-Responsibility Principle

Geleneksel iş analizinin temel çıktısı ‘görev tanımı’ belirlemektir. Bu görev bazen bir kurumun, bazen bir insanın, bazen bir sınıfın görevidir. Birden fazla görevle bezenmiş çalışanların yaşadığı huzursuzluğu düşünün, bir benzeri birden fazla görevle bezenmiş classlar için de geçerlidir.

Bir sınıf (nesne) yalnızca bir amaç uğruna değiştirilebilir, o da o sınıfa yüklenen sorumluluktur, yani bir sınıfın (fonksiyona da indirgenebilir) yapması gereken yalnızca bir işi olması gerekir.

O — Open-Closed Principle

Bir ürün geliştirme yol haritasına paydaşları zor bela ikna edip aldığınız, yaklaşık 6 ayda SDLC döndüğünüz, günün sonunda kullanıcı yaşam tünelinizin temel boğumlarından gelen bir ürün geliştirdiğinizi düşünün. Şimdi de işler bu kadar tıkırında giderken bir başka geliştirmenin bu ürünü ezip geçtiğini… Ya da önemli geri bildirimlerle çıkardığınız fazlandırma çalışmasının bir noktadan sonra gerçekleştirilemediğini… Tam olarak böyle bir şey, open-closed principle ihlali.

Bir sınıf ya da fonksiyon halihazırda var olan özellikleri korumalı ve değişikliğe izin vermemelidir. Yani davranışını değiştirmiyor olmalı ve yeni özellikler kazanabiliyor olmalıdır.

L — Liskov Substitution Principle

Şimdiye kadar iş birimi bakış açısıyla yazılım geliştiren bir startupta ürüncü olarak göreve başladınız, görev ve sorumluluğunuz en doğru yönteme göre ürün geliştirme mimarisi oluşturmak. Ne yaparsınız? Elbette benchmarking, know-how aktarımı ve günün sonunda ‘standardizasyon’. Bir dünya düşünün, her bir epic için tüm mimariyi baştan kurguladığınız… Bir dünya düşünün, her bir mockup için nokta-çizgi düzeyinden çalışmaya başladığınız… İşte o dünyada ‘Lizkov Substitution Principle’ yok. Yukarıdan-aşağıya giden süreç, aşağıdan-yukarıya gidemiyor.

Kodlarımızda herhangi bir değişiklik yapmaya gerek duymadan alt sınıfları, türedikleri(üst) sınıfların yerine kullanabilmeliyiz.

I — Interface Segregation Principle

Diyelim ki bir insanın günlük yaşamında büyük yer kaplayan sorunlara çözümler geliştirmeyi amaçlayan bir ürün şirketindesiniz ve farz edin ki bu sorun ‘yatırım yapmak’ olsun. Yatırım yapmak isteyen bir kullanıcının istek & ihtiyaç ve yetkinliklerini düşünün: Legal sorumluluklar, finans, teknoloji; bir yandan şirketle ilgili pazarlama, geliştirme, muhasebe, İK… Bütün bu fonksiyonları tek bir çizelgeden ve tek bir Slack kanalından ilerletmeye çalışın: Olmuyor değil mi… Yazılım geliştirirken de olmuyor, -olmamalı-.

Sorumlulukların hepsini tek bir arayüze toplamak yerine daha özelleştirilmiş birden fazla arayüz oluşturmalıyız.

D — Dependency Inversion Principle

Mutlaka denk gelmişsinizdir: Birisi bir projeden & ürün geliştirmeden & şirketten ayrılır ve bir anda Jenga oyununun sonu gelmişçesine bir kaos hakim olur. Sebebi nedir: genellikle ‘kilit ve somut rol’ler. Bu kilit ve somut roller işe ilişkin bilgiyi emer ve katı bir şekilde tutarlar. Aynı katılıkla bezeli çalışan da bu bilgiyi yedeklemez veya aktarmazsa günün sonunda sonuç hüsran olur. Bilgisel düzeydeki bağlılık da en az bu denli risklidir, esneklik ve hatta gevşeklik belli kurallar dahilinde kesinlikle katılıktan yeğdir.

Sınıflar arası bağımlılıklar olabildiğince az olmalıdır özellikle üst seviye sınıflar alt seviye sınıflara bağımlı olmamalıdır.

Son not: Bu çalışma bir ‘geliştirici’ tarafından gerçekleştirilmemiş olup hiçbir bilgi içerdiği iddiasında değildir. Sadece kişisel görüşlerden ibarettir.

--

--