Eski Yazılımı Büyük Bir Yeniden Yazım Olmadan Modernleştirmek

Köklü hemen her işletmede bir tane vardır: herkesin sessizce nefret ettiği bir yazılım. Yavaştır, çirkindir, ekibin yarısı kimsenin hiç düzeltmediği o hata için bir kestirme yol bilir ve onu anlayan tek kişi 2019'da ayrıldı. İçgüdü hep aynıdır: yak gitsin, yenisini kur. Ve bu içgüdü çoğu zaman, iyi şirketlerin bir yılı ve küçük bir serveti boşa harcamasının tam da yoludur.

Büyük yeniden yazımın ters gittiğini yeterince gördüm; artık ona karşı bir reflesim var. Bir kurucu bana gıcırdayan sipariş sistemini ya da kadim planlama aracını gösterir, içini çeker ve “sadece tüm bunu değiştirmemiz gerekiyor.” cümlesinin bir biçimini söyler. Belki bir gün gerçekten yaparsınız. Ama tam yeniden yazım — eski sistemi söküp atmak, paralelde yepyeni parlak bir tane kurmak, bir düğmeyle geçmek — tüm yazılım dünyasının en riskli hamlelerinden biridir. Pahalıdır, vaat edilenden çok daha uzun sürer ve tüm bu süre boyunca körü körüne ilerlersiniz; yeni şeyin, eski şeyin on beş yıl boyunca sessizce hallettiği her tuhaf uç durumu kapsamasını umarsınız.

İyi haber şu ki büyük yeniden yazım neredeyse hiçbir zaman tek seçenek değildir, en iyisi olması da nadirdir. Modernleştirmenin daha sakin bir yolu var — kademeli, geri alınabilir ve siz çalışırken hâlâ para kazanmak zorunda olan işe nazik. Bu, o yola dair bir rehber: gerçekten neyin düzeltilmesi gerektiğini nasıl ayırt edersiniz, tüm sistemi çökertmeden acı veren parçaları nasıl değiştirirsiniz ve tam bir yeniden yazımın gerçekten doğru karar olduğunu ne zaman anlarsınız.

Büyük yeniden yazım neden bu kadar cazip ve bu kadar tehlikeli

Tam yeniden yazım baştan çıkarıcıdır çünkü temiz bir sayfa vaat eder. Artık eski karmaşa yok, artık ödün yok, modern araçlarla doğru biçimde kurulmuş taze bir kod tabanı. Beyaz tahtada apaçık görünür. Gerçekteyse, yılların biriken iş mantığını yeniden kurmaya imza atıyorsunuz — büyük kısmı belgesiz, bir kısmı yalnızca ayrılmış insanların aklında yaşıyor — bu sırada saat işliyor ve faturalar geliyor.

Daha derin tuzak paralel evren sorunudur. Yedeği kurmanın aldığı aylar ya da yıllar boyunca iki sisteminiz olur: hâlâ işi yürütmek zorunda olan eski olan ve henüz hazır olmayan yeni olan. İşin ihtiyaç duyduğu her değişiklik iki kez yapılmalı, yoksa yeni sistem daha hiç yayına girmeden gerçeğin gerisinde kalır. Ekipler ikisini de hayatta tutarken tükenir. Ve yeni sistem her şeyi yapana kadar kimsenin geçmesine izin verilmediği için erken bir kazanım, geri bildirim ya da çalıştığının kanıtı olmaz — yalnızca devasa, hep ya da hiç bir lansman gününe doğru uzun, kaygılı bir bekleyiş.

Burada sektörün iyi bilinen bir folkloru var ve hak edilmiş: ikinci sistem, o büyük yeniden yazım, tahmin edilenin üç katı kadar sürme ve yerine geçtiği şeyden daha az özellikle gelme alışkanlığındadır. Tahmin, insanlar dikkatsiz olduğu için yanlış değildir. Başlangıçta kimsenin, eski sistemin sessizce doğru yaptığı tüm küçük şeyleri göremediği için yanlıştır.

“Eski/miras” aslında ne demek (mesele yaş değil)

Miras sözcüğünü, sanki sadece “eski” demekmiş gibi öyle bir savururuz. Öyle değil. On yıldır çalışan pek çok yazılım gayet iyidir — sıkıcı, kararlı, parası ödenmiş, işini yapan. Yalnızca yaş, hiçbir şeye dokunmak için bir neden değildir. Bu alanın en pahalı hatası, sırf eski göründüğü için sessizce çalışan bir şeyi modernleştirmektir.

Yazılım, etkin biçimde önünüze geçtiğinde miras etiketini hak eder. Onu kimse tam anlamadığı için güvenle değiştiremediğinizde. Artık bağımlı olduğunuz araçlara bağlanamadığında. Onu hayatta tutabilen tek kişi tek bir kişi olduğunda. Ekibinizin etrafında bütün bir kestirme yollar folkloru ördüğü kadar yavaş ya da kırılgan olduğunda. Gerçek tanım budur — yazıldığı yıl değil, bugün size yüklediği maliyet ve yarına taşıdığı risk.

