Pragmatik Programcı — 4

Pragmatik Yaklaşım

Yazılım geliştirmeye uygulayabileceğimiz bazı tavsiyeler ve püf noktaları muhakkak var. Bunlar sorgulanamaz veya gerçek anlamda evrensel diyebiliriz ama çok azı yazılı olarak belirtilmiştir.

Çoklamanın Zararları

Programcılar olarak, bilgiyi toplar, organize eder, bakımını sağlar ve çalıştırırız. Şartnameler ile bilgiyi dökümante ederiz, çalışan kod haline getirir ve testler ile kod kontrolü sağlarız.

Maalesef, bilgi durağan değildir. Müşteri ile yaptığın son toplantı sonucuyla, hükümetin yeni bir düzenlemesi ile, seçilen bir algoritmanın yanlış çalışması vb. birçok etken ile bilgi değişir. Bütün bu kararsızlık yüzünden zamanımızın büyük bölümünü bilginin bakımına, tekrar düzenlenmesine ve tekrar yazılmasına adarız.

Birçok insan bakımın, uygulamanın yayınlanmasıyla başladığını düşünür. Bizce bu yanlıştır. Programcıların anlayışı günden güne değişir. Kodlama ve tasarım aşamasında yeni gereksinimler ortaya çıkar. Çevresel değişiklikler olabilir. Sebep her ne olursa olsun, bakım işi ayrı bir aktivite değil, bütün geliştirme sürecine yayılan bir rutindir.

Bakım yapılırken en kolay düşülecek hatalardan biri, bilgiyi çoklamaktır. Bu da bakım kabusuna yol açar.

Yazılımı güvenli bir şekilde yapmak, geliştirmelerimizi daha kolay ve anlaşılır yapabilmek için DRY(Don’t Repeat Yourself, Kendini Tekrar Etme) prensibini takip etmeliyiz.

Her bir bilgi parçası tek, kesin, yetkileri belli olan bir sistem içinde olmalıdır.
11. Tavsiye: Kendini tekrar etme

Buna alternatif durum aynı ifadenin iki veya daha fazla yerde yer almasıdır. Birini değiştirsen, diğerini unutursun. Hatırladığın zaman sıkıntı olmaz, asıl sıkıntı unuttuğun zaman başlar.

Çoklama Nasıl Ortaya Çıkar

Dayatılan çoklama: Geliştiricilerin çoklamaktan başka seçeneği olmadığı düşündüğü zaman ortaya çıkar.

Yanlışlıkla yapılan çoklama: Geliştiriciler çoklama yaptığının farkında olmaz.

Sabırsız çoklama: Geliştirici tembeldir ve çoklama daha kolay görünür.

Geliştiriciler arası çoklama: Takımdaki farklı geliştiriciler ya da farklı takımlardaki geliştiriciler bazı bilgileri çoklayabilir.

Bunların detayına bakalım biraz.

Dayatılan Çoklama

Bazen bizi dış etkenler çoklamaya zorlar. Bu dökümandan kaynaklı olabilir, farklı hedef platformlar kendi dil, kütüphanesinde geliştirme istiyor olabilir. Programlama dilleri bile bazı yapıları çoklamayı zorunlu tutabilir. DRY prensibi ile çoklama yapmanın önüne geçebileceğimiz bazı teknikler:

Bilginin çoklu gösterimi: Kod seviyesinde, bazı bilgilerin farklı formlarda gösterimini isteriz. Sunucu-istemci uygulaması geliştiriyorsunuz, sunucu veya istemci tarafında farklı diller kullanmışsınız ve bu ortak yapıyı göstermeniz gerekiyor. Belki veritabanında ki tabloların karşılığına denk gelen sınıflara ihtiyacınız var.

Bunları önlemek için basit yöntem, bir filtre veya kod üreten bir yapı oluşturmak. Farklı dillerdeki yapılar ortak bir metadatadan oluşturulur. Sınıf tanımlarını veritabanındaki şemalardan üretilebilir. Buradaki püf nokta, bu sürecin tek seferlik yapılmaması, sürecin aktifliğinin ve devamlılığının sağlanması gerekir.

Koddaki yorumlar/dökümantasyonlar: Bize hep iyi kodun yoruma/dökümantasyona ihtiyacı olduğu söylenmiştir. Tam tersine kötü kod daha çok yoruma ihtiyaç duyar. Kendini Tekrarlama prensibi bize kodda en az bilgiyi tutmamız gerektiğini söyler. Aksi takdirde bilgiyi çoklarız. Bu da her değişiklikte kodda ve yorumda değişiklik demektir. Bir süre sonra yorumlar güncelliğini kaybeder. Hiç yazılmamış yorum güvenilmez yorumlardan efdaldir.

