Search Results for: java

Yazılım Karmaşıklığı ve Değişim – I

Yazılım Mühendisliği , , , ,

Yazılımın en temel iki özelliği, karmaşıklık ve değişmedir.Yani yazılım ürünleri aşırı karmaşık ve çok sık değişmesi gereken yapıdadırlar. F. Brooks, “No Silver Bullet” isimli makalesinde, yazılımın asli (essential) özelliklerinden bahsederken, diğer iki özelliğinin yanında (görülemezlik (invisibility) ve uyumluluk (conformity)) karmaşıklık ve değişebilirlikten bahseder. Görülemezlik ve uyumluluk özelliklerini, karmaşıklığın ve değişebilirliğin sebeplerinden birer tanesi olarak görürsek, “yazılım asli olarak karmaşık ve değişebilirdir” diyebiliriz.

Yazılım, soyuttur, kavramsaldır, görünmezdir, dolayısıyla anlaşılması ve anlatılması zordur. Yazılımın genelde örneği yoktur; aynı türden yazılım olsa bile farklılıkları çok fazladır, dolayısıyla birinden diğerine geçiş yapmak ya da birinden diğerini türetmek imkansızdır. Çünkü yazılımın bileşenleri kendi başlarına özeldirler, benzerleri yoktur. Bu anlamda yazılımda aynı “şey”den (satır, blok, metot, sınıf, dosya, modul, vs.) iki tane olması istenmeyen bir durumdur. Zaten eğer iki şey benzer ise birleştirilirler. Tekrar kullanılabilirlik bu yüzden son derece zordur. Dolayısıyla yazılımların büyümesi var olan bileşenlerin büyümesiyle değil de yeni ve orijinal bileşenlerin eklenmesiyle gerçekleşir.

Yazılım sistemlerinin bütün durumlarını (state) düşünmek, elde etmek, test etmek, dokümante etmek vs. imkansızdır. Çünkü, soyut kavramların durumlarını belirlemek genel olarak ya çok zordur ya da imkansızdır.

Yazılımların bileşenleri arasındaki ilişkiler de doğrusal (linear) değildir. Fiziksel dünyada, sistemler fiziksel kısıtlarla çevrelendiğinden, alt sistemler ve parçalar arasındaki ilişkileri kontrol altında tutmak mümkündür. Örneğin, bir aracın kasasının, tekerleklerle olan bağlantısı, son derece basit, standart ve akıllıca tanımlanmıştır öyle ki bu standartlara her araç ve jant üreticisi uyar; böylece aracınızı nereden almış olursanız olun, istediğiniz yerden jant ya da lastik alıp, aracınıza takabilirsiniz. Aracınızın tekerleklerini değiştirmek, sileceklerde ya da akaryakıt filtresinde bir etkiye sebep olmaz. Yazılımda durum nasıldır? Yazılım sistemlerindeki karmaşıklık öylesine büyüktür ki aynı karmaşıklığa araçlarda sahip olsaydık muhtemelen bir tekerleğin çalışmasını anlamak için bujiden tutun da sileceklere, kaportadan tutun da antene kadar pek çok şeyi anlamamız gerekecekti.

Benzer durum değişim için de geçerlidir. Son derece karmaşık yapıdaki yarış arabalarının bir yarış esnasında dört tekerleğini değiştirmek 15-20 saniyede yapılabiliyor. Benzer karmaşıklıktaki bir yazılımın, tekerleğe karşı gelen, benzer büyüklükteki bir modülünü bırakın tamamen değiştirmeyi, böyle bir yazılımın en basit bir tarafıni bile değiştirmek günler hatta haftalar sürebilir. Karşılaştırma yapmak zor, farkındayım, ama uğraştığımız alanın kendine has özelliklerini anlamak ancak böyle kıyaslamalı örneklerle mümkün oluyor. Bu anlamda eğitimlerde çok sıklıkla tekrarladığım bir örneğim vardır: “Geçenlerde arabamın lastiklerini değiştirttim. Sonra yolda geri dönerken yağmür yağmaya başladı ve silecekleri çalıştırdım. Ama baktim ki silecekler çalışmıyorlar. Ne olabilir diye düşünürken aklıma lastikleri değiştiren ustayı aramak geldi. Belki orada bir şey olmuştur diye düşündüm. Usta da bana, ‘evet Akin abi, lastikleri değiştirince ilk bir – iki saat silecekler çalışmaz’ dedi.” Böyle bir şey yaşasak herhalde ustam şaka yapıyorsun değil mi deyip karşılıklı gülerdik. Peki böyle bir durum bir yazılım sisteminde olsa, hiç bir yazılımcıyı hiç şaşırtmaz ama. Çünkü, yazılımın parçaları arasındaki bu türden, kontrolsüz bir şekilde kurgulanmış ilişkiler o kadar yaygındır ki, aksini düşünmek zordur.

