Clean Code'a Giriş

14.04.2022 yasinsunmaz 1247 0

Yeni bir konu ile karşınızdayım. Yazılımlarımızı elimizden geldiğince iyi stabile ve yönetilmesi kolay olacak şekilde yapmaya çalışıyoruz. Fakat bu işin de belli standartları ve kuralları var. Ne yazık ki ben de dahil olmak üzere bir süre boyunca bu şekilde yazılım yapıyordum. Şuan aldığım eğitimler ve araştırmalar sonucunda daha bilinçli kod yazmaya gayret gösteriyorum. Kısaca kodumuzun her anlamda okunaklı, yönetilmesi, bağımlılığı ve sürdürebilir olması için Clean Code diye bir şey var. Sizlere bu yazımda ve bununla alakalı olarak diğer yazılarımda clean code ile ilgili bildiklerimi ve hala öğrenmekte olduğum kısımlar ile ilgili bilgiler aktarmaya çalışacağım. Hem benim hem de siz değerli yazılımcı ve yazılımcı adaylar için faydalı olacağını düşünüyorum.

Biraz mevcut yaptığımız işlemler üzerine durmak istiyorum. Farklı farklı örnekler vereceğim eminim ki başlangıçta mantıklı bile gelebilir fakat öyle değil :)

En basit hali ile metotlarımızı yazarken belli işlemleri yapması için tasarlıyoruz. Örnek üzerinden gidecek olursak seçtiğimiz kullanıcılara mail atmak isteyelim. Bu durumda ilk akla gelen metot içerisinde kullanıcı listesini alıp sonrasında teker teker o kullanıcıya ait mail adresini alıp sonrasında mail gönderme işlemini yapmak olacaktır. Yani işlemleri sırası ile aynı metot içerisinde yapmak diyebiliriz.
Bazen bir metota ihtiyacımız oluyor ve bazı parametler ile birlikte bir işlem yaptırmak istiyoruz. Yeri geliyor 1 yeri geliyor 5-6 parametre metotlar yazabiliyoruz.
Dosya işlemleri yapacağımız zaman dosya yolunu tanımlıyoruz ve bunu değişkene atıyoruz. Bu değişken ismi "file" gibi bir şey oluyor genelde. Bunu gibi kısa isimlendirmeler kullanıyoruz.
Metotlarımızı yazarken karmaşık işlemler sırasında // ekleyerek yorum satırları yazıyoruz böylece başka biri o kodu anlamasını bekliyoruz.
Metotlarımızın içerisinde farklı durumlara göre farklı koşullar tanımlıyoruz. Böylece olası her durum için kodumuz çalışıyor. Ama if durumları giderek büyüyüp uzayabiliyor.
İf koşullarında tip değişkenlerinde özellikle sayı ve metinsel karşılaştırma yapıyoruz. Yani tip 1300 ise şunu yap. 1400 ise şunu yap şeklinde if koşulları kullanabiliyoruz. Bunun aksine "email" ise mail gönder. "sms" ise sms gönder gibi farklı ayrımlara gidebiliyoruz.
Değişken isimlerinde gelen değere göre isimlendirme yapıyoruz. Örneğin km değeri dönen bir kod satırında değişken olarak km yazmak ilk akla gelen oluyor.
Değişken ve metot isimlerinde Türkçe ve İngilizce kelimeleri beraber kullanarak isimlendirme yapabiliyoruz. Bunun en temel sebebi de başkalarının anlaması kolay olsun diye. Biz iyi bir şey yapalım derken daha da kötü bir duruma yol açabiliyoruz.

Genel anlamda bu gibi işlemleri isteyerek ya da istemeden yapıyoruz. Bu durumların birçoğu özellikle başlangıçta normal gibi gözükebilir. Ama hiçte göründüğü gibi masum işlemler değil Gelelim Clean Code neymiş, bizlere ne gibi tavsiyeleri var bir bakalım.

Temiz Kod Nedir?

