Temiz Kod Yazmak için 8 İpucu ?

Herkese Selamlar ! Bugün sizlere hemen hemen tüm yazılımcıların ortak derdi olan “Temiz Kod” yazmak için 8 ipucu vermeye çalışacağım . Aslında her yazılımcı temiz kod yazmak ister . Kim daha kısa şekilde yazılabilecek bir işi daha da uzatmak ister ki ? Yalnız bir problem söz konusu . O işi tamamlamak için bir süreniz ve ciddi bir müşteri baskısı altında olduğunuzu varsayarsak kimsenin umrunda olmaz temiz kod yazmak . Herkesin tek derdi o işi en kısa surede tamamlamak ve müşteriye mahçup olmadan çalışır hale getirmek ister . Daha sonra uygun bir anımda bakarım der aynı yazılımcı fakat öyle bir vakit yoktur . Her daim üzerinde çalışılması gereken bir takım sorunlar ortaya çıkacaktır. Birde üzerine baska birinin kodu üzerinde düzenleme yapmamiz istenirse işte o zaman çok daha dikkatli olmamız gerekir. Bir de o kod ne kadar güzel yazılmış olursa olsun hep kötü olduğunu iddia edenler vardır ki o tarz kişilerin yanından geçerken iyi bir kulaklık takmanızı öneririm . Şimdi ise basit gözüken fakat alışkanlık edindiğimiz takdirde işimizi çok kolaylaştıracak olan 8 ipucuna bir bakalım .  

İsimlendirme Standartınız Olmalı

         Bunu her söylediğimde çok yanlış anlaşılıyor . O yüzden olabildiğince detaylı bir şekilde  burada açıklamak istiyorum . Tabiki de sizin de bir standardınız vardır elbette fakat her kod yazdığınız ya da her geçici olarak geldiğiniz  proje içerisinde kendi standartlarınızı kullanamazsınız . O projeye ait olan bir standart kullanmanız gerekmekte . Proje çok yıllık ise o proje içerisinde çok fazla geliştirmen bulunmuştur . Her gelen kendi standartını uygulamaya kalkarsa o uygulama içerisinde ki standartı olduğu gibi öldürmüş oluruz . Dediğimiz gibi sizlerde kendi standartınızı değil o projede varolan standartı uygulayın , proje uzun soluklu ve çok fazla geliştirmen yer almış ise en azından yer aldığınız modül içerisinde ki standartı yakalamaya çalışın . Bu sayede sizden sonra gelecek olan geliştirmenin biraz işini kolaylaştırmış olursunuz .

Lojik Her Zaman Gözden Geçirilmeli

         Yeni bir özellik eklenmesi için müşteriden talep geldiğini varsayalım . Az çok hemen fikir oluşur sizde . Veriyi çekeceğiniz katman , nerede veri üzerinde değişiklik yapacağınız vesaire bunların hepsi bellidir . Kesinlikle hemen kod yazmaya başlamayın . Sözde Kod (Pseudo – code) , akış diagramı yada kullanım örnekleri hepsini incelemelisiniz . Ardından ise yapmanız gereken şey şu olmalı . Bu talebe benzer bir talep daha önce proje içerisinde kullanılmış mı ? Eğer ki kullanılmış ise tamamen oraya benzeterek yazmaya çalışın . Bu sayede o kod bloğu içerisinde karşılaşacağınız bir problem orada çözülmüş olabilir !

Büyük Methodlardan Kesinlikle Kaçının

         S.O.L.I.D. principles içerisinde yer alan S harfinin temsil ettiği Single Responsibility Principles der ki bizlere “Bir method ya da sınıfın sadece tek bir görevi olmalıdır.” Aynen bunu gerçekleştirmelisiniz arkadaşlar . İlerlerken kurguladığınız mantık ise çok basit iki farklı kural söz konusu .

         1- Kod tekrarı yerine method oluşturmalısınız .

         2- Bir method içerisinde birden fazla görev olmamalı .

Sizin yazmanız beklenen yeni özelliğin tamamını bir method içerisine sığdırmaya kesinlikle kalkmayın. O zaman çok fazla method olacak belki de . Bırakın çok fazla olsun . Kod okurken olabildiğince kolaylaşacak işiniz . Bir kod kolay okunuyorsa onun standartı cidden iyidir .