Fiziksel dünyada değişimi kolaylaştırmak amacıyla, sık değişecek şeyler kolay değişecek şekilde tasarlanmışlardır. Değişmesi zor olan parçalar genelde pek de sık değişmeyecek parçalardır. En sık değişen parçaları, işinin ehli olmayan insanlar bile değiştirebilirler. Ama örneğin trigger kayışı (ya da timing belt), genelde 60.000, 80.000 km gibi aralıklarla değiştiğinden, değişimi zor ve zaman alan bir parçadır.

Karmaşıklık

Robert E. Wood, 1986 yılında yayınladığı bir “Task Complexity: Definition of The Construct” isimli makalesinde, bir işin teorik yapısında üç parça olduğunu ifade eder:

• İşin ürettiği çıktılar (products)

• İşin yapılması sırasında gerekli işler (işlemler) ve davranışlar (required acts)

• İşin yapılması sırasında karar verirken gerekli bilgi parçaları (information cues)

Bu teoriyi yazılım sistemlerine uyguladığımızda, yazılımın karmaşıklığının sırasıyla en temel üç faktörü olarak şunları sayabiliriz:

• Program parçalarının karmaşıklığı: nesneler, metotları ve aralarındaki statik ilişkiler (temelde bilme ilişkisi),

• Program girdileri ve çıktıları arasındaki kamaşıklık: girilen veriler ve eventler ile üretilen hizmetler, GUI yapıları, nesne, veri, rapor, vs. arasındaki yapı, d.nüşüm ve işlemlerle ilgili karmaşıklık (zamansal, prosedürel ilişkiler),

• Veriler ve bilgi karmaşıklığı: işlenen veri yapılarının durumları ile sahip olunması gereken bilginin karmaşıklığı.

Bu üç karmaşıklık faktörünü şu şekilde de ifade edebiliriz:

Bileşen Karmaşıklığı = Program parçalarının karmaşıklığı + Veri/bilgi karmaşıklığı
Koordinasyon Karmaşıklığı = Program girdileri ve çıktıları arasındaki kamaşıklık

Bileşen karmaşıklığı, bileşenin alt parçalarının ne kadar “birlikte” (cohesive) olduğunun bir ölçüsüdür. Yani bir bileşen, ne kadar birlikteliği yüksek ise o kadar az karmaşıktır. Birliktelikten kasıt ise tek bir şeye odaklılıktır. Bir yazılım bileşeni, ister bir satır olsun ister bir blok, ister bir metot isterse de bir sınıf olsun, hatta isterse bir bileşen olsun, tek ama tek bir şeye odaklı olmalıdır. Birliktelik İngilizce’de cohesion olarak ifade edilir ve arzu edilen şey, highly-cohesive yani yüksek birliktelikli yapılardır çünkü karmaşıklıkları düşüktür.

Yüksek birliktelikli yapılar, aynı yerde birden fazla şeyi halletmeye çalışmazlar, sadece bir şeyi ama her yönüyle halletmeye odaklanırlar. Bu anlamda Osmanlıca’da tanımın tanımı olarak verilen “efradını cami ağyarını mani” sağlıklı nesneler için de geçerlidir. Yani nesneleriniz öyle olmalıdır ki bir konuyla ilgili her şeyi hallederken, ilgisiz olan hiç bir şeye de bulaşmamalıdır. Birlikteliği düşük sistemlerin anlaşılması, kodlanması, bakımı, testi, dokümantasyonu vs. hepsi çok daha zordur.

Koordinasyon karmaşıklığı, bir işin ne kadar kendi başına ifade edilebilirliğinin ya da diğerleriyle ne kadar “ilgili” olduğunun ölçüsüdür. İlgililik, diğerleri hakkında bilgidir yani bağımlılıktır (coupling) ve bağımlılığı düşük olan bileşenlerin karmaşıklığı da düşüktür. Bir bileşen oalbildiğince sadece ve sadece kendi hakkında bilmelidir, diğerleriyle ilgili bilgisi ise olabildiğince minimal düzeyde kalmalıdır. Bağımlılık İngilizce’de coupling olarak ifade edilir arzu edilen şey, lowly-coupled yani düşük bağımlılıklı yapılardır çünkü karmaşıklıkları düşüktür. Dolayısıyla, çevresindeki diğer nesnelerle alakası, bilgisi az olan nesnelerın bağımlılıği düşüktür, bu yüzden böyle nesneler daha kolay anlaşılır, aktarılır, kodlanır, test edilir ve dokumante edilirler.

Bu anlamda, gerek karmaşıklığı gerek ise değişimi yönetebilmek için yüksek birliktelikli ve düşük bağımlılıklı (highly-cohesive and lowly-coupled) yapılar kurgulamalıyız.

Toplam görüntülenme sayısı: 1812

Scala’ya Başlamak

Bilgisayar Bilimleri, Java

