İki değişkenin değerlerini değiş tokuş yapmak için bitwise operatörlerini kullanan XOR swap algoritmasını ele alın. Bir zamanlar bu verimli bir yöntemdi. Fakat modern CPU’lar pipeline’ları kullanarak birden fazla komutu paralel olarak çalıştırarak performansı arttırıyor. Bu XOR swap’te işe yaramıyor. Bugün XOR swap’i kullanarak kodunuzu optimize etmeye kalktıysanız, daha yavaş çalışabilir çünkü yeni CPU’lar farklı tekniklerden yararlanıyor.
Çok çekirdekli CPU’lar durumu daha da karmaşıklaştırıyor. Onların avantajından yararlanmak için, çok izlekli (multithreaded) kodlar yazmanız gerekiyor. Ne yazık ki paralel işlemi doğru yapmak güç. Bir izleği hızlandıran optimizasyonlar, diğerlerini kazara yavaşlatabilir. İzlek sayısı arttıkça programın optimizasyonu zorlaşıyor. Bir yordamın optimize edilebilir olması edilecek olması anlamına gelmiyor. Çoğu program zamanın yüzde 90’ında kodlarının sadece yüzde 10’luk bölümünde çalışıyor.
Birçok durumda en iyisi kendi araçlarınıza güvenmenizdir. 1975’te Fred Brooks bazı derleyicilerin, elle yazılan kodların yenemediği sonuçlar ürettiğini gözlemledi. Bu günümüz için de doğru. Bu yüzden gerekli olmayan manüel optimizasyonlarla zaman harcamayın. Kodunuzun verimliliğini geliştirme yarışında, geliştirici verimliliğin de o kadar önemli olduğunu hatırlayın.
Programlama Efsanesi No. 7: İyi kod ya “basit”tir ya da “mükemmel”
Çoğu mühendis gibi programcılar problemler için “mükemmel” veya “basit” çözümler bulmak hakkında konuşur. Tehlike, bunun yazılım kodunu değerlendirmede zayıf bir yola dönüşmesidir.
Bu tanımlar tam olarak ne anlama geliyor? Basit bir çözüm mükemmel olanın aynısı mı? Mükemmel bir çözüm bilgiişlemsel olarak verimli olan mı yoksa en az kod kullanan mı?
Her ikisini ararken çok fazla zaman harcayın ve iyi programlamanın felaketiyle karşılaşma riskini alın: zeki çözüm. O kadar zekicedir ki takımdaki diğer üyeler kodun nasıl çalıştığını anlayana dek oturup bulmaca çözmek zorunda kalır. Anladıktan sonra bile ona dokunmaya cesaret edemezler; parçalara ayrılır korkusundan.
Çoğu durumda, çözüm kendi iyiliği için çok zekicedir. 1974’deki kitapları “The Elements of Programming Style,”da Brian Kernighan ve P.J. Plauger, “Herkes debug işinin programı yazmaktan iki kat daha güç olduğunu bilir. Peki bunu yazacak kadar zekiyseniz, onu nasıl debug edeceksiniz?” diye yazmışlardı. Bu yüzden, başkası bunu nasıl yürütecek?
Yani, bir programlama problemine en “mükemmel” çözümü bulmaya konsantre olmak, diğer bir tür prematüre optimizasyondur. Problemi çözmek birincil hedef olmalıdır.
Bu yüzden okunması, yönetimi ve debug’ı kolay olan kodlar yazmak yerine kendilerini onurlandırmayla ilgileniyor gözüken programcılardan sakının. İyi kod o kadar basit olmayabilir. İyi kod mükemmel olmayabilir. En iyi kod çalışır, gayet güzel çalışır ve hatasızdır. Neden daha fazlası istensin?
