Karşınıza karmaşık, düzensiz ve not içermeyen kodlar çıktığında neler hissettiğinizi çok iyi anlıyorum. Bunu önlemek için "temiz kod" önerilerini ve ipuçlarını bu yazıda bulacaksınız. Sizler de bu yazıyı paylaşarak temiz kodu teşvik edebilirsiniz.
Günümüzde sıfırdan başlanarak ticari bir yazılım geliştirilmesi, özellik, arayüz ve protokol çeşitliliğinin getirdiği kompleksite artışı ve pazara çıkış sürelerinin giderek kısalması nedeniyle neredeyse imkansızdır. Bu yüzden mevcut kod parçalarının doğrudan ya da değiştirilerek kullanılması bir zorunluluk haline gelmiştir.
Bu kod parçalarını, COBOL, Basic, Java, C++ vb. diller oluşturur ve onlar 3GL diye adlandırılır. 3GL kullanım açısından kolay ve anlaşılabilir olsa da iş yerlerinde bu dili kullanabilen nitelikli programcılara ihtiyaç duyulur. Aynı zamanda, bu ihtiyacı azaltmak için son dönemlerde Hızlı Uygulama Geliştirme (RAD) araçları kullanılıyor. Bu araçlar, kişilerin kendi programlarını oluşturmalarını sağlayarak verimliliği arttırmaya yarıyor. Bunlar temel ifadelerin ve metnin girilmesinden başka, çok az kodlama içeren görsel gelişim ortamları sunuyor. Fakat, yeniden kullanılacak kod parçaları kurum içinde üretilmiş olabileceğinden ötürü, açık kaynak kodları ya da satın alınmış kodlar olabilir. Bahsettiğimiz geliştirme araçları bildirimlere dayanıyor. Yani, kullanıcı ara yüzlerinin, iş mantığının, algoritmaların ve kontrol kodunun görsel modellemesini sağlıyor. Arka planda, düşük kodlu bir ortamda erişilebilen ve değiştirilebilen binlerce kod satırı üretebiliyor. Bu kod parçalarının verimli ve güvenli olarak kullanılabilmeleri için kolay anlaşılabilir ve değiştirilebilir olmaları çok önemlidir. Kurum içinde üretilmiş de olsa, kodun ilk geliştiricisinin uzun zaman önce ayrılmış olması, bir üst düzey yöneticinin kodu olması durumunda, sıklıkla “koddaki şu açıklamada (// yyyy) ne demek istemiştiniz” gibi sorular sorma şansının olmaması, ya da kendi kodu da olsa altı ay sonra detayları hatırlama zorluğu, kodla yeni sahibini başbaşa bırakacaktır.
Yukarıda bahsettiğimiz, düşük kodlu programların hem avantajları hem de dezavantajları vardır. Örneğin,başlangıçta, birçok tedarikçi Amazon Web Services (AWS), Microsoft Azure ve Google Cloud gibi yaygın olarak kullanılan genel bulut platformlarına dağıtımı desteklemektedir. Bununla birlikte, oluşturulan kod aynı zamanda özel olabilir, yani taşınamaz ve özel olmayan 3GL kodu üretilse bile, geleneksel programcılar için bile çalışması zor bir yapıya ve formata sahip olabilir. Diğer yandan, düşük kod geliştirmenin, uygulamaları daha hızlı test etmeye, düşük hata oranlarına ve daha güvenilir bir ortam sağlamaya yaradığı söyleniyor.
Tüm bu nedenlerle yazılımcıların aşağıdaki konuları anlaması ve dikkat etmesi oldukça önemlidir;
- İyi kod ve kötü kod arasındaki fark,
- İyi kod yazmak ve kötü kodu iyi koda dönüştürmek,
- İyi isimler, iyi fonksiyonlar, iyi nesneler (object) ve iyi sınıflar (class) oluşturmak,
- Maksimum okunabilirlik için kodu formatlamak,
- Kod yapısını bulanıklaştırmadan hata işlemek (error handling),
- Birim test yapmak ve test odaklı geliştirme (TDD).
Robert C. Martin’in Clean Code - A Handbook of Agile Software Craftsmanship (Temiz Kod – Çevik Yazılım İşçiliği Elkitabı) adlı eserinde temiz kod yazmanın prensipleri, örüntüleri (pattern) ve pratikleri anlatılmaktadır. Bu blog yazısında uzun uzun anlatamayacağım için, konuyla ilgili fikir vermek ve teşvik etmek amacıyla, kitabın isimlendirmeyle ilgili birinci bölümünü ana başlıklarıyla aşağıda özetlemeye çalıştım.
1) Niyeti ortaya koyan isimler kullanın
Değişken, fonksiyon ya da sınıf ismi, neden var olduğunu, ne yaptığını, ve nasıl kullanıldığını anlatmalıdır.
yerine
gibi isimler seçilmelidir.
2) İsimde yanlış bilgilendirmeden kaçının
Bir grup hesaba gerçekten liste değilse hesapListesi demeyin. hesapGrubu, birGrupHesap ya da sadece hesaplar daha iyi olacaktır.
Yanıltıcı isimlendirmeye en uç örnek değişken ismi olarak küçük L ya da büyük o kullanmak olacaktır.
Kullanılan editör ve fonta bağlı olarak küçük L birle, büyük o sıfırla karıştırılabilir.
3) İsimleri anlamlı olarak farklılaştırın
İsimleri numara ekleyerek farklılaştırmak yanlış bilgi vermekten öte hiç bilgi içermez.
Argüman olarak kaynak ve hedef kullanılırsa bu fonksiyon daha anlaşılır olacaktır.
4) Telaffuz edilebilir isimler kullanın
Telaffuz edilebilir isimler kullanmak anlaşılırlığı kolaylaştıracağı gibi takım içi iletişimi de kolaylaştıracaktır. Telaffuz edemiyorsanız, üzerine tartışmanız da bir hayli zor olacaktır. olsyagsdsn (oluşturma tarihi, yıl, ay, gün, saat, dakika, saniye) değişkeninden bahsederken “Buradaki olsyag se de se ne değişkeni int olmalı” benzeri konuşmalar sıkça duyulacaktır çünkü programlama sosyal bir aktivitedir.
5) Aranabilir isimler kullanın
Tek harflik isimler ve numerik sabitlerin metin içinde aranması kolay değildir. OGRENCI_BASINA_EN_COK_SINIF’ı bulmak 7’yi bulmaktan kolaydır. Tek harflik isimler sadece kısa metodların içindeki lokal değişkenler için kullanılabilir.
Aşağıdaki iki kod parçasını karşılaştırınız.
,
6) Kodlamadan kaçının
İsim uzunluğu sınırlaması olan eski dillerde bu kuralı çiğnemek zorunluydu. Fortran, ilk harfin türü belirten bir kod olması kuralı nedeniyle kodlamaya zorlayan bir dildi. Ancak günümüzün güçlü tür kontrolü yapan modern dillerinde böyle bir sınırlama bulunmamaktadır.
yerine
kullanılırsa değişkenin long yapılması gerekince ismin değişmesi gerekmeyecektir.
Sınıf ve fonksiyon üye isimlerinde de ‘_’, ‘m_’ ya da ‘its’ benzeri kodlamalara gerek yoktur çünkü sınıf ve fonsiyonlarınız bunlara gerek duymayacak kadar kısa olmalıdır. Ayrıca üye isimlerini renklendiren bir editör kullanılmalıdır.
7) Zihinsel eşlemelerden kaçının
Döngü sayaçlarına i ya da j gibi isimler verilebilir çünkü bu geleneksel bir uygulamadır. Ancak diğer çoğu durumda tek harfli bir isim kötü bir seçimdir.
Programcılar genelde akıllı insanlardır. Akıllı insallar bazen gösteriş yapmayı severler. r’nin url’nin sunucu ve şema çıkarılmış küçük harf versiyonu olduğunu hatırlayabiliyorsanız açıkça çok akıllı olmalısınız. Akıllı programcı ile profesyonel programcı arasındaki farklardan biri, profesyonelin, açıklığın paha biçilmez olduğunu bilmesidir.
8) Sınıf isimleri
Sınıf ve obje isimleri, musteri, WikiSayfası, Hesap, HesapCozumleyici gibi isim ya da isim cümleleri olmalıdır. Sınıf ismi fiil olmamalıdır.
9) Metod isimleri
Metod isimleri, odemeyiErtele, sayfayiSil, sakla gibi fiil ya da fiil cümleleri olmalıdır.
10) Her kavram için tek kelime kullanın
Farklı sınıfların benzer metodları için Sakla, Yaz ve Kaydet kullanmak kafa karıştırıcıdır. Bir tanesi seçilip tüm kodda bağlı kalınmalıdır.
11) Kelime oyunu yapmayın
Aynı kelimeyi farklı fikirler için kullanmak bir kelime oyunudur. Topla‘yı ele alalım. Bir sınıfta tuşlanan numaraların toplanması, bir diğerinde mevcut iki değerin toplanması ya da eklenmesi işlemi için kullanılması kafa karıştırıcı olacaktır.
12) Çözüm alanına ait isimler kullanın
Kodunuzu okuyacak kişilerin programcı olacağını unutmayın. Bilişim terimlerini, algoritma isimlerini, örüntü isimlerini, matematik terimlerini kullanmaktan çekinmeyin. Zorunlu olmadıkça sorun alanına ait terimler kullanmamalıyız çünkü programcıların ikide bir müşteriye gidip isimlerin ne anlama geldiğini sormalarını istemeyiz. HesapVisitor Visitor örüntüsüne aşina bir programcıya çok şey ifade edecekken, HesapCetveli fazla fikir vermeyebilir.
13) Sorun alanına ait isimler kullanın
Programlayıcı jargonundan bir isim bulunamıyorsa, sorun alanından bir isim kullanılabilir. Programcı en azından bir alan uzmanı bulup ne anlama geldiğini sorabilir.
14) Anlamlı bağlamlar ekleyin
ad, soyad, cadde, sokak, numara, sehir ve postakodu isimli değişkenleriniz olduğunu düşünelim. Topluca bakıldığında bir adres oluşturdukları anlaşılabilir. Fakat sadece kodun bir yerinde numara’nın tek başına kullanıldığını görürseniz ne anlarsınız? Ön ekler kullanarak bağlam ekleyebilirsiniz: adresAd, adresSoyad, adresCadde… Daha iyisi Adres isimli bir yapı ya da sınıf oluşturmak olacaktır. Böylece derleyici de bu değişkenlerin daha büyük bir oluşumun elemanları olduklarını bilecektir.
15) Gereksiz bağlam eklemeyin
“Delüks Benzin İstasyonu” adlı hayali bir uygulamada, her sınıf isminin önüne DBI eklemek kötü bir fikirdir. Açıkcası kullandığınız araçlara karşı haksızlık yapmış olursunuz. D’ye basın ve sistemdeki tüm sınıfların bir kilometrelik listesi karşınızda.
BONUS: Muzip olmayın
İsimlendirme çok akıllıca olursa sadece yazarın espri anlayışını paylaşanlar tarafından ve şaka hatırlandığı süre boyunca anlaşılabilecektir. KutsalElBombasi isimli bir fonsiyonun ne olduğunu kim bilebilir? Gerçekten çok muzipçe ama bu durumda OgeleriSil daha uygun bir isim olacaktır.
Kod Yazmayı Bilmeden Programlama Yapılabilir mi?
Bilgisayar sistemleri, son yıllarda toplumu değiştirdi ve birçok görevde insanların çabasını azalttı. Fakat günümüzde bile, bilgisayarlara bu işleri yaptırabilmek için gerekli programlama görevini bir insana vermek gerekiyor. Bu görevi üstlenen kişiler yazılımcılar oluyor.
Yazılımcılar veya diğer bir deyişle programcılar, elbette temel bilgisayar talimatlarının birincil ikili dilini oluşturan 0 ve 1’leri yazmazlar. Bu ikili dil daha soyut programlama dilleri tarafından oluşturulur. Peki, bu soyutlama ne kadar ileri gidebilir? İkili komutlara benzeyen Assembly dilleri ikinci seviyeyi oluşturur. 3. seviyeyi ise COBOL, Basic, Java, C++ vb. diller oluşturur ve onlar 3GL diye adlandırılır.
3GL kullanım açısından kolay ve anlaşılabilir olsa da iş yerlerinde bu dili kullanabilen nitelikli programcılara ihtiyaç duyulur. Bu ihtiyacı azaltmak için son dönemlerde Hızlı Uygulama Geliştirme (RAD) araçları kullanılıyor. Bu araçlar, kişilerin kendi programlarını oluşturmalarını sağlayarak verimliliği arttırmaya yarıyor. Bunlar temel ifadelerin ve metnin girilmesinden başka, çok az kodlama içeren görsel gelişim ortamları sunuyor. Hızlı Uygulama Geliştirme araçları son dönemde tekrar gündeme geldi ve düşük kodlu veya kodsuz programlama konusu iş hayatında önemini arttırmaya başladı.
Bahsettiğimiz geliştirme araçları bildirimlere dayanıyor. Yani, kullanıcı ara yüzlerinin, iş mantığının, algoritmaların ve kontrol kodunun görsel modellemesini sağlıyor. Arka planda, düşük kodlu bir ortamda erişilebilen ve değiştirilebilen binlerce kod satırı üretebiliyor.
Düşük kodlu araç sağlayıcılarının çoğu yeni nesil olan bu ürünlerinin, iş insanlarına ve geleneksel geliştiricilere kurumsal sınıf uygulamaları oluştururken fayda sağlayabileceğini iddia ediyor. Düşük kodun, 4GL'nin başarısız olduğu yerde başarılı olacağına inanmalarının nedenlerinden biri, ortalama bir iş insanının 20-30 yıl öncesine göre teknik olarak daha donanımlı olmasıdır. Bir diğer neden ise, uygulamaların genellikle araç sağlayıcılarının kendi bulut platformlarından dağıtılmasıdır ve performans, kullanılabilirlik, ölçeklenebilirlik, hizmet seviyeleri ve güvenlik konusunda merkezi kontrol sağlamasıdır.
Düşük Kodlu Program Geliştirmenin Artıları ve Eksileri Nelerdir?
Öncelikle düşük kod geliştirmenin en önemli dezavantajlarından biri, bir ürün veya şirkete bağımlı kalmak olabilir.
Başlangıçta, birçok tedarikçi Amazon Web Services (AWS), Microsoft Azure ve Google Cloud gibi yaygın olarak kullanılan genel bulut platformlarına dağıtımı desteklemektedir. Bununla birlikte, oluşturulan kod aynı zamanda özel olabilir, yani taşınamaz ve özel olmayan 3GL kodu üretilse bile, geleneksel programcılar için bile çalışması zor bir yapıya ve formata sahip olabilir.
Düşük kod araçları, en son yenilikleri desteklemek için kullanıma hazır bileşenler sağlayan kütüphanelerle birlikte gelir. Bunlara en yaygın örnekler blockchain ve yapay zekadır. Bileşenler; tedarikçi, üçüncü taraflar veya kullanıcılar topluluğu tarafından sağlanabilir ve ücretsiz ya da ücretli olabilir. Örneğin, harici entegrasyonları sağlayan uygulama programlama arayüzleri (API) de vardır.
Düşük kodlu araç sağlayıcıları, düşük kod geliştirmenin, uygulamaları daha hızlı test etmeye, düşük hata oranlarına ve daha güvenilir bir ortam sağlamaya yaradığını söylüyor. Tüm bu avantajların da maliyeti düşürdüğüne ve 4GL'lerin yetersiz kaldığı alanlarda fayda sağlayacağını düşünüyor. Elbette, düşük kodlu araçları kullanmak için de belli bir miktarda ödeme yapılması gerekebiliyor. Fakat çoğu 3GL derleyicisi açık kaynaklı olduğu için ve ücretsiz açık kaynak kitaplıklarından yararlandığı için maliyeti daha az olabiliyor.
Düşük kod tedarikçileri ürünlerinin düşük maliyetli olduğunu iddia ediyorlar çünkü yazılımcı çalıştırmanın daha yüksek maliyetli olduğunu söylüyorlar. Ayrıca düşük kod, iş insanlarının projelerinin gelişimi üzerinde daha fazla kontrol sağlayabilmelerini sağlıyor.
Düşük Kod Geliştirme Araçları Nelerdir?
Express (Apex): Tedarikçinin veritabanı yönetim sistemine bağlı olan Application Express (Apex), Oracle’ın ürünüdür.
Visual Builder Cloud (VBCS): Bulut tabanlı ve şirket içi dağıtımın desteklendiği Visual Builder Cloud bir Oracle ürünüdür.
Salesforce Lightning: Salesforce, genellikle Force.com platformundaki diğer uygulamaların kullanımını genişletmek için kullanılan, AppExchange kütüphanesi tarafından desteklenen Salesforce Lightning aracını piyasaya sunuyor.
Quick Base: Temeli 1999'a kadar uzanan eski bir şirket ve şimdilerde ise bellek içi veritabanına dayalı tamamen bulut tabanlı bir platformdur.
Pega Infinity: 1980'lere dayanan Pegasystems’in Pega Infinity düşük kod platformu, iş süreci yönetiminden evrimleşirken, App Studio kütüphanesi robotik süreç otomasyonu gibi karmaşık gereksinimler için bileşenler de içeriyor.
Zoho’s Creator: 2006 yılında piyasaya sürüldü ve platformunda beş milyondan fazla uygulamanın çalıştığını iddia ediyor. Kısmen küçük işletmelerin odağı olsa da kurumsal kullanıcılar da vardır. Deluge adında özel bir betik dili kullanır.
OutSystems: OutSystems'in düşük kodlu platformu mobil, nesnelerin interneti (IoT) ve web uygulamalarının geliştirilmesini destekler. C # ve .Net kodu üretilir ve teslimat yerinde destek için tedarikçinin kendisinde veya genel bulut platformlarında olabilir. Kullanıcıların, daha çok profesyonel geliştiriciler olma olasılığı daha yüksektir.
Betty Blocks: Yeni niş tedarikçiler arasında, ilk olarak 2012 yılında piyasaya sürülen kodsuz bir platform olan Betty Blocks yer alıyor. Uygulamalar, temel işlevleri içeren bloklardan toplanıyor. Uzantıları yazmak için Elixir adlı bir dil kullanıyor.
Skuid: Skuid, 2013 yılında kurulmuştur. Tasarım ve dağıtım platformu, kullanıcıların kod yazmadan sipariş üzerine yapılan uygulamaları bir araya getirmek için farklı veri kaynaklarına bağlanmalarına yardımcı olur. SAP ve Google ile ortaklıkları vardır.
Bu yazıyı okuyanlar, bunları da okudu;
Programlama Dilleri Nedir? Gelişimi ve Tarihi
En Popüler 10 Programlama Dili
Bugünün ve Yarının En Popüler 12 IT Mesleği