Malum, Java çok uzun süredir bir dil değil, yani sadece bir dil değil, aynı zamanda bir platform. JVM’in standartlar üzerine kurgulanmış, oturmuş ve yüksek performanslı yapısı, irili ufaklı pek çok dil için nefis bir run-time ortamı oluşturmakta. Bu yüzden yanlış bilmiyorsam 100’den fazla dil ya da dilcik var ki JVM üzerinde çalışabiliyor, yani JVM için bytecode üretiyor. Örneğin Groovy’i, statik tipli (statically-typed) bir dil olan Java’ya dinamizm kazandırmak için geliştirilmiş bir dil. Ben de onu dinamik tipli (dynamically-typed) bir dil olarak kullanmıştım, Java’nin statik yapısını dinamikleştirmekte faydalanmıştık Groovy’den. Benzer şekilde son zamanlarda fonksiyonel diller de sık kullanılır hale geldi. Scala da, yapı olarak Java’ya çok benzeyen bir dil olan Groovy’nin tersine, tamemen farklı bir söz dizimi ve gramerle, JVM eko sisteminde kendine güzel bir yer bulmuş durumda. Burada detaylarına fazla girmeyeceğim ama ileride bir vesileyle ele alacağım fonksiyonel programming paradigmasının yapılarını, nesne-merkezli yapılarla harmanlayarak topa giren Scala, açıkçası Java’nın hemen en başından bu yana arka tarafta, sessiz ama sağlam adımlarla gelişmiş bir tarihe sahip.

Bu yazıda bir dil olarak Scala’ya nasıl başlanırdan bahsedeceğim.

Kurulum ve İlk Program

Scala’yı makinanızda iki farklı türde çalışır hale getirebilirsiniz. İlki Scala’nın “interactive build tool”u olan sbt aracılıgıyla. Sbt, Scala’nın Maven vari bir aracı ve buradan temin edilebilir. Ben Mac’imde indirdiğim zip dosyasını, bir yere kopyalayıp, bin klasöründe içeriği aşağıdaki gibi olan bir “sbt.sh” dosyası oluşturdum ve bu klasörü path değişkenine ekledim. Artık “sbt.sh” diyerek bu etkileşimli Scala ortamına ulaşabiliyorum. Bu amaçla bu sayfadaki manual installation bilgilerine bakabilirsiniz.

SBT_OPTS="-Xms1024M -Xmx1536M -Xss1M -XX:+CMSClassUnloadingEnabled -XX:MaxPermSize=256M"
java $SBT_OPTS -jar `dirname $0`/sbt-launch.jar "$@"

Etkileşimli Scala ortamında, derlemek ve çalıştırmak yanında, “console” diyerek ulaştığınız Scala shell’i de mevcut. Scala’yı öğrenmek için bu etkileşimli konsol ortamı son derece basit ve hızlı iş görerek faydalı olmaktadır, dolayısıyla sbt ortamını muhakkak kurun derim.

Bir diğer yol ise Eclipse ortamınızı bir Scala IDE’ye çevirmek. Bunun için buradan Scala güncelleme linkini kullanarak, Eclipse IDE’nizi Scala tanır hale getireceksiniz. Orneğin şu anda burada Scala IDE 4.0.0 Milestone 1’in Eclipse için güncelleme linkleri mevcut. Yapacağınız şey Eclipse’inizdeki Help menüsünün altındaki “Install New Software”i tıklayarak Scala IDE özelliklerini Eclipse’inize kazandırmak. Eclipse’inizi tekrar başlattığınızda, Scala özelikleriniz hazır demektir.

İster Eclipse’i kullanarak isterseniz herhangi bir editörü kullanarak örneğin aşağidaki gibi ilk Scala programınızı yazabilrisiniz:

package org.javaturk.scala.ch01.selam1

object SelamObject {
//  def main(args: Array[String]) = println("Selam :), naber?")

  def main(args: Array[String]) {
    println("Selam :), naber?")
  }
}

Yukarıdaki kod, isimsiz (anonymous) bir sınıfın SelamObject isimli nesnesini oluşturup üzerindeki standart main fonksiyonunu çağırıyor. Farkedeceğiniz gibi yukarıdaki kodda main fonksiyonun tanımı iki farklı şekilde yapılmış durumda.

Aslında yukarıdaki kod, sınıfını da tanımlayarak şöyle yazılabilirdi:

package org.javaturk.scala.ch01.selam1

/**
 *  This is a class with a function.
 */
class SelamClass1 {
  
  def selamSoyle(name: String) = println("Selam " + name + " :)")

}

Bu durumda aşağıdaki gibi bir test sınıfı ile yukarıdaki sınıfın nesnesini oluşturup ondan hizmet alabiliriz:

package org.javaturk.scala.ch01.selam1

/**
 * Test object of SelamClass1
 * @author akin
 */