Dökümantasyon ve kod: Dökümantasyonu yazarsın sonra kodu yazarsın. Bir şeyler değişince, dökümantasyonu onaylatıp, kodu güncellersin. Bazı zamanlar gelir ki proje teslim tarihi çok yakın olur ve dökümantasyonu güncellemeyi öteleriz. Bu da daha büyük sıkıntılara yol açabilir. Daha önce sıkı bir test durumları ve bunların dökümantasyonları isteyen bir şirket için, geliştiriciler şöyle bir yol izledi. Dökümandan test durumlarını otomatik oluşturan bir yapı geliştirildi ve müşteri dökümanı değiştirince birkaç saniye içinde testleri oluşturan bir yapı sağlandı.

Dil mevzusu: Birçok programlama dilleri çoklamaya zorlayabilir. C/C++ gibi diller modül tanımı ve gerçeklemesini ayrı tutar. Bu yüzden başlık(header) dosyaları, isimleri, dışa açılan değişkenleri, fonksiyonları gibi birçok şeyi çoklar. Uzak prosedür çağrıları kullanıyorsanız, arabirim(interface) bilgilerini gerçeklediğiniz yerde çoklamanız gerekir.

Bunların üstesinden gelmenin kolay yolu yoktur. Bazı geliştirme ortamları C/C++’da ki başlık dosyalarını otomatik üreterek, yönetimini kolaylaştırır.

Yanlışlıkla Yapılan Çoklama

Bazen çoklamalar tasarımdaki yanlışlıklardan kaynaklanır.

Kargo dağıtım sektöründen bir örnek verelim. Kamyonun bir tipi, lisans numarası ve sürücüsü vardır. Benzer şekilde, varış yolunun da bir yol güzergahı, bir kamyonu ve sürücüsü olur.

Sürücünün hastalandığını değiştirilmesi gerektiğini düşünelim? Hem Kamyon hemde VarisGuzergahi sınıflarında sürücü nesnesi var. Hangisini değiştirmeliyiz şimdi? Açık şekilde görülüyor ki tasarımda bir hata var. Belki burada ikisinde de sürücü nesnesine gerek var mı bunu sorgulamalı veya sürücü nesnesini başka bir yer üzerinden ortaklaştırmalıyız.

Şimdi de şu örneğe bakalım:

İlk bakışta burada her şey normal gibi gözüküyor ama uzunluk(length) değişkeni başlanğıç ile bitiş arasındaki fark olduğu için burada bir çoklama var. Bunu şu şekilde hesaplanmış alan yapabiliriz:

Sabırsız Çoklama

Her projenin zaman baskısı vardır bu da bize en iyisini yapmak yerine kısayoluna sapmamıza yol açar. Yeni bir fonksiyon mu yazılacak? Mevcut olanı önce kopyala sonra onun üzerinden değişikliklerini yap. Java üzerindekine benzeyen bir sınıfa mı ihtiyaç var? Zaten kaynak dosyasında var neden onu almayayım?

Böyle bir eğilime doğru gidiyorsan şunu unutma, “kısayolların uzun gecikmelere yol açar”. Şimdilik kazandığın saniyeler ilerde senin saatlerine malolabilir.

Geliştiriciler Arası Çoklama

Belki de en zor bulunan çoklama hatalarından biri bir projedeki farklı geliştiriciler arasında meydana gelen çoklamadır. Bazı fonksiyonlar hatalıca çoklanmış ve bu çoklama yıllarda anlaşılmadan devam etmiş olabilir. ABD’de Y2K probleminde(bilgisayarların 2000 yılına girmesi) 10.000 kadar program her biri kendi Sosyal Güvenlik numarası kontrolü yaptığı için her birinin üzerine yama yapmak gerekti.

Temiz bir tasarım, sağlam bir proje lideri ve tasarımdaki sorumlulukların iyi anlaşılması ile bu sorunlar bir nebze çözülebilir ama modül seviyesine inince sorunlar daha sinsileşir.

Bunu çözebilmenin en iyi yollarından biri geliştiriciler arası aktif ve açık bir iletişim kanalının olması. Benzer problemlerin taşınabileceği forumlar kurulmalıdır. Bir takım üyesi proje kütüphanecisi olarak seçilebilir ve onun görevi bilgi paylaşımını kolaylaştırmak olur.

12. Tavsiye: Tekrar kullanmayı kolaylaştır.
İnsanların kendileri yazmalarındansa, varolan şeyleri tekrar bulup kullanmalarını teşvik edecekleri bir ortam kur.

İnsanlar kolay değilse kullanmayacaklardır ve bu da çoklama riskini artırır.