Temiz Kod ve Genel Olarak Yazılımda Bazı Kavramlar/İlkeler 1
Selamlar,
Temiz Kod(Clean Code), yazılım veya refactoring tarzı kitapları okuduğunuzda bazı genel kavramlar/prensipler önümüze çıkar. Bu yazıda onlara değinmek istiyorum. Birçok kaynakta bunlara rastlayabilirsiniz ama en son okuduğum kitapta daha derli toplu bir şekilde bahsedilmiş. Clean Code Cookbook kitabının orjinali şuradan bulabilirsiniz.
Object Reification(Nesnelerin Somutlaştırılması)
Nesnenin somutlaştırılması, soyut bir kavram veya fikrin, veri odaklı nesnelere davranış sağlayan somut bir biçime kavuşturulduğu bir süreçtir. Nesnelerin yaratılması yoluyla soyut kavramlara somut bir biçim vererek, bu kavramları sistematik ve yapılandırılmış bir şekilde işleyebilir ve onlarla çalışabilirsiniz.
Fail Fast Principle(Hızlı Başarısızlık İlkesi)
Hızlı başarısız olma ilkesi, bir hata olduğunda onu görmezden gelip daha sonra bunun sonucunda başarısızlığa uğramak yerine, mümkün olan en erken zamanda yürütmeyi durdurmanız gerektiğini belirtir.
Encapsulation(Kapsülleme)
Kapsülleme, bir nesnenin sorumluluklarını korumayı ifade eder. Bunu genellikle gerçek uygulamayı soyutlayarak başarabilirsiniz. Ayrıca bir nesnenin metodlarına erişimi kontrol etmenin bir yolunu da sağlar. Birçok programlama dilinde, bir nesnenin alanlarının(fields) ve metodlarının görünürlüğünü belirtmek mümkündür; bu, programın diğer bölümleri tarafından erişilip erişilemeyeceğini veya değiştirilip değiştirilemeyeceğini belirler. Bu, geliştiricilerin bir nesnenin dahili uygulama ayrıntılarını gizlemesine ve yalnızca programın diğer bölümlerinin kullanması için gerekli olan davranışı ortaya çıkarmasına olanak tanır.
Essence and Accident(Öz/Temel ve Kazara)
Bilgisayar bilimcisi Fred Brooks, The Mythical Man-Month adlı kitabında, Aristoteles’in tanımını kullanarak yazılım mühendisliğindeki iki farklı karmaşıklık türüne atıfta bulunmak için “kazara” ve “temel” terimlerini kullanır.
“Temel” karmaşıklık, çözülen problemin doğasında vardır ve sistemin amaçlandığı gibi çalışması ve gerçek dünyada mevcut olması için gerekli olan karmaşıklık olduğu için kaçınılmazdır. Örneğin, bir uzay iniş sisteminin karmaşıklığı, bir keşif aracını güvenli bir şekilde indirmek için gerekli olduğu için temeldir.
“Kazara” karmaşıklık, çözülen problemin doğasından ziyade sistemin tasarlanma ve uygulanma biçiminden kaynaklanır. İyi tasarımlar oluşturarak azaltılabilir. Gereksiz kazara karmaşıklık, yazılımdaki en büyük sorunlardan biridir ve bu kitapta birçok çözüm bulacaksınız.
Ripple Effect(Dalga Etkisi)
Dalga etkisi, bir sistemin bir bölümünde yapılan bir değişikliğin veya modifikasyonun sistemin diğer bölümlerinde beklenmeyen sonuçlara yol açabilmesi anlamına gelir. Belirli bir nesnede değişiklik yaparsanız, bu değişiklik potansiyel olarak ona bağlı olan sistemin diğer bölümlerini etkileyebilir. Bu, sistemin diğer bölümlerinde hatalara veya beklenmeyen davranışlara yol açabilir.
“Tell, Don’t Ask” Principle(“Söyle, Sorma” İlkesi)
“Söyle, sorma” ilkesi, nesnelerin verilerini istemek yerine metodlarını çağırarak onlarla etkileşime girmenin bir yolunu tanımlar.
Information Hiding(Bilgi Gizleme)
Bilgi gizleme, bir yazılım sisteminin karmaşıklığını, iç işleyişini dış arayüzünden ayırarak azaltmayı amaçlar. Bu, bir sistemin iç yapısının, diğer sistemler veya kullanıcılar tarafından kullanılma biçimini etkilemeden değiştirmesine olanak tanır.
Demeter’s Law(Demeter Yasası)
Demeter Yasası, bir nesnenin yalnızca yakın komşularıyla iletişim kurması gerektiğini ve diğer nesnelerin iç işleyişini bilmemesi gerektiğini belirten bir ilkedir. Demeter Yasası’nı desteklemek için, birbirlerine çok bağımlı olmayan, yani gevşek bir şekilde bağlı(loosely coupled) nesneler yaratmanız gerekir. Bu, bir nesnedeki değişikliklerin diğer nesneler üzerinde istenmeyen sonuçlar doğurma olasılığı daha düşük olduğundan sistemi daha esnek ve bakımı daha kolay hale getirir.
Cohesion(Uyumluluk/Tutarlılık)
Tutarlılık/Uyumluluk, tek bir yazılım sınıfı veya modülündeki öğelerin tek ve iyi tanımlanmış bir amaca ulaşmak için birlikte çalışma derecesinin bir ölçüsüdür. Nesnelerin birbirleriyle ve modülün genel hedefine ne kadar yakından ilişkili olduğunu ifade eder. Yüksek tutarlılığı, yazılım tasarımında istenen bir özellik olarak görebilirsiniz.
No Silver Bullet(Her İşi Yapan Sihirli Bir Değnek Yok)
“Sihirli Değnek Yok” kavramı, bilgisayar bilimci ve yazılım mühendisliği öncüsü Fred Brooks’un 1986 tarihli “No Silver Bullet: Essence and Accidents of Software Engineering” adlı makalesinde ortaya attığı bir ifadedir. Brooks, tüm sorunları çözebilecek veya yazılım geliştirmenin üretkenliğini ve etkinliğini önemli ölçüde artırabilecek tek bir çözüm veya yaklaşım olmadığını savunur.
Rapid Prototyping(Hızlı Prototipleme)
Hızlı prototipleme, son kullanıcıyla doğrulamak için çalışan prototipleri hızla oluşturmak amacıyla ürün geliştirmede kullanılır. Bu teknik, tasarımcıların ve mühendislerin tutarlı, sağlam ve zarif temiz kod oluşturmadan önce bir tasarımı test etmelerine ve iyileştirmelerine olanak tanır.
Single-Responsibility Principle(Tek Sorumluluk İlkesi)
Tek sorumluluk ilkesi, bir yazılım sistemindeki her modül veya sınıfın, yazılım tarafından sağlanan işlevselliğin tek bir parçası üzerindeki sorumluluğa sahip olması gerektiğini ve bu sorumluluğun tamamen sınıf tarafından kapsanması gerektiğini belirtir. Başka bir deyişle, bir sınıfın değişmek için yalnızca bir nedeni olmalıdır.
Don’t Repeat Yourself Principle(Kendini Tekrarlama İlkesi)
Kendini Tekrarlama(Don’t Repeat Yourself, DRY) ilkesi, yazılım sistemlerinin kod tekrarından kaçınması gerektiğini belirtir. DRY ilkesinin amacı, çoğaltılmış bilgi, kod ve bilgi miktarını azaltarak yazılımın sürdürülebilirliğini, esnekliğini ve anlaşılabilirliğini iyileştirmektir.
SOLID Principles(SOLID İlkeleri)
SOLID, nesne yönelimli programlamanın beş ilkesini temsil eden bir kısaltmadır. Bunlar Robert Martin tarafından tanımlanmıştır ve katı kurallar değil, kılavuzlar ve sezgisel yöntemlerdir. Bunlar şunlardır:
- Single-responsibility principle(Tek sorumluluk ilkesi)
- Open-closed principle(Açık-kapalı ilkesi)
- Liskov substitution principle(Liskov ikamesi ilkesi)
- Interface segregation principle(Arayüz ayrımı ilkesi)
- Dependency inversion principle(Bağımlılık tersine çevirme ilkesi)
Test-Driven Development(Test-Yönelimli Geliştirme)
Test-yönelimli geliştirme (TDD), çok kısa bir geliştirme döngüsünün tekrarına dayanan bir yazılım geliştirme sürecidir. Önce geliştirici, istenen bir iyileştirmeyi veya yeni davranışı tanımlayan başarısız bir otomatik test case’ini yazar, ardından bu testi geçmek için asgari kodu üretir ve son olarak yeni kodu kabul edilebilir standartlara göre yeniden düzenler. TDD’nin temel hedeflerinden biri, iyi yapılandırılmış olmasını ve iyi tasarım ilkelerini izlemesini sağlayarak kodun bakımını kolaylaştırmaktır. Ayrıca, her yeni kod parçası yazılır yazılmaz test edildiğinden, geliştirme sürecinin başlarında hataları yakalamaya yardımcı olur.
Mutation Testing(Değişim Testi)
Mutasyon testi, birim(unit) testlerinizin kalitesini değerlendirmek için kullanabileceğiniz bir tekniktir. Test ettiğiniz koda küçük, kontrollü değişiklikler (mutasyonlar olarak adlandırılır) eklemeyi ve mevcut birim testlerinizin bu değişiklikleri tespit edip edemediğini kontrol etmeyi içerir. Ek testlere ihtiyaç duyduğunuz kod alanlarını belirlemenize yardımcı olabilir ve bunu mevcut testlerinizin kalitesinin bir ölçüsü olarak kullanabilirsiniz.
Mutasyon, kodun küçük bir bölümünü değiştirmekten (örneğin, bir boole değerini olumsuzlamak, bir aritmetik işlemi değiştirmek, bir değeri null ile değiştirmek vb.) ve herhangi bir testin başarısız olup olmadığını görmekten oluşur.
Software Linters(Yazılım Doğrulayıcıları)
Bir yazılım linter’ı, daha önce tanımlanmış sorunlar için kaynak kodunu otomatik olarak kontrol eder. Bir linter’ın amacı, düzeltmesi daha zor ve maliyetli hale gelmeden önce geliştirme sürecinin başlarında hataları yakalamanıza yardımcı olmaktır. Linter’ınızı, kodlama stili, adlandırma kuralları gibi çok çeşitli sorunları kontrol edecek şekilde yapılandırabilirsiniz. Çoğu linter’ı IDE’nizde eklenti olarak kullanabilirsiniz ve bunlar ayrıca CI/CD hattında adımlar olarak değer katabilirsiniz. ChatGPT, Bard ve diğerleri gibi birçok generative makine öğrenimi aracıyla da benzer sonuçları elde edebilirsiniz.
Continuous Integration and Continuous Deployment(CI/CD, Sürekli Entegrasyon ve Sürekli Dağıtım)
CI/CD (sürekli entegrasyon ve sürekli dağıtım) hattı(pipeline), yazılım geliştirme, test etme ve dağıtım sürecini otomatikleştirir. Hat, yazılım geliştirme sürecini kolaylaştırmak, görevleri otomatikleştirmek, kod kalitesini iyileştirmek, yeni özellikleri ve düzeltmeleri birçok farklı ortamda dağıtmayı daha hızlı ve daha yönetilebilir hale getirmek için tasarlanmıştır.
Object Essence(Nesnenin Özü)
Bir nesnenin özünü tanımlamak, ait olduğu domainin derinlemesine anlaşılmasını gerektirdiği için zorlayıcı olabilir. Bir davranışı kaldırabiliyorsanız ve nesne aynı şekilde davranmaya devam ediyorsa, kaldırılan davranış temel değildir. Özellikler davranışa bağlı olduğundan, aynı kuralı izleyeceklerdir. Bir araba rengini değiştirebilir ve aynı araba olacaktır, ancak modelini, seri numarasını vb. değiştirmek zor olacaktır. Ancak bu çok özneldir çünkü gerçek dünya da özneldir ve mühendislik böyle işler. Bu bir mühendislik sürecidir, bilimsel bir süreç değildir.
Shallow Copy(Sığ Kopyalama)
Sığ kopya, orijinal nesnenin depolandığı aynı bellek konumuna yeni bir referans oluşturan bir nesnenin kopyasıdır. Hem orijinal nesne hem de sığ kopyası aynı değerleri paylaşır. Birinin değerlerinde yaptığınız değişiklikler diğerine yansıtılır. Bunun yerine, derin kopya(deep copy), kendi özellikleri ve değerleriyle orijinal nesnenin tamamen bağımsız bir kopyasını oluşturur. Orijinal nesnenin özelliklerinde veya değerlerinde yaptığınız değişiklikler derin kopyayı etkilemez ve bunun tersi de geçerlidir.
Lazy Initialization(Tembel İlklendirme)
Tembel ilklendirme kullanarak bir nesnenin oluşturulmasını veya bir değerin hesaplanmasını, hemen yapmak yerine, gerçekten ihtiyaç duyulana kadar geciktirebilirsiniz. Bu, genellikle kaynak kullanımını optimize etmek ve ilklendirme sürecini mümkün olan son ana erteleyerek performansı iyileştirmek için kullanılır.
Antipatterns(Anti-desenler)
Bir yazılım antipattern’i, başlangıçta iyi bir fikir gibi görünebilen ancak nihayetinde olumsuz sonuçlara yol açan bir tasarım desenidir(kalıbıdır). Başlangıçta birçok uzman tarafından iyi çözümler olarak sunuldular ancak günümüzde bunların kullanımına karşı güçlü kanıtlar vardır.
The Principle of Least Surprise(En Az Sürpriz İlkesi)
En az sürpriz ilkesi, bir sistemin kullanıcıları için en az şaşırtıcı olan şekilde davranması gerektiğini söyler ve kullanıcıların beklentileriyle uyum gösterir. Bu ilkeyi izlerseniz, kullanıcı sistemle etkileşime girdiğinde ne olacağını kolayca tahmin edebilir. Bir geliştirici olarak, daha sezgisel ve kullanımı daha kolay yazılımlar yaratmalısınız, bu da kullanıcı memnuniyetini ve üretkenliğini artırır.
Referential Transparency(Referans Şeffaflığı)
Referans şeffaflık fonksiyonları, belirli bir girdi için her zaman aynı çıktıyı üretir. Global değişkenleri değiştirmek veya giriş-çıkış(I/O) işlemleri gerçekleştirmek gibi herhangi bir yan etkiye sahip değildir. Başka bir deyişle, bir fonksiyon veya ifade, programın davranışını değiştirmeden değerlendirilen sonucuyla değiştirilebiliyorsa referans olarak şeffaftır. Bu, fonksiyonların girdileri çıktılara eşleyen matematiksel ifadeler olarak ele alındığı fonksiyonel programlama paradigmalarında temel bir kavramdır.
Intention-Revealing(Niyeti Açığa Çıkarma)
Niyet-açıklayan kod, gelecekte kodunuzu okuyabilecek veya üzerinde çalışabilecek diğer geliştiricilere amacını veya niyetini açıkça iletir. Niyet-açıklayan kodun amacı, onu daha davranışsal, bildirimsel, okunabilir, anlaşılabilir ve sürdürülebilir hale getirmektir.
The KISS Principle(KISS İlkesi)
KISS ilkesi, “Aptalca Basit Tut” ifadesinin kısaltmasıdır. Sistemlerin karmaşık hale getirilmektense basit tutulduklarında daha iyi çalıştığını söyler. Daha basit sistemlerin anlaşılması, kullanılması ve bakımı karmaşık olanlardan daha kolaydır ve bu nedenle başarısız olma veya beklenmedik sonuçlar üretme olasılıkları daha düşüktür.
Declarative Exception Descriptions(Bildirimsel İstisna Açıklamaları)
İstisna(exception) açıklamaları hatadan değil, iş kuralından bahsetmelidir. İyi açıklamaya örnek: “Sayı 1 ile 100 arasında olmalıdır.” Kötü açıklama ise: “Sayı sınırların dışında.” olabilir. Sınırlar nelerdir ama?
Boy Scout Rule(İzci Kuralı)
Uncle Bob’un İzci Kuralı, bir İzci olarak bulduğunuzdan daha temiz bir kamp alanı bırakmak gibi, kodu bulduğunuzdan daha iyi bırakmanızı önerir. Kural, geliştiricileri, daha sonra temizlenmesi zor bir teknik borç karmaşası yaratmak yerine kod tabanına her dokunduklarında küçük, artımlı iyileştirmeler yapmaya teşvik eder; ayrıca tamamen iyi olmayan şeyleri değiştirmeyi de destekler. Bu, “Bozuk Değilse, Düzeltme” ilkesiyle çelişir.
“If It Ain’t Broke, Don’t Fix It” Principle(“Bozuk Değilse, Düzeltme” İlkesi)
“Bozuk Değilse, Düzeltme” ilkesi, yazılım geliştirmede yaygın bir ifade olup, bir yazılım sistemi iyi çalışıyorsa, herhangi bir değişiklik veya iyileştirme yapmaya gerek olmadığını belirtir. İlke, yazılımların otomatik testlere sahip olmadığı zamanlara dayanır, bu nedenle herhangi bir değişiklik yapmak muhtemelen mevcut işlevselliği bozar. Gerçek dünyadaki kullanıcılar genellikle yeni özelliklerdeki kusurlara tahammül ederler, ancak daha önce çalışan bir şey artık beklendiği gibi çalışmadığında çok sinirlenirler.
Cognitive Load(Bilişsel Yük)
Bilişsel yük, bilgiyi işlemek ve bir görevi tamamlamak için gereken zihinsel çaba ve kaynak miktarıdır. Bir kişinin aynı anda bilgiyi işlemeye, anlamaya ve hatırlamaya çalışırken çalışma belleği üzerindeki yüktür.
Decorator Pattern(Dekoratör Kalıbı)
Dekoratör tasarım deseni(kalıbı), aynı sınıftaki diğer nesnelerin davranışlarını etkilemeden, tek bir nesneye dinamik olarak davranış eklemenize olanak tanır.
Separation of Concerns(Kaygıların Ayrılması)
Kaygıların ayrılması kavramı, bir yazılım sistemini her biri genel sistemin belirli bir yönünü veya kaygısını ele alan ayrı, kendi kendine yeten parçalara bölmeyi amaçlar. Amaç, kodu daha küçük, daha yönetilebilir parçalara bölmektir. Bu sayede kodun yeniden kullanılabilirliğini, ölçeklenebilirliğini ve anlaşılırlığını teşvik eder. Ayrıca, modüler ve sürdürülebilir bir tasarım oluşturmak ve geliştiricilerin bir seferde bir kaygıya odaklanmasını sağlamayı teşvik eder.
Collective Ownership(Toplu Sahiplik)
Toplu sahiplik, bir geliştirme ekibinin tüm üyelerinin, başlangıçta kimin yazdığına bakılmaksızın kod tabanının herhangi bir bölümünde değişiklik yapma yetkisine sahip olduğunu belirtir. Paylaşılan bir sorumluluk duygusunu teşvik etmek, kodu daha yönetilebilir ve iyileştirilmesi daha kolay hale getirmek amaçlanmıştır.
Copy-and-Paste Programming(Kopyala-Yapıştır Programlama)
Kopyala-yapıştır programlama, yeni kod yazmak yerine mevcut kodu kopyalayıp başka bir yere yapıştırdığınız bir tekniktir. Kopyala-yapıştırı yoğun bir şekilde kullanırsanız, kodunuz daha az sürdürülebilir olur.
Feature Flags(Özellik Bayrakları)
Bir özellik bayrağı (özellik geçişi veya özellik anahtarı olarak da bilinir) tam yeni bir dağıtım(deploy) gerektirmeden, çalışma zamanında belirli bir özelliği veya işlevi etkinleştirmenize veya devre dışı bırakmanıza olanak tanır. Bu, A/B testi ve erken beta testleri gerçekleştirmek için bunları diğerlerinden gizleyerek yeni özellikleri bir kullanıcı veya ortam alt kümesine yayınlamanıza olanak tanır.
A/B Testing(A/B Testi)
A/B testi, piyasaya sürülen bir yazılımın iki farklı versiyonunu karşılaştırarak, hangisinin son kullanıcılar için daha iyi olduğunu belirler.
Overdesigning(Aşırı Tasarlama)
Aşırı tasarım, bir yazılım uygulamasına gereksiz yere kazara karmaşıklık ekleme uygulamasıdır. Bu, yazılımı basit tutup temel işlevselliğe odaklanmak yerine onu mümkün olduğunca özellik açısından zengin hale getirmeye odaklandığınızda oluşur.
Poltergeist Objects(Poltergeist Nesneleri)
Poltergeist, ilklendirme(initialization) işlemini gerçekleştirmek veya daha kalıcı bir sınıftaki metodları çağırmak için kullanılan kısa ömürlü bir nesnedir.
Baby Steps(Bebek Adımları)
Bebek adımları, geliştirme süreci boyunca küçük, yönetilebilir görevler veya değişiklikler yaptığınız yinelemeli ve artımlı bir yaklaşımı ifade eder. Bebek adımları kavramı, Agile geliştirme metodolojisinde kök salmıştır.
Rubber Duck Debugging(Lastik Ördek Hata Ayıklama)
Lastik ördek hata ayıklama, sanki bir lastik ördeğe programlamayı öğretiyormuşsunuz gibi kodunuzu satır satır açıklama kavramıdır. Kodunuzun her adımını sözlü olarak ifade edip açıklayarak, daha önce gözden kaçırmış olabileceğiniz hataları veya mantıksal tutarsızlıkları keşfedebilirsiniz.
Interface Segregation Principle(Arayüz Ayırma İlkesi)
Arayüz ayrımı ilkesi, nesnelerin kullanmadıkları arayüzlere bağımlı olmaya zorlanmaması gerektiğini belirtir. Tek bir büyük, monolitik arayüzden ziyade birçok küçük, uzmanlaşmış arayüze sahip olmak daha iyidir.
