“Eğer sahip olduğun tek aletin çekiç ise her problem çivi gibi görünür.” Twain? Maslow? Kaplan? Kim demişse demiş. Doğru da demiş ama. Yazılım dünyasında hemen hemen her gün bu sözün gerçekleşmesine şahit oluyorum.
Ürettiğimiz makineyi ayarlamak için binlerce parametremiz var. Evet, tahmin ettiğiniz gibi bizim çekicimiz de parametreler. Geçen gün iki eleman yüksek gerilim kaynağı ile haberleşme protokolü üzerine tartışıyordu. Yeni protokol eski protokole de benziyor biraz. En azından ikisi de binary protokol. Yani insan tarafından okunmasına gerek olmayan, sadece makine için tasarlanmış bir protokol. Tabii içerikte de birkaç fark var. Neyse, elemanların biri “bu yeni bir alet, üretici farklı, kullanılan protokol de farklı. O zaman yeni bir protokol tanımlayıp diğerinden ayrı programlaman lazım” derken diğeri de “ama o zaman bir sürü kod yazmam lazım. Protokoller arasındaki farklar da çok değil, üç parametre ile bu işi halledebilirim” tezini savunuyordu. Bunun üzerine ilk eleman “öyle yaparsan ilk protokolü de değiştirmiş olursun, bu durumda eski güç kaynaklarını yine test etmemiz gerekir” şeklinde karşı saldırıya geçti. İkinci eleman da “sadece üç yerde değişiklik olacak. Onların testi de kolayca yapılabilir” diye karşılık verdi. Başka işlerim olduğu için bu tartışmaya pek dalmadım ama kendimi birinci elemanın düşüncesine daha yakın buluyorum. Schrödinger’in programları gibi programları sevmiyorum. Bir bakışta programın ne yaptığını anlamak isterim.
Bu hafta yine buna benzer bir tartışma oldu. Bu sefer işin ucu bana da dokunuyordu. Benim yazdığım modül de yapılacak değişikliklerden etkilenecekti. Kontrol birimi her gün belli bir saatte bana belli bir mesaj gönderece ve ben de bu mesaja göre belli bir işlem yapacağım. Bu işlemin sonucunu da kontrol birimine geri göndereceğim. Yani çok basit ve temel bir işlem. Daha önce de defalarca yapmışız. Tabii ki sorun şu: Harika bir proje yönetimi ve beklenmeyen aksilikler yüzünden bu işi yapmak için bir gün zamanımız kalmış. Problem, aynı anda üç değişik modülde değişiklik yapmak yerine bunu tek modülde değişiklik yaparak nasıl yaparız şekline indirgenmiş. Kontrol biriminin bana göndermesi gereken mesaja benzer bir mesajı zaten daha önce programlamış olduğumuz için bütün işi kontrol birimine yıktık. Bir süre sonra kontrol birimi programcıları bu mesajın aynı işi yapamayacağını buldu. Zaman da azalmıştı. Bunun üzerine yeni bir mesaj tanımlamak yerine (o zaman üç modülde değişiklik gerekecek) bir parametre kullanmayı (sadece bir modül etkilenecek) teklif ettiler. Görünüşe göre istenen çözüm de böyle olmalıydı ama parametrenin sorunu şuydu: Bu parametrenin anlamı ve yaptığı iş normal bir kullanıcı ya da servis elemanı için hiç de kolay anlaşılır bir şey değildi. Dolayısıyla ileride bir sürü gereksiz telefon görüşmesi gerekecekti. Sonuçta parametrenin yaptığı iş şu olacak: İlk modülün gönderdiği mesajın aslında başka bir mesaj olduğunu söyleyecek ve kontrol birimi de bu durumda bu mesajı eski mesajımıza uygun hale getirip (içindeki bir miktar bilgiyi atıp) gönderecek. İşin komik tarafı projedeki asıl plan işin sadece ilk modülde yapılmasıyken birden iş ikinci modüle, kontrol birimine, kaymış oldu. Hiç kimsenin hoşuna gitmedi ama başka türlü pazartesiye yetişmesi de mümkün değildi heralde. Bu arada, ben cuma günü işten çıktığımda kontrol birimi bu işi hala bitirememişti.
Parametrelerle bir çok şey yapılabilir, bir sürü problem çözülebilir ama burada tasarruf ettiğimiz zaman bize dokümantasyon, hata arama, elemanların eğitimi, kullanıcıların hayatını zorlaştırma şeklinde geri dönebilir. Sonuçta parametreler de bir tür programlamadır ve bu tür çekiçler kullanarak işi böylece bizden sonrakilere, yani hem kullanıcılara hem de bu sorunları düzeltecek programcılara bırakmış oluyoruz.