Pragmatik Programcı — 6
Tersine Çevrilebilme
- Bu yazı The Pragmatic Programmer kitabından anladığımın özetidir. Orjinal halini buradan alabilirsiniz.
- Önceki yazıyı buradan okuyabilirsiniz.
Hiçbir şey, tek bir düşünceye sahip olmandan daha tehlikeli değildir. Emil-Auguste Chartier, 1938
Mühendisler problemlere karşı basit ve tekli çözümleri tercih ederler. Matematik testleri, ki sana mesela x=2 olduğunu söyler, belirsiz ve sayısız Fransız Devrimi sebepleri hakkında makale yazmaktan daha kolay gelir.
Bu kolaylık, sadece gerçek dünya işbirliğine giderse bu şekilde devam eder. Maalesef, x bugün 2’dir ama yarın 5 olabilir, haftaya 3 belki de. Hiçbir şey kalıcı değildir, bunun değişeceğinden kesinlikle emin olabilirsiniz.
Bir şeyleri gerçekleştirmek için her zaman birden fazla yol vardır ve üçüncü-parti ürünleri şirketinize sağlayabilmek için de her zaman birden fazla satıcı vardır. Bir şeyi yapmak için tek bir yolun olduğu algısının işlendiği bir projeye gittiyseniz, hoş olmayan sürprizlerle karşılaşabilirsiniz. Birçok proje takımları, gelecek daha da belirgin hale gelirken, mecburi olarak gözlerini açarlar.
Programcı itiraz etti, “Ama siz XYZ veritabanını kullanacağız demiştiniz ve biz kodlamanın %85’ini bitirdik, şimdi değiştiremeyiz.”. Yönetici cevap verdi, “Üzgünüm ama şirketimiz, bütün projelerde, PDQ veritabanında standartlaşmayı kararlaştırdı. Elimde olan bir şey değil. Yeniden kodlamanız gerekiyor. Hepiniz tekrar bildirilene kadar haftasonları bile çalışmanız gerekiyor.”
Değişikliklerin bu kadar radikal veya çabuk olmasına gerek yok. Bununla birlikte, zaman ilerlerken, proje devam ederken, bazen kendini savunulmaz bir pozisyonda sıkışmış bulabilirsin.
Zamanla kritik kararlar verilir. Burada ki problemli nokta şudur ki, kritik kararlar kolaylıkla tersine çevrilemez.
Bir satıcının veritabanını, mimari modelini veya yaygınlaştırma modelini kullanmaya karar verdiğinizde, bunu büyük bir olay olmazsa, geri çevrilmeyecek bir hareket olarak görme eğiliminiz olur ama bu yanlıştır.
Tersine Çevrilebilme
Bu kitapta ki birçok konu, esnek ve uyarlanabilir bir yazılım üretmenin ne olduğunu anlatmaya çalışmaktadır. DRY(Don’t Repeat Yourself, Kendini Tekrarlama) prensibi, ayrıştırma(decoupling) ve metadata kullanımı gibi tavsiyelere bağlı kalarak, kritik ve tersine çevrilemeyen kararlar almak zorunda kalmayız. Bu iyi bir şeydir, çünkü genelde biz ilk seferlerde en iyi kararları alamayız. Bazı teknolojileri kullanmayı taahhüt ederiz, çünkü bu teknolojilerin benzerini yapabilecek yeterli sayıda adam almaya gücümüz yetmez. Gereksinimler, kullanıcılar ve donanım, biz geliştirilmiş yazılımı elimize alıncaya kadar çoktan değişmiş olur.
Mesela, projenin ilk aşamalarında, A satıcısından ilişkisel bir veritabanı kullanmaya karar verdiniz. Sonradan, performans testleri sırasında, bu veritabanının çok yavaş olduğunu farkettiniz. Buna karşın, B satıcısından nesne veritabanının daha hızlı olduğunu gördünüz. Birçok geleneksel projelerde, şansınız yoktur, çünkü üçüncü-parti ürünlere yapılan çağrılar kodunuzun her tarafına saçılmıştır. Eğer gerçekten veritabanınızı projenizden soyutlamışsanız, ki burada kısaca PAAS(persistence as a servise) sistemine işaret ediyoruz, nehrin ortasında at değiştirecek kadar esnekliğe sahipsiniz demektir.
Benzer şekilde, projeniz istemci-sunucu modeli ile başlamış olsun, sonradan pazarlama bölümü, sunucuların çok pahalı olduğuna karar verdi ve tek-başına(stand-alone) çalışan versiyonunu istediler. Bu ne kadar zor olabilir? Bu sadece yaygınlaştırmanın konusu olduğu için, bunun birkaç günden fazla sürmemesi gerekir. Daha uzun sürüyorsa, tersine çevrilebilme konusunda hiç düşünmediğiniz anlamı çıkar.
Burada ki hata, herhangi bir alınan kararın, bir şeylerin üzerine taş dökmek gibi kalıcı olduğunu düşünmemiz. Kayalar içine oyulmuş kararlar yerine, onları kumsaldaki kuma yazılmış kararlar olarak görmemiz gerekiyor. Büyük bir dalga gelebilir ve bütün kararları silip süpürebilir.
14. Tavsiye: Nihai karar yoktur.
Esnek Mimari
Birçok insan kendi kodlarını esnek tutmaya çalışırken, aynı zamanda mimari, yaygınlaştırma ve satıcı entegrasyonu gibi alanlarda da esnekliği sağlayabilmesi gerekir.
Herhangi bir Windows sürümüne göre mi kod geliştiriyorsunuz? Hangisi — 95, 98, NT, 2000, XP, Vista, Windows 7, Windows 10? Diğer versiyonları desteklemek ne kadar zor olabilir? Kararlarınız yumuşak ve esnek tutarsanız, bu o kadar da zor olmaz. Eğer zayıf kapsülleme(encapsulation), yüksek bağlanma, kod içinde mantık ve parametre kullanımı var ise, bu mümkün olmaz.
Normalde, üçüncü-parti ürünleri iyi-tanımlanmış, soyut bir arabirim ile basitçe projenizden saklayabilirsiniz. Gerçekte, çalıştığımız bütün projelerde böyle yapmışızdır. Farzedin ki bunu temiz bir şekilde izole edemediniz ve bunu kodun birçok yerinde kullanmanız gerekti? Bu gereksinimi metadata içinde saklayınız ve bunu otomatik üreten ve koda enjekte eden nmekanizmalar kullanınız. Her ne mekanizma kullanıyorsanız, tersine çevrilebilir olsun. Bir şey otomatik olarak eklenebiliyorsa, otomatik olarak da çıkarılabilir olmalı.
Geleceğin ne getireceğini kimse bilemez, bu yüzden mümkün olduğunca projemizden çıkarmak isteyebileceğimiz, tersine çevrilebilir sistemler kullanmalıyız.