Tüm geliştiriciler tarafından rahatça anlaşılabilen, geliştirilmesi kolay, odaklı, kısa ve basit koddur. Aslında temiz kod(Clean Code) basit olduğu için kısa, kısa olduğu için anlaşılır, anlaşılır olduğu için odaklı ve odaklı olduğu içinde gerekli geliştirmeleri rahatlıkla yapabilmektir. Aynı zamanda temiz kod teknoloji ve sektörden bağımsız olarak düşünülmelidir. Bir diğer husus ise tekrarsız kod yazmaktır. Aynı sınıf içerinde ya da aynı proje içinde aynı koddan ya da aynı metottan olması pek mantıklı bir davranış değildir. Hepsi birbiri ile bağlantılı ve hepsini iyi şekilde kullandığımızda ortaya temiz bir kod çıkacaktır.

Temiz kod aslında yapmasanız da yine o kodunuz bir şekilde çalışacaktır. Ama temiz kod yazmak hem sizin gelişiminiz hem de bulunduğunuz proje ve şirket için bir ahlaki bir sorumluluk olarak düşünmemiz gerekir. Temiz kod yazmak işini iyi yapmakla ilgilidir. Temiz kodun aksine bir kod temiz değilse kötü koddur(dirty kod).

Temiz kod elde edebilmemiz için şirket ve ekip bireylerinin iletişimi, kodları gözden geçirme, kodları iyileştirme, cesarete ve zamana ihtiyacımız olacaktır. Özellikle ciddi projelerde yapacağınız değişiklikler sistemi etkileyebileceğinden bunları yapma konusunda iyi düşünmeli ve ona göre hareket etmelidir.

1-Temiz Kod: Basittir(KISS)

KISS: Keep It Simple, Stupid

Kodumuzun olabildiğince basit, anlaşılabilir ve geliştirebilmesini sağlamayı hedefleyen bir prensiptir. Aptal olacak kadar basit yapmalısınız ki o kodda hata olmadığı açık olsun.

Refactoring

Kodun basitleştirilme işlemidir. İyileştirme yapabilmek için her zaman bölme, çıkarma ve parçalama ile sağlanır. Yani kodunuzun basit olabilmesi için her zaman mevcut kodlar parçalanır ve yeni metotlar, yeni sınıflara bölünmesi gerekir. Bunu yaptıkça kodunuz basitleşir ve tek bir işlevi olur.

Her satırda bir işlem yap: Kodunuzun her satırda sadece bir iş yapmasına yönelik geliştirme yapmak en iyisidir. Aynı satır içerisinde farklı işlemleri aynı anda yapmayın. Siz ve başka geliştiriciler satıra baktığında tek bir işi anlasın. Aksi durumda o satırda anlam karmaşası olup geliştiricinin anlaması güçleşebilir. Buna uyarak kodlarınızın anlaşılabilir olmasını sağlayabilirsiniz.

Basit Kod İçin

Kodlarınızda değişken, metot ve isimlendirmelerine dikkat etmek.
Her iş tek seferde olacak şekilde yazılmalıdır. Tanımlamalar tek seferde olmalıdır.
Kodunuza baktığınız zaman karmaşık olmamalı hem görüntü hem de anlaşılırlık bakımından güzel görünmelidir.
Basit kod temelde doğru soyutlamalar ile sağlanabilir.
Kodlarınızda gerektiği yerlerde dokümantasyon kullanımına özen gösterilmelidir.
Satır, metot ve sınıf seviyesinde iş mantığı farklı şeylerdir. Satır seviyesinde bir iş sadece o satırdaki yapılan işi kapsağı gibi sınıf seviyesindeki iş ise o sınıf içerisinde barındırdığı tüm işlerin genel anlamda tek bir anlam ifade etmesidir.
Basit kod anlaşılır ve kısa koddur. Anlaşılır kod ise standart ve odaklı koddur.
Gereksiz değişken ve özellikler kaldırılmalıdır.
Kodu atmaktan korkmayın. Kodu yeniden düzenlerken her zaman istenmeyen kodu kaldırın.
Kodunuzu basitleştirmeden önce soruna odaklanın, nasıl çözebileceğiniz ile ilgili alternatif çözümler üretin. Sorunları iş parçalarına bölüp öyle çözmeye başlayın.
Her zaman kod geliştirme standartlarını takip etmelisiniz.