Hiçbir şeye dokunmadan önce teşhis koyun

Tek bir satır yeniden yazılmadan önce, acının aslında nerede yaşadığına dair dürüst bir haritaya ihtiyacınız var. Çoğu zaman herkesin nefret ettiği sistem %80 yolundadır. Sorun birkaç belirli yerde yoğunlaşır — bir yavaş ekran, bir bozuk entegrasyon, çift veri girişine zorlayan bir iş akışı — ve bu birkaç yer şikâyetlerin neredeyse tamamını üretir. Onları bulun, tüm projenizi bulmuş olursunuz.

Onları bulmanın yolu önce teknik bir denetim değil — bir sohbettir. O şeyi her gün kullanan insanlarla oturun ve nerelerinin acıdığını sorun. Nerede bekliyorlar? Neyi yeniden yazıyorlar? Acı verdiği için neden kaçınıyorlar? Resmî sistemi aşmak için nerede özel bir tablo tutuyorlar? Bu kestirme yollar altın değerindedir: her biri, düzeltmeye değer bir sorunun tam bir röntgenidir.

• İnsanların en çok şikâyet ettiği ekranlar ve adımlar — teoride değil, gerçek günlük işlerinde.
• İki sistem birbiriyle konuşmadığı için verinin iki kez yazıldığı her yer.
• Bozulan ya da hiç var olmamış, araçlar arasında elle kopyala-yapıştıra zorlayan entegrasyonlar.
• Yalnızca tek bir kişinin nasıl çalıştıracağını ya da düzelteceğini bildiği her şey — tek hata noktalarınız.
• Gerçekten yolunda olan parçalar; böylece onları koruyup oldukları gibi bırakabilirsiniz.
• İşin gelecek yıl ihtiyaç duyacağı ve mevcut sistemin büyüyüp asla ulaşamayacağı şey.

Bunu dürüstçe yaptığınızda proje genellikle küçülür. “Her şeyi değiştirin” diyerek giren işletme sahibi, üç şeyi düzeltmesi gerektiğini fark ederek çıkar. Bu bir hayal kırıklığı değil — bir rahatlamadır. Düzeltilebilir üç şey, bu çeyrekte bitirebileceğiniz bir projedir. Tam değişim ise atlatamayabileceğiniz bir yıldır.

Boğan yaklaşım: onu tek tek parça değiştirin

Bunu güvenle yapmanın bir deseni var ve biraz kasvetli ama akılda kalıcı bir adı var: boğan yaklaşım, boğan incirden geliyor — bir ağacın etrafında büyüyen, yapısını yavaş yavaş ele geçiren ve sonunda yeni büyüme kendi başına ayakta dururken eski gövdeyi yok eden bir asma. Yazılıma uygulandığında fikir harikulade pratiktir: eski sistemi tek bir kahramanca takasla değiştirmezsiniz. Yenisini onun etrafında, her seferinde tek bir parça, kimsenin ihtiyaç duyduğu hiçbir eski kalmayana dek büyütürsünüz.

Uygulamada şöyle işler. Acı veren tek bir parça seçersiniz — diyelim herkesin nefret ettiği faturalama modülü. Yalnızca o parça için modern bir yedek kurarsınız. Faturalamayı yeni modüle yönlendirirsiniz; geri kalan her şey eski sistemde dokunulmadan çalışmaya devam eder. Onu bir süre izlersiniz. Sağlam olduğunda, eski sistemin o kısmı sessizleşir ve siz bir sonraki parçaya geçersiniz. Eski sistem hepten yıkılmak yerine, bir mum gibi yavaş yavaş küçülür.

Bunu bir yeniden yazımdan çok daha güvenli kılan şey, her adımın küçük, canlı ve geri alınabilir olmasıdır. Asla körü körüne ilerlemezsiniz. Her yeni parça hızla gerçek kullanıma girer, böylece gerçekten çalışıp çalışmadığını çabucak öğrenirsiniz. Bir şey ters giderse tüm işi değil, yalnızca bir modülü riske atmış olursunuz — ve düzeltirken genellikle eski yola geri dönebilirsiniz. Sonda tek bir dehşet verici lansman yerine yol boyunca kazanımlar elde edersiniz. Ve iş, tüm bu süre boyunca olağan biçimde yürür.

Ritim gerçekte nasıl görünür

1. 1
   En acı veren, en kendi içinde bütün parçayı seçin

   Yüksek acı ve temiz kenarlar istersiniz — çok acı veren ve parmaklarını başka her şeye sokmamış bir modül. İlk hedefiniz odur.
2. 2
   Eski sistemin önüne ince bir katman koyun

   Küçük bir yönlendirme katmanı, hangi isteklerin eski sisteme, hangilerinin yeni parçaya gideceğine karar verir. Diğer her şeyi mümkün kılan ek yeri budur.
3. 3
   Yalnızca o tek parçayı kurun ve yayına alın

   Bir modülü değiştirin, gerçek ellere verin ve işin yalnızca o dilimini ona yönlendirin. Yıllar değil haftalar — ve sistemin geri kalanı hiç kıpırdamadı.
