Merhaba sevgili yazılımperver dostlarım, bu yazımda, yazılımcıların vakıf olması gereken bir hususa değinmeye çalışacağım.

Bu husus temelinde çok karmaşık olmasa da, uygulamaya gelince bazen gözden kaçıyor olabilir. Bunu zaten uyguluyor da olabilirsiniz ama bundan haberdar olmak her zaman için sizlere faydalı olacaktır. Aslında bakarsanız, buna benzer ve oldukça önemli olan  bir  takım prensiplere (SOLID), önceki yazılarımda değinmiştim. Eğer onları okumadıysanız, muhakkak bir göz atın lütfen:

1. SOLID 1 – Tek Sorumluluk Prensibi
2. SOLID 2 – Açık/Kapalı Prensibi
3. SOLID 3 – “Liskov Substitution” Prensibi
4. SOLID 4 – Arayüz Ayrıştırma Prensibi
5. SOLID 5 – Bağımlılıkların Ters Çevrilmesi Prensibi

Daha fazla oyalanmadan, ilk prensibimiz ile başlayalım: Don’t Repeat Yourself

DRY (Don’t Repeat Yourself) nedir?

Kısaca, bu prensibin altında yatan temel husus, olabildiğince kod çoklamasından/tekrarından kaçınmak ve tekrar kullanımı arttırmaktır. Velev ki yapmadık, bunun bize ne zararı olabilir peki?

• Öncelikle bakım maliyetini arttırı ve idameyi zorlaştırır (ardınızdan gelen yazılımcı dostlarınız kulaklarınızı hayırla çınlatırlar :)),
• Kod kalitesini düşürür,
• Kod değişikliklerinde/güncellemelerinde, hatalı ve uyumsuz durumların ortaya çıkmasına sebebiyet verir,
• Yazılımın uyarlanmasını ve genişlemesini engeller,
• Güncelleme ve yayınlama sürelerini uzatır.

Burada, önceki yazılarımda da çok değindiğim Robert C. Martin’in bir sözünü sizler ile paylaşmadan edemeyeceğim:

“Duplication may be the root of all evil in software.”

Yani,

Kod tekrarı/çoklama, yazılımdaki bütün şeytanlıkların köküdür.

Peki, neden böyle bir durum ortaya çıkıyor?

• Kopyala yapıştır 🙂
• Büyük uygulamalarda, farklı yazılımcılar ya da aynı yazılımcı, unutup benzer kabiliyeti kodlarsa,
• Farklı sınıf ya da fonksiyonlar zamanla, birbirlerinin yaptığı işlevleri içerecek şekilde büyürse,
• Yazılım mimarisinde/tasarımında sıkıntıları olması,

bu tarz durumlar ortaya çıkabilmekte. Kaynak veya niyet ne olursa olsun, sonuçta elimizde, tekrarlanan kodlar olmaktadır.

Peki bu durum nasıl ortaya çıkıyor?

Örneğin, fonksiyon seviyesinde, eğer bir işlevi yapan aynı satırları birden fazla yerde kullanıyorsanız bunu ayrı bir fonksiyona taşıyıp, ilgili yerlerde bu fonksiyonu çağırabilirsiniz. Ya da aynı işlevi farklı tipler için yaptığınızı fark ettiğinizde, “template” kullanımına yönelebilirsiniz. Benzer şekilde, benzer unsurları ifade eden sınıflar, veri yapıları kullandığınızı fark ettiyseniz bunları ortaklamaya kafa yormalısınız (eğer tasarım aşamasında yormadıysanız, tasarımınızı gözden geçirmelisiniz). Ayrıca, özellikle if/else tarzı koşulları içeren kodlarda da, tekrar ile karşılaşılabilmektedir. Bu durumda, if/else ya da switch yerine, nesne yönelimli yazılım pratiklerini kullanabilirsiniz.

Peki bunu nasıl önleriz, ne yapabiliriz?