object SelamClass1Test {
  def main(args: Array[String]) {
    var selamClassObject = new SelamClass1
    selamClassObject.selamSoyle("Ali")
    selamClassObject.selamSoyle("Yesim")
  }
}

Madem Scala, JVM’de çalışabiliyor ve Java ile etkileşim halinde, o zaman aşağidaki gibi bir Java test kodu da yazabilirim:

package org.javaturk.scala.ch01.selam1;

/**
 * SelamClass1's tester class.
 * @author akin
 *
 */
public class SelamClass1JavaTest {

	public static void main(String[] args) {
	     SelamClass1 selamClassObject = new SelamClass1();
	     selamClassObject.selamSoyle("Mihrimah");
	}
}

 

Nasıl Öğrenirim?

Scala’yı öğrenmek için belki de ilk yapacağınız şey, DZone’un referans kartlarından Scala için olanına ulaşmak. Bu adresten temin edebileceğiniz bu 6 sayfalık giriş dokümanını okumak, tecrübeli programcılar için hızlı bir başlama imkanı sağlayacaktır.

Scala ile ilgili en güzel öğretici bilgilere online olarak ulaşabilirsiniz.  Sanırım bunlardan en merkezi olan Scala’nin kendi sayfasındaki dokümantasyondur. Scala’nin specification dosyasına, APIsine ve pek çok diğer tutoriala buradan ulaşabilirsiniz. Ayrıca piyasadaki Scala kitaplarıyla ilgili bilgilere de buradan ulaşabilrisiniz.

Ayrıca aralarında Scala’nın yaratıcısı Martin Odersky’nin dersinin de bulunduğu pek çok online video eğitimine buradan ulaşabilirsiniz.

Scala’ya başlamak böyle kolay ve hızlı ama ilerlemek biraz farklı. Özellikle fonksiyonel özellikleri ilk etapta kafa karıştırıcı gelebilir.

Toplam görüntülenme sayısı: 6527

Tasarım Kalıpları – I: Giriş

Java, Yazılım Mühendisliği

Tasarım Kalıpları (Design Patterns), uzun süredir en hararetli ve en saygın kavramlardan addediliyor, kaliteli programlamanın, gerçek nesne-merkezli yazılım geliştirmenin olmazsa olmazlarından görülüyor. Yersiz bir anlayış da değil tabi. Ben de uzun süredir bu konuda yazmak istiyordum. Hatta bu yazıya çok önce başladım ama yayınlanması bugüneymiş.

Tasarım Kalıpları, Design Patterns’in dilimizdeki bir kaç karşılığından birisi. “Design”in “Tasarım” olarak çevrilmesinde problem yok. Peki ya “pattern”i nasıl çevirmeli? Asıl derdim tabi olarak bu kelimenin nasıl çevrileceğinden çok anlamıdır. Şöyle anlatabilirim İngilizce’deki pattern kelimesinin anlamını: Ben ufakken devamlı annemin bana ördüğü kazakları ve süveterleri giyerdim. Annem hamarat bir kadındır ve dikiş, örgü vs. konularında da eğitimlidir. Çok sıklıkla, sokakta giderken kadınların beni durdurup, “örneğini” almak için kazağımı incelediklerini hatırlarım. Kadınların benim kazağımdan almaya çalıştıkları şey, bizim dilimizde “örnek”, İngilizce’de ise “pattern”dır. Zaten Mariam-Webster sözlüğündeki açıklamalardan birisi de “something designed or used as a model for making things <a dressmaker’s pattern>” şeklindedir. Bu yüzden model kelimesi belki daha iyi karşılardı “pattern”ı. Bu anlamda bence kalıp, desen ya da şablon anlamlı ve uygun çevirilerdir. Ama örüntü gibi kelimelere alışamadığımı belirteyim.

Yazılım dünyasına bu kelimenin girişi yazılımcılarla değil Christopher Alexander isimli bir mimar ile oldu. Kendisi yüzyıllar boyunca insanlığın bina ettiği yapılardaki mimari özellikler üzerine çalışırken “design pattern” kavramını geliştirdi. Alexander tasarım şablonları ile ilgili olarak şöyle demektedir: “Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice.“

Bu güzel tanımı dilimizde ifade edecek olursak: “Her bir kalıp (önce) ortamımızda tekrar tekrar olan bir problemi tanımlar ve sonra da bu problem için çekirdek bir çözümü tarif eder öyle ki siz bu çözümü bir milyon defa kullansanız bile, hiç birisini aynıyla iki defa kullanmazsınız.“

Bu anlamda tasarım kalıbi, bir bağlamda sıklıkla karşılaşılan tasarım problemine genel (generic), soyut (abstract) ve tekrar kullanılabilen (reusable) bir çözümdür. Tasarım kalıpları soyutturlar, diller seviyesinde değil tasarım seviyesinde ifade edilirler. Bundan dolayı tasarım kalıpları anlatılırken sıklıkla class ve sequence diyagramlarını kullanırız. Tasarım kalıpları soyut olduklarından, her uygulanmalarında, bağlama ve ihtiyaca göre şekillendirilirler. Bu yüzden aynı tasarım kalıbını defalarca uygulasanız bile hiç bir iki uygulamanız birbirisinin aynısı olmayabilir.