Indentation Kullanmak

       Bu biraz tartışmaya açık bir konu olsada sürekli yan yana ve her bir parantezin hemen yanına yazılmış olan kodu okumak mı yoksa yeteri kadar boşluk bırakılmış , alt alta yazılmış kodu okumak mı kolay ? Siz o tarz bir şey hazırlamasanız bile sonradan o kodu okumaya çalışacak olan kişi o boşlukları hazırlayıp ondan sonra okuyacaktır. Derleyicinin tabiki de böyle bir şeye ihtiyacı yoktur . Nasıl yazılırsa yazılsın doğru yazıldığı müddetçe bir problem yok . Buna biraz dikkat edersek fena olmaz sanki.

Açıklayıcı Yorumlar Kullanın

Çoğu projede ki en önemli sorunların başında gelen problemlerden biridir bu. Eğer ki yeni özellik ekliyorsanız kodun amacını kısaca açıklamanız , ne zaman yaptığınız (aslında bu versiyon kontrolden bulunur) son olarak ise kim tarafından yapıldığını söylemeniz yeterli . Bazı firmalara eğitime gittiğimde bundan bahsediyorum ama genelde herkes o projeden sanki hiç ayrılmayacakmış gibi biz anlasak ne yazdığımızı yeter mantığı ile çalışıyorlar ki bu da durumu daha da içinden çıkılmaz hale getiriyor .

Kod İçerisinde Aşırı ve Gereksiz Yorumlar Yazmayın

En Başta şunu söylemek istiyorum ki yukarıda ki ile bu madde tamamen birbirinden farklı . Bir değişiklik yaptıktan sonra  /*Bunu ozhan yaptı*/  ya da tamamlayamadığınız bir iş için /*Sonra devam ederim*/ gibisinden yorumlar bırakmayın . Komik gelebiliri ama inanın bana çok fazla bunların sayısı. Geçici olarak yazabilirsiniz tabi ama kodunuzun ürün içerisinde yer almadan önce bunları kesinlikle silmelisiniz . Uzun uzun yorum yazın ama kodunuzun içerisine değil. Çok fazla yorum yazacak bir durumunuz var ise kodun bulundugu satı rile beraber farklı bir not aracında saklayın . Bu sayede çalışmanızı da bir parka daha düzenlemiş ve yorumlarınızı control altına almis olursunuz .

Eski ve Kullanılmayan Kodları Temizleyin

Aslında bu hemen gerçekleştirilmeli fakat ya ileride lazım olursa ya da başka bir özellik konusunda o kod bloğu bana yardımcı olabilir belki diye yorum satırına dönüştürüp basit bir açıklama ile saklıyoruz. Bunun en büyük dezavantajlarından biri ise o kod çok değiştirilmiş ve üzerinde çok oynanmış bir kod bloğu bize nasıl yardımcı olabilir ? Aynı zamanda üzerinden çok zaman geçtikten sonra ya da ekibe yeni bir üye gelince de kafa karışıklığı yaratabilir . Silmenizde fayda var ama . Eğer ki çok ihtiyaç duyarsanız source control üzerinden geriye gidip alma imkanınız söz konusu .

Lojik Her Zaman Kod İçerisinde Olmalı

Eğer ki veri çekiyorsanız bir yerden ki bu neredeyse küçük ölçekli bir proje için bile olması gereken bir şey artık az bir iş yükü bile olsa veritabanı içerisinde o işi yapmayın . Her şey kodunuz içerisinde aksın . Bu sayede her şeyi kontrol altında tutarsınız ve değişikliklerinizi daha kolay gerçekleştirirsiniz.

Bu tarz ifadeleri sizler ile ne kadar paylaşırsak paylaşalım en güzeli ise iş , proje ortamında tecrübe edince gerçekleşmekte. O yüzden şu an bu ipuçlarına uymaya çalışın ama zamanla hepsini çok daha iyi anlayıp , çok faha iyi bir sekilde uygulamaya başlayacaksınız zaten. Yazımı okudugunuz için çok teşekkür ederim. Sonra ki yazılarda görüşmek üzere …