Bu maddeler genel anlamda basitlik için önem içerir. Bunların detaylarını inceleyeceğiz.

1.1-Temiz Kod: Anlaşılırdır

Anlaşılır kod mimariye uyumludur, isimlendirme standartlarına sahiptir, standartlar ve belli şekile sahiptir. Dilin kullanımı da önemlidir. Dokümantasyon ile gerekli açıklamalar ile kodu destekleyebilirsiniz.

Temiz Kod: Mimariye Uyumludur

Clean code için mimariye uyumlu yazılım geliştirmek gerekiyor. Gerekli yerlerde kodlarımızı mimariye uyacak şekilde değiştirmemiz gerekebilir. Eğer mimari değişime müsait değilse mimariye uygun kod yazılmalıdır. Aksi durumda mimari geliştirmeye değiştirmeye müsait ise clean code işlemini buradan başlanmalıdır.

Temiz Kod: İsimlendirme

Temiz kodda bir diğer önemli husus ise isimlendirmedir. İsimlendirmeler değişkenlerde, metotlarda ve sınıf isimlendirmelerinde de dikkat edilmesi gerekir. Genel olarak isimlendirmelerde dikkat edilmesi gerekenler:

İsimlendirmelerinizi her zaman İngilizce olarak yapın. Türkçe isimlendirme kullanmak uygun değildir. En temel sebebi kod herkes tarafından ortak bir dilde olması ve yazılımın başkalarına satılması durumunda o kişilerce de anlaşılabilir olması açısından İngilizce olması en uygundur.
İngilizce kelimeler ile isimlendirme yaparken kelimenin doğruluğuna dikkat etmelisiniz. Örneğin "Extentions" diye bir kelime kullanacakken "Extentons" gibi kelime hataları yapmamak gerekiyor. Kelimenin doğrulundan emin olmalısınız.
Anlaşılır isimlendirmeler kullanılırken en sık yapılan hata kısaltma kullanımıdır. Bir isimlendirme kısaltma yapıp anlaşılması zor olacağına uzun olup anlaşılır olması daha iyidir. Yani kısa isimlendirme yerine uzun anlamlı isimlendirmeler daha iyidir. Örneğin "fileExt" değişkeninde ne olduğu konusunda kafa karışıklığa sebep olabilir. Bunun yerine "fileExtentions" şeklinde bir tanımlama daha anlaşılır olacaktır. Kısaltmalar farklı anlamlar taşıyor ise uzun isimlendirme kullanılmalıdır.
Kısaltmalar ancak for, while gibi döngülerde i,j ve k gibi tanımlamalar uygundur. Döngülerde bu harfleri kullanmakta bir sakınca yoktur.
Kendi kısaltmalarımız yerine evrensel kısaltmalar kullanmak en doğrusu olacaktır. Evrensel olmayan kısaltmalardan uzak durmak gerekir. Http, tcp gibi evrensel kısaltmalar bunlar arasındadır.
Metotlarınızda isimlendirmeye dikkat etmediğinizde karmaşık işlerde anlamanız daha da zor olacaktır. Doğru isimlendirmeler ile karmaşık işlerin bile anlaması kolaylaşacaktır.
Var olan bir metot ve buna ait bir isimlendirme vardır. Ama gün gelir o metodun işlevinde bir değişiklik olursa metodun da ismi değiştirilmesi gerekir. Aksi takdirde anlam karmaşasına sebep olup geliştiriciler için zamanla zorluk çıkaracaktır.
İsimlendirmelerin uzun olması da her zaman da doğru olacak diye bir şey yoktur. Gereksiz uzun isimlendirmelerde yanlıştır.
İsimlendirme genel olarak verilmez. Amacı ne ise açıkça belirtilir.
Aynı kelimeleri kullanan değişken isimlendirmelerinde dikkatli olunmalıdır. Benzer isimler de kodda karmaşaya sebep olabilir.
Aynı işleve benzer ama farklı iş yapacak işlemlerde isimlendirmeler sonuna 1,2,3 gibi sayılar yazarak isimlendirme yapmayın. Anlamlı isimlendirme yapın.
Sınıf-Metot-Değişken isimlendirmeleri birbirleriyle uyumlu olmalıdır. Yani kullanıcı ile ilgili bir sınıfımızda: User sınıfımızda metot isimlendirmeleri de user ile ilgili olmalı. Aynı zamanda da değişkenler de user ile ilgili olacak şekilde tanımlamamız gerekiyor.
Metin ve sayısal ifadeler için enumaration kullanılmalıdır. Böylece hata yapma olasılığınız neredeyse olmaz.
Genel olarak herkesin benimsediği isimlendirmelere uygun şekilde isimlendirme yapmaya gayret göstermek gerekiyor.
İsimlendirme konusunda ekip ve şirket olarak tutarlı olunması en iyi sonucu verecektir. Böylece şirket içinde veya dışında olsun kodun okunurluğu artacaktır.