Tasarım kalıpları, temel nesne-merkezli prensipleri kullanarak doğru sorumlulukları bulmamıza (finding responsibilities), değişimi göz önüne alarak bu sorumlulukları nesnelere dağıtmamıza (highly-cohesive objects) ve nesneleri, aralarında az bağımlılık olacak şekilde (lowly-coupled objects) kurgulamamıza yardımcı olur. Bir başka deyişle tasarım kalıpları, yüksek birliktelikli ve düşük bağımlılıklı yapıları nasıl kurgulayacağımızı, sıklıkla karşılaşılan problemler bağlamında, model olarak ortaya koyar. Bu anlamda tasarım kalıplarını kullanmadan doğru düzgün bir tasarım yapamayız desek sanırım abartmış olmayız. Çünkü tasarım kalıplarının çözdüğü ve bir kısmını hemen aşağıda sıraladığım problemler, her ortamda sıklıkla karşımıza çıkan problemlerdir.

Tasarım kalıplarının modelledikleri problemlerden bazıları şunlardır:

  • Nesneleri nasıl yaratırız?
    • Karmaşık nesneleri nasıl yaratırız?
    • Nesne ailelerini nasıl yaratırız?
  • Bir sınıftan sadece bir ya da belirli sayıda nesne nasıl yaratırız?
  • Nesnelere erişimi nasıl kontrol ederiz?
  • Nesneler arasındaki bütün-parça ilişkisini nasıl tasarlarız?
  • Bir işi yapmanın pek çok yolu varsa bunları nasıl ifade ederiz?
  • Emir-komuta ya da olay-bilgilendirme zincirini nasıl oluştururuz?
  • Bir sürü nesne arasındaki haberleşmeyi nasıl yönetiriz?
  • Bir nesneye çalışma zamanında yetkinlik nasıl kazandırırız?
  • Karmaşık duruma sahip olan nesneleri nasıl yönetiriz?
  • Nesnenin durumunu nasıl saklar ve sonra yine ulaşırız?
  • Birden fazla nesneyi nasıl yönetiriz?
  • Aynı işi birden fazla nesneye nasıl uygularız?

Bir tasarım kalıbının temelde dört bileşeni vardır:

  • İsmiki o şablonu, problemi ve çözümüyle birlikte ayırt etmemizi sağlar,
  • Problem ki hangi bağlamda nasıl ortaya çıktiğını ifade eder,
  • Çözüm ki parçaları ve aralarındaki ilişkileri ifade eder,
  • Sonuçlar ki kazanılan ve kaybedilenleri ifade eder.

Tasarım kalıpları çoğu defa bize, normalde nesne-merkezli programlama dili kullanmamıza rağmen prosedürel anlayışla yazılım geliştirmeye düşmekten kaçınmamızı sağlar. Bu yüzden normalde tek bir metot altında pek çok “if” ile yaptığımız “functional decomposition” tarzındaki yapıları, nesne seviyesinde nasıl ifade edeceğimizi bize öğretir.

Aslında “tasarım kalıpları” kavramı yayıldıktan sonra sadece tasarımın değil farklı konuların da kalıpları ortaya çıkmaya başladı. Bu sebeple “security patterns”, “performance patterns” gibi kavramlar oluştu. Bu anlamda ele aldığımız “tasarım kalıpları”, karmaşıklığı ve değişimi yönetmek amacıyla oluşturulmuş, iş alanından ve mimari katmanlardan bağımsız modellerdir. Programlama dillerine has tipik kullanımlar ya da kalıplar da mevcuttur. Örneğin Java’da bir Map nesnesinin üzerindeki değerlerin alınması için yaptığımız tipik işlemler vardır. Bu gibi dile özel yaklaşımlara, kalıplara “idiom” denir.

Tasarım kalıpları tipik olarak sınıf seviyesinde ifade edilirler. Mimari kalıplar ise daha çok modüller ve katmanlar (layer/tier) bazında ifade edilirler.  Örneğin Model-View-Controller (MVC) mimari bir kalıptır. Ayrıca mimari kalıpların, tasarım kalıplarından beslendiği de söylenebilir.