Bunu farklı seviyelerde ele alabiliriz ama her ne olursa olsun, öncelikle, sürekli olarak geliştirdiğiniz yazılımı ve kodları gözden geçiriyor ve güncelliyor olmamız gerekiyor. Refaktör yapmaktan korkmamalıyız (Martin Fowler’ın Refactoring kitabını muhakkak okuyun). Sonrasında ise, sınıflarımızı, fonksiyonlarımızı olabildiğince, mantıksal olarak küçük parçalara ayırmalıyız. Buna aykırı bir husus görür görmez, hemen gecikmeden bunu düzeltmeliyiz.

Başta sizler ile paylaştığım SOLID prensiplerinden SRP, “Single Responsibility Principle”‘na uymak da kod tekrarının önüne geçmenize yardımcı olacaktır.

Şu ana kadar hep kaynak kodtan bahsetsek de, aslında kod çoklamanın altında yatan sebeplerin çoğu, doğru bir soyutlama yapılmamasından ötürü ortaya çıkmaktadır. Bu sebeple, tekrar eden unsurular ya da kavramlar doğru bir şekilde soyutlanmalıdır. Bunun ile birlikte, yazılımınız geliştirmeden önce, uygulamanızın mimarisine kafa yormak, çok karmaşık bir tasarımdansa, daha basit ve genişleyebilir bir mimari takip etmek de, kod çoklaması ve benzeri durumların oluşmasına engel olacaktır.

DRY prensibi doğrultusunda dikkat etmemiz gereken son husus da, olabildiğince tekerleği tekrar icat etmekten kaçınmamız (bunun da elbette bir kaç istisnası olabilir değineceğim).

Artık, internet üzerinde, erişebileceğiniz ve uygulamalarınızda kullanabileceğiniz bir çok kütüphane ve koda erişmeniz mümkün. Elbette, bunları gözü kapalı bir şekilde, hiç bir şeye dikkat etmeden alıp kullanmak çok doğru olmasa da, kullanmamak da doğru olmayabilir. Özellikle, geniş bir kullanıcı kitlesine sahip ve olgun kütüphaneleri kullanmak, hem size zaman kazandıracak hem de uygulamanızda ortaya çıkabilecek (kullanmak yerine sizin yazmanız durumunda) hataları azaltacaktır. Aşağıda, C++ için özellikle başvurabileceğiniz kaynakları sıraladım, ayrıca C++ kaynaklarının bulunduğu sayfama da göz atabilirsiniz.

• Boost C++ Kütüphaneleri (https://www.boost.org/ )
• POCO Kütüphaneleri, (https://pocoproject.org/)
• Google’s Abseil (https://abseil.io/)
• Folly, Facebook Open-source Kütüphanesi (https://github.com/facebook/folly)
• Electronic Art Standar Template Library (EASTL) (https://github.com/electronicarts/EASTL)
• Bloomberg’s BDE Kütüphaneleri (https://github.com/bloomberg/bde)
• https://www.yazilimperver.com/index.php/kutuphaneler/

Peki hangi durumlarda tekrar kullanımı tercih etmeyebiliriz? Bir konu ya da kavramı öğrenmek istiyorsanız, teknik mülakatlara hazırlanıyorsanız 🙂 ya da özel bir donanıma yazılım geliştiriyorsanız, bu kuralı biraz esnetebilirsiniz. O durumda, bile yazdıktan sonra karşılaştırmak anlamında bu kütüphanelere başvurabilirsiniz.

Yazımı kapatmadan, peki gerçekten kod çoklamasından kurtuldum mu? Ya da bu sıkıntıdan ne kadar müzdaribimi ölçebilir miyiz? Evet, SonarQube tarzı statik kod analiz araçları sizlere bu konuda yardımcı olabilir ama en önemli kontrol bence şu olmalı: eğer yazılımda bulunan bir elemana/bileşene ilişkin değişiklik yaptığınızda, mantıksal olarak bu bileşen ile ilgili olmayan kısımlarda değişiklik gerekmiyorsa ve sadce bir değişiklik yeterli oluyorsa, doğru yolda olduğunuza dair iyi bir işaret olarak kabul edebiliriniz.

Bir sonraki yazımda görüşmek dileğiyle, kendinize çok iyi bakın sevgili yazılımperver dostlarım.