Clean Code içinde bahsedeceğimiz bir diğer konu ise "High Cohesion Low Coupling" yani "Yüksek Birliktelik ve Düşük Bağımlılık"'tır. &O...
Clean Code: Least Astonishment Prensibi
Clean Code ve SOLID konuları ile birlikte bilmemiz gereken bir diğer prensip Principle of Least Astonishment'dir. Principle of Least Astonishment En Az Şaşkınlık Prensibi olarak bilinir. Bu prensip genel anlamda vurguladığı şey: Her zaman az şaşırtıcı olanı yapmak. Sistem çoğu kullanıcının ya da geliştiricinin bekleyeceği şekilde davranmalıdır. Bu ilkenin daha geniş bir uygulaması, bir sistemin bir parçasının veya bileşeninin, kullanıcıların ondan beklediği şekilde davranması gerektiği söyler. Başka bir deyişle, kullanıcılar şaşırmamalı, ürkütülmemeli veya sistemin farklı davranışları sergilemesi beklenmemelidir.
Geliştirici koda baktığında ya da test ettiğinde alakasız bir durum ile karşılaşmamalı beklenen durumlara hazır olmalıdır. İşte bu noktada prensip adından da anlaşılacağı gibi her zaman az şaşırtıcı olan işi yapmayı söyler. Gerekli bir özelliğin şaşkınlık faktörü yüksekse, özelliği yeniden tasarlamak gerekebilir. Aşağıdaki görselde bu durumu tasvir etmek için bir örnektir. İlk baktığınızda portakal görüyorsunuz fakat içinin kivi olması kullanıcıyı şaşırtır. İşte bu prensip bunun olmaması gerektiğini herkesin ortak anlayacağı şaşırmayacağı şekilde kod geliştirmemiz gerektiğini belirtir.
Biraz daha sektörden örnekler vermek gerekirse aşağıdaki gibi iki butonu görüyorsunuz. Seçim hakkınız olsa hemen hemen herkes B butonunu seçecektir. Çünkü genel alışılmış olan odur. Aksi durumda ise siz A butonunu kullandığınızda kullanıcılar bunu gördüğünde şaşkınlık içerisinde olması muhtemeldir. İşte bu durum Principle of Least Astonishment şaşkınlık prensibi olarak geçmektedir. Şaşkınlık her zaman en az seviye olmalıdır.
En Az Şaşkınlık İlkesi'nin diğer yüzü, yüzeysel olarak benzer, ancak gerçekten biraz farklı yapmaktan kaçınmaktır. Bu durum oldukça tehlikelidir çünkü görünüşteki aşinalık yanlış beklentiler doğurur. Bir şeyleri hemen hemen aynı yapmak yerine bazı belirgin farklı özellikler ile geliştirme yapmak çoğu zaman daha iyidir.
En Az Şaşkınlık İlkesine Uymak İçin
- Yazdığınız kodda beklenilen sonuçları vermesine özen gösterin.
- Yapılan iş geliştiricileri şaşırtmamalıdır.
- Beklenen duruma hazır olunmalıdır.
- Şaşkınlık faktörü yüksek ise kodunuzu yeniden gözden geçirmeniz gerekebilir.
- Bazen beklenilen alışılmış durumların yerine küçük değişiklikler ile geliştirme yapmak daha iyi sonuç verebilir.
Clean Code'a Giriş adlı yazımı da okumanızı tavsiye ederim.
Diğer Prensipler:
Kaynak:
https://medium.com/@myelmarc/principle-of-least-astonishment-efd5214b44a9
https://kidscodecs.com/principle-of-least-astonishment/
Umarım faydalı olmuştur. İyi çalışmalar dilerim.
Yorum yapabilmek için giriş yapmalısınız. Giriş yapmak için tıklayınız.