Tasarım kalıplarını şu amaçlarla öğreniriz:

  • Tekerleği yeniden keşfetmemek, var olan ispatlanmış çözümleri kullanmak. Tasarım kalıpları yukarıda saydığımız ve sayamadığımız problemleri çözerek, tekrar kullanılabilen, faydası ispatlanmış modeller ortaya koyar.
  • Formal ve yaygın bir dil oluşturmak. Tasarım kalıpları, formal bir kalıp dili (pattern language) oluşturmaktadır. Bu dilin yazılım geliştiriciler arasında yayılması, anlaşmayı kolaylaştıracak, ifade gücümüzü arttıracaktır.
  • Tasarıma uygun, yüksek soyutlama gücü kazandımak, detaylardan sıyrılıp, daha yüksek hedefler cinsinden düşünmek. Bu anlamda tasarım kalıpları daha iyi bir yazılım geliştirici hatta mühendisi olmanın en temel gerekliliklerindendir.

Tasarım kalıpları üzerine ilk çalışmalar, yukarıda da bahsettigim gibi Christopher Alexander tarafindan yapılmıştır. Sonrasinda Trygve Reenskaug, Smalltalk’la MVC (Model-View-Controller) üzerine çalışmışlardır. Benzer şekilde 80’li yıllarda Kent Beck ve Ward Cunningham, Smalltalk ile tasarım kalıpları uzerine calışmalar yapmışlardır. 1994 yılında ise Gang of Four (GoF) – Dörtlü Çete olarak adlandırılan Eric Gamma, Richard Helm, Ralph Johnson ve John Vlissides, ünlü “Design Patterns” kitabını yazmışlardır.    

Dörtlü çete kitaplarında 3 farklı kategoride toplam 23 tane kalıba yer vermişlerdir:

  • Creational – nesneleri yaratmakla ilgili olan 5 tane,
  • Structural – nesneler arasindaki yapısal iliskileri ifade eden 7 tane,
  • Behavioral – nesnelerin çalışma zamanı davranışlarını değiştirmek için 11 tanedir.

Sonrasında çıkan kitaplarda başka şablonlara da yer verilmiştir ama genelde tasarım kalıpları denince bu 23 tanesi anlaşılır.

Şimdilik burada bırakalım. Sonraki yazılarda bu konuya devam ederiz.

Bol tasarımlı ve dahi kalıplı günler dilerim 🙂

Toplam görüntülenme sayısı: 6237

Temiz Kod Nasıl Yazılır? – Basitlik İlkesi – I

Java, Yazılım Mühendisliği , ,

Bu yazıda, daha önce paylaşmış olduğum Temiz ve Kaliteli Kod Nasıl Yazılır? başlıklı yazıda bahsettiğim kaliteli kodun ilkelerinden olan basitliği ele alacağım.

Sanılanın aksine bir şeyi basit tutmak zordur, uzun bir şekilde ele almak çok daha kolaydır. Çünkü bir şeyi ilk defa yaparken büyük bir ihtimalle en uzun şekliyle, en zor haliyle yaparız. Ancak o konuda tecrübe sahibi oldukça, anlayışımız, yetkinliğimiz gelişir ve işin aslına odaklanabiliriz. Basitleştirmek, bir şeye tümüyle, her yönüyle hakim olup, asıl ile teferruatı ayırmak, neyin gerekli neyin gereksiz olduğuna karar vermektir, orasını burasını gelişi güzel budamak değildir. İlkini yapan beğenilir, ikincisini yapan indirgemeci olmakla ya da aşırı basitleştirmekle eleştirilir. Einstein’e atfedilen “her şey olabilidiğince basit olmalı, ama daha da basit değil” (everything should be made as simple as possible, but no simpler.) ya da “her şeyi olabildiğince basitleştir, ama daha da basit yapma”  (make things as simple as possible, but not simpler.) cümleleri aslında bunu ifade eder.

Bir şey ne zaman mükemmele ulaşır? Mükemmellik nasıl elde edilir? Kamaşıklıkla mı yoksa basitlikle mi? Küçüklükle mi büyüklükle mi? Mükemmellik sonuçta insan taktiridir. İnsan ise basiti daha rahat anlar ve taktir eder, karmaşığı anlamak zordur. Eğer aynı iş, bir basit bir de karmaşık yöntemle yapılabiliyorsa, akl-ı selim olan herkes basit olanı seçer. Mükemmellik tabi olarak algıya bağlıdır ama sanırım Fransız yazar Antoine de Saint-Exupery‘ın şu sözü mükemmel olmanın en temel özelliği olan basitliği çok güzel bir şekilde ifade etmektedir: “Mükemmellik, eklenecek bir şey olmadığında değil, çıkarılacak bir şey olmadığında başarılır.” (Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.) Dolayısıyla küçük her zaman güzeldir. Küçüklük dışında bir güzelleştirme aramaya gerek yoktur.

