Kalite#1 — Yazılımda prensipler, kalite, sadelik gerçekten önemli mi? Yoksa sadece gereksiz bürokrasi mi?
İş görüşmelerinde sık sık karşılaştığım sorulardan biri SOLID prensipleridir. Bize SOLID’in D’sini açıklayabilir misin? Açıklarım açıklamasına ama siz gerçekten bunları kullanıyor musunuz diye sorasım geliyor her defasında. Peki gerçekten sadece iş görüşmelerinde iyi yazılımcıyı kötüsünden ayırt etmek için mi geliştirildi bu prensipler?
Tabiki hayır. Ülkemizde kötü yazılımların acısı yeni yeni keşfedilirken bunu daha önce yaşayanlar aynı acıyı bir daha yaşamamak için edindikleri tecrübelerden bazı dersler çıkarmışlar. İşte bu yazının konusu da bu derslerden faydalanabilme konusunda bir farkındalık oluşturabilmek.
SOLID veya diğer yazılım prensiplerini ve bunların tasarım şablonlarını (Design patterns) daha sonra yazmaya çalışacağım. Burada esas anlatmak istediğim kaliteli yazılım ile kalitesiz yazılım arasındaki farkı belirleyen ana etmenleri izah etmek.
Software was invented because we needed a way to quickly and easily change the behaviour of machines. (1)
Evet yazılımın icadı makinaların davranışlarını daha kolay (soft) bir şekilde değiştirebilmeyi amaçlar aslında. Yani her bir değişiklik için donanımsal değişiklik yapmaktansa yazılımsal değişikliklerle davranışları yönetmek çok daha kolay olacaktır.
Peki gerçekten öyle mi? Bugüne kadar bir şekilde birlikte çalıştığım birçok şirkette yazılım değişiklik döngüleri çok maliyetliydi. Bunun bir çok sebebi var tabiki. Ama ben daha çok yazılım kalitesine önem verilmemesi kısmına odaklanmak istiyorum. Kendisinden beklenen davranışı gerçekleştiren bir yazılım geliştirmek tek başına yeterli midir? Yoksa zaman içerisinde artan maliyetleri de hesaba katmak gerekmez mi? Yani iyi bir yazılım bizim için sadece beklenen davranışı sergileyen yazılım değildir. Aynı zamanda bu işlevi makul sayılabilecek sınırlar içerisinde ve sürdürülebilir bir şekilde yapması gerekir. Bu konuda üstad olarak gördüğüm Robert Martin’in iyi bir mimari ile ilgili tanımı bence gayet yeterli:
The primary purpose of architecture is to support the life cycle of the system. Good architecture makes the system easy to understand, easy to develop, easy to maintain, and easy to deploy. The ultimate goal is to minimize the lifetime cost of the system and to maximize programmer productivity. (1)
İyi bir mimari kolay anlaşılır, kolay geliştirilebilir, kolay bakım yapılabilir ve kolaylıkla yaygınlaştırılabilir olmalıdır. Bu kavramların hemen hepsi birbiri ile bağlantılır zaten. Bir kod parçasını kolaylıkla değiştirebilmek istiyorsak önce onu anlamamız lazım. Veya değiştirdiğimiz kodu sisteme yansıtmak her defasında çok ciddi problemlere sebep olmamalıdır.
Yazılım hayat döngüsüne baktığımızda yazılım geliştirmenin işin sadece bir kısmını oluşturduğunu görürüz. Dolayısı ile yazılım, bir yaşam döngüsüne sahip uzun süre kullanılması amaçlanan önemli bir yatırımdır. Yatırım sözcüğünü bilerek kullandım. Çünkü şirketlerin yazılımları için ne kadar çok maliyetlere katlandıklarının farkında olmamız ve bu maliyetleri kontrol altında tutmamız lazım. İşte başta yazılım mimarları olmak üzere tüm yazılım geliştiricilerin görevlerinden biri budur.
Kısaca yazılım kalitesi ile ilgili aklımdan geçenleri aktarmaya çalıştım. Bundan sonraki yazılarımı da vakit buldukça bu eksende yazmaya çalışacağım.
(1) Robert C. Martin, Clean Architecture