4. 4
   Kararlı hale getirin, sonra bir sonraki parçaya geçin

   Yeni modüle güvenildiğinde, eski sistemin ona karşılık gelen kısmı uykuya dalar. Yol aldıkça öğrenerek bir sonraki acı veren parçayla tekrarlayın.
5. 5
   Eski sistem boşaldığında emekliye ayırın

   Sonunda eski sistem, kimsenin güvendiği hiçbir işi yapmaz olur. Ancak o zaman onu kapatırsınız — sessizce, dramsız, çünkü önemli olan her şey çoktan taşındı.

Bunun yeniden yazımdan farkına dikkat edin: korkulacak tek bir lansman günü yok. Bakımı yapılacak bir paralel evren yok. Yeni sistem, sürekli ertelenen bir lansman için bir laboratuvarda beklemek yerine üçüncü haftadan itibaren üretimde, ekmeğini kazanıyor ve size bir şeyler öğretiyor.

Bazen onu değiştirmenize bile gerek yoktur

Herhangi bir şeyi değiştirmeden önce, eski sistemin değiştirilmeye mi yoksa yalnızca bir ada olmayı bırakmaya mı ihtiyacı olduğunu sormaya değer. “Yeni bir sisteme ihtiyacımız var” sorunlarının şaşırtıcı bir kısmı aslında “sistemlerimiz birbiriyle konuşmuyor” sorunudur. Eski yazılım işinde gayet iyidir — sadece bir silonun içinde oturur, insanları veriyi elle taşıyıp getirmeye zorlar.

Bu durumlarda en ucuz, en hızlı çözüm yeni bir sistem değildir. Bir köprüdür. Eski yazılımı bir bağlantıyla sararsınız — diğer araçlarınızla otomatik veri alışverişi yapmasını sağlayan bir entegrasyon — ve insanların gerçekten dokunduğu kısımlar için üstüne modern bir katman koyarsınız. Eski motor altta mırıldanmaya devam eder; ekip temiz bir yüzey ve kopyala-yapıştırın sonunu kazanır. Göz alıcı değildir ama çoğu zaman tüm çabada euro başına en yüksek getiridir.

Tam bir yeniden yazım ne zaman gerçekten doğru karardır

Bu rehber boyunca sizi büyük yeniden yazımdan caydırdım, o yüzden adil olayım: bazen gerçekten cevap odur. Öyle çürük temeller vardır ki hiçbir yamalama, köprüleme ya da parça parça değiştirme onları kurtaramaz; tersini varsaymak yalnızca, bir cesedi ayakta tutmak için para harcarken kaçınılmazı erteler.

Dürüst işaretler belirgindir. Sistemin üzerine kurulduğu teknoloji ölü ya da ölmekte — destek yok, güvenlik güncellemesi yok, üzerinde çalışabilecek kimse kalmamış. İş o kadar köklü değişmiş ki eski model gerçeğe artık hiç oturmuyor. Ya da sistem o kadar karışık ki küçük değişiklikler bile alakasız yerlerde sürekli bir şeyleri bozuyor — bu da genellikle boğan yaklaşımını uygulayacak temiz ek yerlerinin baştan olmadığı anlamına gelir. Bunlardan ikisi ya da üçü aynı anda doğruysa, kademeli iş artık daha güvenli seçenek olmaktan çıkar.

Ve önce kademeli işi yapmanın sessiz ödülü şudur, sonunda yine de yeniden inşa etseniz bile: oraya vardığınızda sistemi başlangıçta olduğundan çok daha iyi anlarsınız. Değiştirdiğiniz her modül, özgün yazarların hiç yazmadığı bir şeyi size öğretti. O bilgiyle beslenen bir yeniden yazım, ilk gün iyimserliğiyle yayına alınandan tamamen farklı, çok daha güvenli bir canlıdır.

Kimsenin değinmediği kısım: mesele çoğunlukla insanlar

İşte teknik rehberlerin atladığı bir şey. Eski yazılımı modernleştirmenin en zor kısmı genellikle kod değildir — yıllarını ona uyum sağlayarak geçirmiş insanlardır. Onun acayipliklerini bilirler. Tuhaf kestirmeleri için kas hafızaları vardır. Nesnel olarak daha iyi olan yeni bir modül, yalnızca tanıdık olmadığı için ilk iki hafta yine de daha kötü hissedebilir. Bunu görmezden gelirseniz kusursuz bir teknik geçiş bile başarısız olabilir.

Kademeli yaklaşım burada da, neredeyse tesadüfen, yardımcı olur. Değişim her seferinde küçük bir parça halinde geldiği için insanlar tek bir pazartesi sabahı her şeyi yeniden öğrenmeye çağrılmak yerine onu yavaş yavaş özümser. Günlük kullanıcıları erken dahil edin. Yedek bitmeden onu şekillendirmelerine izin verin. Yeni faturalama ekranını tasarlamaya yardım eden ekip onu savunur; ekranın üzerine bırakıldığı ekip ise birebir aynı olsa bile ona içerler. Modernizasyon, yazılım kostümü giymiş bir değişim yönetimi projesidir.

Sık sorulan sorular