Basitleştirmek çok sağlıklı ve sağlam bir anlayış, vukufiyet gerektirir. Bu anlayış ve vukufiyeti kazanmak hem zeka hem bilgi ve tecrübe hem de çalışma gerektirir. (Bu anlamda “basit”liği, ele yüze bulaştırmadan, basit bir şekilde anlatmak o kadar zor ki! Hele benim gibi mükemmelliyetçi birisi için. Özellikle yazılım ve programlama gibi aslında zaten anlaşılması ve tarif edilmesi zor olan soyut yapılar için bir çırpıda basit olmayı anlatmak bence çok daha zor bir iş. En azından benim boyumu aşar. Yani bu yazıyla her türlü karizmayı çizdirme riskini göz önüne almış oluyorum. 🙂 Bu yüzden bu yazıyı önce yayınladım sonra geri çektim, üzerine bayağı düşündüm, yaz-boz yaptım ve eskiden bu yana düşündüğüm ama formal bir hale dökemediğim “basit”likle ilgili biraz daha geliştirdiğim anlayışımı paylaşıyorum.)

Basitliği tarif etmek zor hayattaki pek çok şey gibi ama ters örnekleri gördüğümüzde en azından bu basit değil diyebiliriz. Örneğin şu yazıda bahse konu olan ifade kesinlikle basit değil. Bu ifadenin basit olmayıp son derece karmaşık olmasına sebep olan şey bence iki tanedir: İlk ve en temel sebep, bir yerde birden fazla şey yapmak. Yani bir yerde pek çok şeyi halletmeye çalışmak, odaklanmamaktır. Karmaşıklığın en temel sebebi ise budur. Bu bir içerik problemidir ve genelde problemlerin en kötüsü, üstesinden en zor gelinenidir. İkincisi ise, bir cümlede (statement) birden fazla ifade (expression) kullanılmış olmasıdır. Bu tabiki ilk problemin bir sonucu ve şekilsel bir durum. Bütün bunlara bir de Java’daki “?:” operatöründe çok akışkan olmayan yani çok aşina olmayan bir programcı eklenince, anlamak hakikatten çok zor hale geliyor.

Kodun basitliğine gelirsek, basit yazılan kodun temelde iki özelliği vardır: Anlaşılırdır ve kısadır. Anlaşılır olmak için şekil açısından öncelikle kod standartlarına daima uyulmalıdır. Eğer bir sebepten dolayı uyulamazsa bu durumu sebebiyle birlikte belirtilmelidir ki insanlar şaşırıp burada fazladan zaman harcamasınlar. Dolayısıyla anlaşılır kod,

  • anlaşılır isimler içeren,
  • ferah, mekanı etkin kullanan dolayısıyla rahat okunan,
  • tutarlı yani şaşırtmayan, beklendiği gibi, aşina olunan,
  • açıklanmış (commented) koddur.

Bunlar anlaşılır kodun şekil şartlarıdır. Bu amaçla paylaştığım isimlendirme ve şekil standartlarına buradan ulaşabilirsiniz.

İçerik açısından ele alındığında anlaşılır kod, okuyananın çok zeki ya da konuya çok hakim olmasına gerek bırakmadan kavranan koddur. Martin Fowler, Refactoring isimli güzel kitabında “Herhangi birisi bilgisayarın anlayacağı kod yazabilir. Fakat iyi programcılar insanların anlayabileceği kod yazarlar.” (Any fool can write code that a computer can understand. Good programmers write code that humans can understand.) der. Dolayısıyla programcı öncelikle kendi anlaması için kod yazmalıdır. Kodunu yazdıktan sonra dönüp bir bakmalı, 3 ay ya da 1 yıl sonra bu kodu anlamak için ne kadar enerji harcayacağını düşünmelidir. Bu anlamda soru “bir kod parçasının kendini ne kadar açık bir şekilde okuyucusuna anlattığı”dır?

Anlaşılır olmak belki bir kaç farklı seviyede ele alınmalıdır. Yani bir kodun anlaşılır olması, sadece o kodun anlaşılır bir şekilde yazılmaya çalışılmasıyla elde edilemeyecek kadar geniş ya da çok faktörlü bir problemdir. Çünkü kod bir son çıktıdır ve kendinden önceki ihtiyaç analizi, mimari ve fonksiyonel tasarım gibi çalışmalar sonucunda üretilebilir. Bu anlamda anlaşılırlık, iş (business) seviyesinden başlamalıdır. Yani basitlik en temelde iş seviyesinde ele alınmalıdır. Yapılacak işin ne kadar kısa, öz, tutarlı olduğu o işin koduna da etkir. Karmaşık bir iş kuralını basit yazmak zordur örneğin. Soru öncelikle “o iş kuralı o kadar karmaşık mı olmalıdır”dır. Ya da “yazılım ile otomatikleştirmeye çalıştığımız süreçlerimiz en basit, en kısa ve en anlaşılır halinde midir” sorularının cevaplanması gereklidir. Bu noktada ünlü felsefeci Adorno’nun “yanlış hayat doğru bir şekilde yaşanamaz” (wrong life cannot be lived rightly) sözü akla geliyor. Karmaşık iş yapış şekillerini basit bir halde koda dökmek zordur diyebiliriz yani. Ülkemizde gelişi güzel, parça parça ya da yazılıma geçirme safhasında akla gelip kurgulanan süreçler gibi problemlerden dolayı zaten iş yapış şekillerimiz sağlıklı değildir, çoğu zaman da onu yapan kişiye bağlıdır. Dolayısıyla süreçleri bölük pörçük, örneğin “ekran” ya da “sayfa” düzeyinde ele alınarak analiz edilmeye çalışılmış bir iş alanın iş kurallarını kodunuzda örneğin nasıl yönetebilirsiniz ki?