Temiz Kod: Standartları ve Şekil

Kodun bazı standartları vardır. Bunun en bilineni değişken isimlendirme standartlarıdır. Bu isimlendirme standartlarına uygun isimlendirme yapılmalıdır. Bir yerde camelCase başka yerde snake_case standartlarına uygun isimlendirme yapmak yanlış olacaktır. C#'da genel olarak metot isimlendirmeleri PascalCase olarak yapılırken, değişken isimlendirmeleri camelCase olarak kullanılır.

PascalCase: FileExtentions

camelCase: fileExtentions

snake_case: file_extentions

kabab-case: file-extentions

Kodunuzun satır uzunluğu ekranın altındaki kaydırma çubuğunu kaydırmaya gerek olmadan okunacak şekilde olmasına gayret gösterilmelidir. Eğer satır uzunluğunu mevcut ekranınızın uzunluğunu geçiyor ise alt satıra geçmeniz en doğrusudur. Böylece geliştirici kodu okurken tek seferde okuyabilir ikinci bir işlem yapmaya gerek duymaz.

Temiz Kod: Dilin Kullanımı

Kodunuzdaki bir problemi çözmek için farklı kodlamalar yaparak ekleme yapmak anlam karmaşalarına neden olur. O yüzden hep dediğimiz gibi temiz kod ekleyerek değil bölüp parçalamak ile olur. Yazılımda sık karşılaşılan problem için tasarım kalıpları(design patterns) kullanılır. Her tasarım kalıbı belli sorunlara yönelik çözümler üretir. Frameworkler ise kodların standartları olmasını sağlar. Son olarak ise her yazılım diline ait idiomlar vardır. Bu idiomlar hangi durumda ne yapmamız gerektiği konusunda bize yok gösterir.

C# .Net idiomlarını detaylı incelemek için: tıklayın...

Temiz Kod: Dokümantasyon

Kodun anlaşılabilir olması için ilk başvurulan şey dokümantasyon olmamalıdır. Eğer böyle ise o kod zaten basit kod değildir. Yani temiz kod değildir. O yüzden öncelikle kodun clean code olması gerekiyor. Kod anlaşılır olsun ki dokümantasyona bile gerek olmasın. Zaten metot ve isimlendirmeler açık ve net olursa dokümantasyona da gerek olmayacaktır. Dokümantasyon ancak karmaşık işlemlerin olduğu geliştiriciye yön vermek istediğimiz durumlarda gereklidir.

Genel olarak geliştiriciler tek satırda yorum satırı yapmak için "//" kullanılır. Çoklu satırlar için ise "/*.......*/" kullanılır. Ama bunlar pek tercih edilmemelidir. Bunun yerine API dokümantasyonu tercih edilmelidir.

Ayrıca kodlarınızı yorum satırı halde iken projede bırakmayın. Yorum satırı olarak duracak kod yerine direk silmeniz en doğrusudur.

API Dokümantasyonu

Metotta yapılan işlem ile gerekli açıklamayı, eğer alıyorsa parametreleri ve geri dönüş değerleri gibi bilgiler içerir. API dokümantasyonu sınıf, arayüz ve metotlar için kullanılır. C# için API dokümantasyonu aşağıdaki gibi kullanılır:

