# Geçici Çözümlerin Uzun Ömrü

Neden geçici çözümler üretiyoruz?

Tipik olarak, çözülmesi gereken acil bir sorun vardır. Takım zincirindeki bir boşluğu dolduran bazı takımlar, geliştirme ekibinin içinde olabilir. Eksik işlevleri gideren bir geçici çözüm gibi harici olabilir, son kullanıcılar tarafından görülebilir.

Çoğu sistemde ve ekipte, sistemden bir şekilde ayrılmış, bazen değiştirilecek bir taslak olarak kabul edilen, kodun geri kalanını şekillendiren standartları ve yönergeleri takip etmeyen bazı yazılımlar bulacaksınız. Kaçınılmaz olarak geliştiricilerin bunlardan şikayet ettiğini duyacaksınız. Oluşturulmalarının nedenleri çok ve çeşitlidir, ancak geçici bir çözümün başarısının anahtarı basittir: Yararlıdır.

Bununla birlikte, ara çözümler atalet (veya bakış açınıza bağlı olarak momentum) kazanır. Orada olduklarından, nihayetinde yararlı olduklarından ve geniş çapta kabul edildiğinden, başka bir şey yapmaya hemen gerek yoktur. Bir paydaş hangi eylemin en fazla değeri katacağına karar vermek zorunda kaldığında, bir ara çözümün uygun entegrasyonundan daha yüksek sıralarda yer alan pek çok kişi olacaktır. Niye? Çünkü oradadır, çalışır ve kabul edilir. Algılanan tek dezavantajı, seçilen standartları ve yönergeleri takip etmemesidir, birkaç niş pazar dışında, bu önemli bir güç olarak kabul edilmez.

Böylece geçici çözüm yerinde kalır. Sonsuza kadar.

Ve bu geçici çözümle ilgili sorunlar ortaya çıkarsa, onu kabul edilen üretim kalitesiyle uyumlu hale getirecek bir güncelleme sağlanması olası değildir. Ne yapalım? Bu geçici çözümde hızlı bir geçici güncelleme genellikle işi yapar. Ve büyük olasılıkla iyi karşılanacaktır. İlk ara çözümle aynı güçlü yönleri sergiliyor... sadece daha güncel.

Bu bir sorun mu?

Cevap, projenize ve üretim kodu standartlarındaki kişisel payınıza bağlıdır. Sistemler çok fazla ara çözüm içerdiğinde, entropisi veya dahili karmaşıklığı artar ve sürdürülebilirliği azalır. Ancak, bu muhtemelen ilk önce sorulacak yanlış sorudur. Bir çözümden bahsettiğimizi unutmayın. Tercih ettiğiniz çözüm olmayabilir, herhangi birinin tercih ettiği bir çözüm olmayabilir, ancak bu çözümü yeniden işleme motivasyonu zayıftır.

Peki bir sorun görürsek ne yapabiliriz?

1. Her şeyden önce geçici bir çözüm yaratmaktan kaçının.
2. Proje yöneticisinin kararını etkileyen güçleri değiştirin.
3. Olduğu gibi bırakın.

Bu seçenekleri daha yakından inceleyelim:

1. Kaçınma çoğu yerde işe yaramaz. Çözülmesi gereken gerçek bir sorun var ve standartların çok kısıtlayıcı olduğu ortaya çıktı. Standartları değiştirmek için biraz enerji harcayabilirsiniz. Onurlu olsa da sıkıcı bir çaba... ve bu değişiklik, elinizdeki problem için zamanında etkili olmayacak.
2. Güçler, gönüllü değişime direnen proje kültüründe kök salmıştır. Çok küçük projelerde başarılı olabilir, özellikle de sadece sizseniz ve önceden sormadan pisliği temizleyebilirsiniz. Proje, gözle görülür bir şekilde durdurulacak ve temizlik için biraz zaman tanınacak kadar dağınıksa da başarılı olabilir.
3. Önceki seçenek geçerli değilse, statüko otomatik olarak uygulanır.

Birçok çözüm üreteceksiniz, bazıları geçici olacak, çoğu faydalı olacak. Ara çözümleri aşmanın en iyi yolu onları gereksiz kılmak, daha şık ve kullanışlı bir çözüm sunmaktır. Değiştiremeyeceğiniz şeyleri kabul etmek için [huzur](http://en.wikipedia.org/wiki/Serenity_prayer), değiştirebileceğiniz şeyleri değiştirmek için cesaret ve aradaki farkı bilmek için bilgelik bahşedilsin.

[Klaus Marquardt](http://programmer.97things.oreilly.com/wiki/index.php/Klaus_Marquardt) Tarafından