İş seviyesinden sonra mimari seviyede basitlikten söz etmeliyiz. Mimarinin ne olduğunu biliyoruz; katmanlar (tiers), bileşenler (components), bunların arayüzleri, aralarındaki ilişkiler, protokoller, “kim kiminle konuşacak”, “hangi bileşen neyi yapacak”, “performans, ölçeklenirlik, güvenirlik, güvenlik vb. kriterleri nasıl sağlayacağız” gibisinden sorular, kullanılacak teknolojiler, donanım mimarisi, sistemin topolojisi vs. hep mimarinin konusu. Mimari bu anlamda sistemin yüksek seviyeli bir taslağıdır.

Mimari bileşenlerin ve aralarındaki ilişkilerin ne kadar basit ve anlaşılır oldukları kesinlikle çok önemlidir. Bu noktalarda alınan kararlar açık bir şekilde ne kadar basit kod yazdığınızı etkiler. Daha doğru ifadeyle mimari kararlar kodunuzun ne kadar basit yazılabileceğini doğrudan etkiler. Kötü oluşturulmuş mimari, karmaşık bir mimari, ya da baştan güzel kurgulanan ama sonra özellikle kontrolsüzlükten ve sisteme giren çıkan yeni programcı vs.nin var olan mimariyi özümsemeden, bilinçsiz ve pragmatik olarak yaklaşmalarından dolayı rayından çıkmış bir mimaride kodunuzu ne kadar basit yazabilirsiniz ki? Java EE’nin ya da Spring’in teklif etmiş olduğu mimariler, mimari şablonlar (architectural patterns) aslında uygulandığı taktirde daha rahat bir yapı kurgulamanızı ve nihayetinde daha basit kod yazmanızı sağlayan yaklaşımlar olarak son derece önemlidirler. Bu anlamda Demeter Kanunu (Demeter Law) sadece sınıflar düzeyinde geçerli değildir, bileşenler ve katmanlar düzeyinde de dikkat edilmesi gereken bir prensiptir. Benzer şekilde daha sonra ele alacağımız “odaklılık” konusu tabi olarak mimari için de geçerlidir.

Daha sonra tasarım seviyesinde basitlik ele alınmalıdır. Sınıf, arayüz, metot vb. yapılar ve aralarındaki ililşkiler, basitlik üzerine kurgulanmadıkça basit kod yazamazsınız. Eğer yazılım geliştirme sürecinizde bir tasarım safhası yoksa o zaman hakikatten basit kod yazmanız çok zor. Çünkü tasarım demek kodunuz hakkında düşünmek demektir. Kodunuzu düşünmeden yazdığınızda çoğu zaman kaliteli ve basit kod yazmaya odaklanamazsınız. Kodu doğru yazmaya, iş mantığını doğru bir şekilde yansıtmaya daha fazla odaklanırsınız. İş, mimari ve tasarım seviyesinde ele alınmayan konuların getirdiği bütün yük üzerinizdedir. (Bu yüke technical debt deniyor.) Bunlar o kadar fazla sayıda faktör olarak ortaya çıkarlar ki zaten zihninizin bu kadar çok şeyi aynı anda halletmesi son derece güçtür. Bu durumda ister istemez kötü kod yazarsınız, basit yazayım derken performansı gözden kaçırırsınız mesela. 

Tasarımda yapılacak, sorumlulukları nesnelere atama, nesneler arasındaki ilişkileri düzenleme, değişmesi muhtemel kısımlarla diğer kısımları birbirinden yalıtma, bu amaçlar için tasarım şablonlarını kullanma vb. çalışmalar, kodunuzun kalitesini doğrudan etkiler. Hatta tasarım çalışmaları sonuçta sistemde var olacak her türlü tipin arayüzünü belirlediği için, kod kalitesi büyük oranda tasarımda belirlenir. Bu anlamda bir tasarım çalışması yapmadan kaliteli kod yazmak aslında hayaldir. Ya da kaliteli kod ancak düzgün bir tasarım çalışmasının çıktısı olabilir.

Bu yazıda burada bırakalım. Belli ki basitliği ancak bir kaç yazıda tamamlayabileceğim. Bir sonraki yazıda daha detaylı bir şekilde basit kodun özelliklerinden bahsedelim.

Hoşçakalın…

Toplam görüntülenme sayısı: 9323

«< 51 52 53 54 55 >»