Clean Code API Dokümantasyon

API Dokümantasyonu ilgili detaylı bilgi için: tıklayın...

2-Temiz Kod: Odaklıdır(DRY)

Kodunuzda, metodunuzda ve sınıfınızda ne olursa olsun tek bir şeye odaklanmalıdır ve bir şeyi halletmelidir. Yani sınıf sadece bir şeye odaklanmalıdır. Metot sadece bir işi yapmalıdır. Sınıflar olabildiğince küçük olmalı gerekirse parçalanarak yeni sınıflar oluşturulmalıdır. Yazdığımız kodun tek bir hedefi olmalıdır. Bunu yaparken o işlevde ilgili her şey olmalı ama ilgisiz hiçbir şey olmamalıdır. Yani metotta ya da sınıfta gereken şeyleri barındırmaları eğer ora ile alakası yok ise o dışarıda tutulmalıdır. Örneğin user sınıfında file ile ilgili bir metot bulunmamalıdır.

Bir blokta yapılacak işi bir satırda yapmak, birkaç işi birleştirip tek metotta halletmek yanlış bir soyutlamadır. Her ne kadar kodu azalttığımızı ya da tek seferde işi yaptığını düşünsek bile. Ama öyle değil bir metot birçok işi tek seferde yapması ile bir metodun tek bir işi olması arasında çok büyük fark vardır.

Kodumuzu sürekli iyileştirerek mükemmelliğe ulaştırabilir. Bunun yaparken de ekleyerek değil çıkararak yapmalıyız.

DRY(Dont Repeat Yourself)

Odaklı kod yazabilmenin yanında kodumuz tekrarsız olması gerekiyor. DRY prensibine göre ne olursa olsun kodunuz tek bir yerde olmalıdır. Aynı kod aynı metot farklı yerlerde olmamalıdır. Tek bir yerde olmalıdır. Bunu yapabilmek için de copy-paste değil cut-paste ile sağlayabiliriz. Buna dikkat ederek kod yazmamız gerekiyor. Eğer o kod varsa ve siz kolay olsun diye kopyalayıp istediğiniz yerde tekrar yazarsanız bu kötü koda dönüşür.

3-Temiz Kod: Doğrudur

Bir kodun doğrulundan emin olabilmek için de testlere ihtiyaç duyarız. Birim testler sayesinde kodun doğrulundan emin olabiliriz. İleride tekrar o kod ile ilgili bir geliştirme yapacağımızda yine birim testlere ihtiyaç duyar ve kullanırız. Sonraki konularımızda ama kod yazdıktan sonra birim test yazmak pek mantıklı değildir. Bu birim testlerimiz TDD yöntemleri ile daha iyi sonuçlar verir. TDD ile iligli bilgilendirmeyi sonraki yazılarımda paylaşacağım.

4-Temiz Kod:Tamdır

Kodumuzun tam olması demek:

Olması gereken işi başarılı olarak yapması
Olmaması, istenmeyen şeye karşı önlem almış olması
Olabilecek olanı ön görmesidir.

Bununla birlikte kodu tam yapan şeyler aslında bizim şimdiye kadar bahsettiğimiz basitlik, odaklılık ve doğruluktur. Tüm bunların bir araya gelmesi ile tam bir kod ortaya çıkar. Clean code için ilk aşamada bunlara uyarak güzel geliştirmeler yapabiliriz. Eminim ki bunlara uymaya başladıkça siz de farklı anlayacaksınız.

Evet clean code ile ilgili girişimizi yaptık. Buna bağlı olarak diğer önemli hususlarda da yazılar hazırlayacağım. Bu bahsettiklerime eklemek istedikleriniz varsa benimle paylaşabilir ve yorum yapabilirsiniz.

Kaynak:

Akın Kaldıroğlu

https://www.c-sharpcorner.com/article/k-i-s-s-software-design-principle/

Umarım faydalı olmuştur. İyi çalışmalar dilerim.