Toplamda: Eski sistemleri nasıl koruyacağız? [kapalı]

NEW YORK - Gökdelenleri titreyen bir patlama ile 83 yaşındaki bir buhar borusu, New York ve diğer ABD şehirlerinin altındaki kilometrelerce boru, tel ve demirin yaşlandığını ve tehlikeli bir şekilde kararsız hale gelebileceğini gösteren güçlü bir mesaj gönderdi.

Temmuz 2007 Manhattan'da Patlama Buhar Borusu Hakkında Hikaye

Yazılım çürümesi ve teknik borç duyduk .

Ve şu şeylerden duyduk:

• "Bob Amca" Martin - Bizi " dağınıklığın sonuçları " konusunda uyardı .
• Michael C. Feathers - Bize 'Eski Kodla Etkili Çalışma' konusunda rehberlik eden kim .

Yani kesinlikle yazılım mühendisliği topluluğu bu sorunların farkında.

Ama toplu toplumumuzun bu sorunların çalışma sistemlerini ve uygulamalarını nasıl rahatsız edebileceğini takdir etmediğini hissediyorum.

Steve McConnell'in belirttiği gibi :

... Finansal borçtan farklı olarak, teknik borç çok daha az görünür ve bu yüzden insanlar onu görmezden gelmek için daha kolay zaman geçiriyorlar.

Bu doğruysa ve inanıyorum ki, o zaman hükümetlerin ve işletmelerin, çok geç olana kadar bilgisayar korsanlarına karşı düzenli bakım ve zenginleştirmeyi erteleyebileceğinden korkuyorum. [NYC ve buhar boruları gibi.]

Benim sorum:

• NYC ve buhar borularının eşdeğer yazılımlarından kaçınmanın bir yolu var mı?

Eski sistemlerin bakımıyla ilgili önemli bir sorun, a) bu sistemlerde hızlanan ve b) sistemlerini korumaya devam etmek isteyen kişilerin eksikliğidir.

Geçenlerde benzer programlarda genç programcıların ana bilgisayarlarla hiç ilgilenip ilgilenmedikleri hakkında bir soru sordum. Fikir birliği no.

Eski sistemlerin bakımı kariyer intiharı olarak görülmektedir. Atalet kurallarının olduğu birçok şirkette, personelin bu sistemlerin üstünde kalması için çok az yatırım vardır ve bu da personel tarafında tek hata noktalarına yol açar. Benzer sistemler üzerinde çalışan tanıdığım birçok insan, sistemlerde uzun vadeli bir gelecek görmedikleri ve sadece kariyer zararı gördükleri için yollar arıyor.

Bazı endüstrilerde, veri bakım düzenlemeleri, eski sistemlerin makul şekilde izlenmesini sağlayan önemli bir faktör olabilir. Özellikle finans endüstrisindeki sorun bu. Bu düzenlemeler - bildiğim kadarıyla - genellikle zaman sınırlıdır.

Ancak, pratikte ne olacağını düşünüyorum:

Grafikte, eski bir sistemin dezavantajları etrafında geçiş yapmanıza izin veren daha modern bir sisteme geçmenin maliyetinin, daha ucuz olduğu için eski sistemi koruma maliyetinin altına düşeceği bir nokta olacaktır.

IBM şu anda çok sayıda ana çerçeve satıyor ve büyük makinelerinin genç profesyonellerin dallarını kapatmamasını sağlamak için çok çalışıyorlar. Ama bu aşamada bunun yeterli olduğunu düşünmüyorum. Karbon ayak izi ve gerçek işlem gücü açısından bazı USP'leri var.

Bununla birlikte, üzerinde Linux çalıştırabileceğiniz için IBM ana bilgisayarını satın alacak her kişi için elektrik maliyeti daha düşüktür ve oldukça verimlidir, bir sunucu çiftliği seçecek birkaç tane daha olacaktır, çünkü bu dünyaya daha aşinalar ve daha birçok programcı da öyle.

Sonuçta çok şey ilgili sektöre bağlıdır. Yıllardır yıllardır ana karelere çok bağımlı olan belirli bir sektörde çalışıyorum ve hala yaygın olarak kullanılıyorlar. Ancak, barındırılan çözümler daha popüler hale geliyor ve bu da daha büyük şirketlerde becerilerin birleştirilmesine izin veriyor - bu, bireysel şirketlerin başarısızlık noktaları açısından karşılaştığı bazı sorunları ortadan kaldırıyor ve ayrıca bazı tedarikçiler ana bilgisayar tabanlı olmayan çözümlere çok güçlü bakıyorlar bu endüstrinin doğasında var olan sorunlar için.

Yani özetle söylüyorum, ekonomik bakım noktası göçle göçün lehine düştüğünde, büyük ölçüde miras sistemlerinden göçe doğru bir hareket olacaktır. Bununla birlikte, birçok insan için büyük ölçüde görünmez olacak, çünkü yeni ve korkak değil ve bir sonraki büyük şeyin yaptığı gibi halka açık bir yüzü yok. Bu taşıma, hizmet sağlayıcılara veya daha yeni teknolojilere (özellikle hizmet sağlayıcıların doğrudan etkilenenler olduğu durumlarda) olabilir.

Benim deneyimim - özellikle ağlarda - eski sistemlere olan güveni ortadan kaldırma yönünde bir hareket olması.

Çoğu işletme halihazırda teknik borçtan habersizdir ve kelimenin tam anlamıyla etraflarında çökünceye ve iflasa gönderene kadar (kötü bir noktaya gelirse) işlerin kötü olduğunu bile fark etmezler. Aslında gördümbu oldu ve güzel değildi; daha da kötüsü, sürekli olarak işletme sahiplerinin artan teknik borcun farkında olmasını sağlamaya çalışmam ve bunun düzeltilmesi gerektiğiydi ve her seferinde düzeltmek için gerekli zaman ve kaynakları harcama isteksizliği nedeniyle reddedildi. o. Sonuç 10 yıl sonra sistem felaketle başarısız oldu (ben gittikten sonra) ve iyileşemediler ve işten çıktılar, çünkü on yıl boyunca biraz para harcayanları gerçekleştirmek için çok aptallardı sorunu tamamen göz ardı etmekten daha iyi olurdu. Ben o şirketin saçma aptallığı hakkında saatlerce atıp olabilir ve hangi sahipleri eğer en tamamen önlenebilirdi edildi beni üzüyordu değildi diğer her şeyi tamamen keserek hızlı bir para kazanmak için dışarı.

Bu onların sistemleri kötü yazılmış ve bazı ağır üstlenmeden (değilse bunun nedeni genelde bu böyledir toplam yeniden yazmak gerek eğer bir iş anlatmaya çalışıyor delicesine zor olduğunu da kötü). Çoğu zaman onlar sadece bunu yeni özellikler değişiklikler yapmak veya eklemek zor olduğunu onları uyarmak bile vurmaya edeceğiz (, sadece kazık üzerine daha bok katman değil, doğru yolu ortalama), hatta düşünün sizi bir mevcut durumda sistemle ilgili sorunlar gördüğünüz için işe zarar verebilir.

Dürüst olmak gerekirse, kaybedilen bir savaş ve savaşmaya değmeyecek bir sonuca vardım. Teknik borcu bilecek kadar zeki insanların bu konuda iki kez söylenmesine gerek yoktur ve başlangıçtan itibaren tehlikelerin farkındadır ve herkes çok geç olana kadar herhangi bir sebep veya uyarı dinlemez. En iyi (ve elbette en gerçekçi olmayan) seçenek, doğal seleksiyonun devreye girmesine ve cahil insanların soyu tükenmesine izin vermek ve sadece akıllı olanları bırakmak olacaktır. Bunu ele almanın daha aşağı bir yolunu bilmiyorum, çünkü geçmişte şahsen denediğim her şey tamamen göz ardı edildi, şirketin gözündeki değerimi azalttı ("şikayet" için) veya hatta Sonlandırıldım çünkü neyin olmadığını düzeltmeye çok fazla odaklandım kırıldı ve kimse kırıldığını görmek için uygun bir zihin durumuna sahip değildi.

New York ve diğer ABD şehirlerinin altındaki kilometrelerce borular, teller ve demir yaşlanıyor ve tehlikeli bir şekilde kararsız hale gelebiliyor.

Anekdot için aynı argüman 16-17. Yüzyılda Paris'te yapıldı. Altına o kadar çok delik ve tünel kazılmıştı (alanın jeolojisine bağlı doğal deliklere ek olarak), ara sıra bir binanın parçalanacağı.

Tüm şehir blokları yere çöktüğünde, gereksiz delikleri ve tünelleri çakıl ve kemiklerle doldurmak için direktifler verildi (ayrıca aşırı kalabalık mezarlık sorunları vardı). Şehir, beton icat edilene kadar bu şekilde hayatta kaldı.

Demek istediğim, birçok kuruluşun herhangi bir yazılım bakımı yapmak için son dakika beklemek eğiliminde olması, ancak kodlayıcılar (inşaat mühendisleri gibi) çok fazla işi hızlı ve iyi bir şekilde hallediyor.

Y2k böceğinden kurtulduk. Y2036 hatası, birçok kuruluşu donanım ve yazılımını yükseltmeye zorlayacaktır. Bilgisayar bilimcileri sosyolog ya da edebiyat eleştirmeni değildir .

Oh, ve bu arada söylenen gibi: Bir sonraki bakıcı nerede yaşadığınızı bilen kısır bir psikopatmış gibi kod yazın.

Unutma, bugünlerde eski kodu ne düşünüyoruz? Geçen yılın kodu, geçen on yılın kodu veya geçen yüzyılın kodu?

Para, eski sistemlerin bakımı etrafında konuşmayı yönlendirir. Teknik borç, sistemi değiştirmek için artan bir maliyet biçimini alır.

Kötü tasarlanmış ve akıllıca tasarlanmış sistemlerle çalıştım. İlginç olan, onları koruma maliyetlerinin çok fazla değişmemesidir. En büyük sorunlar, genellikle ölçeklendirme sorunlarında veya büyük bir değişiklik istendiğinde ortaya çıkan mevcut kullanım için yanlış mimarilerdir. Büyük bir kod alanını tek iş parçacığından çok iş parçacığına kolayca dönüştüremezsiniz.

Yaşadığım en önemli sorunlar kullanılan geliştirme dilleridir. Eski sistemler bugün daha az popüler olan dillerde yazılmıştır, bu nedenle ya daha fazla eğitim almanız ya da daha deneyimli (pahalı) ve nadir kaynaklar kiralamanız gerekir. Her iki durumda da, daha küçük havuz nedeniyle, aynı zamanda çözümler kadar sorunlara yol açan yetenekli bireyler bulmakta da zorlanıyorsunuz.

Söz verilen yeniden yazmaya gelince, büyük yatırımları olan çoğu sistem bir yeniden yazmayı haklı çıkarmaz. Yazılımın ne kadar süre çalışmaya devam edebileceği ve geliştirilebileceği şaşırtıcı. Donanım değişiklikleri (şirketimin özel donanım kullanmayı desteklediği bazı sistemler) en büyük sorunumuz olma eğilimindedir. Geliştirme yeteneği genellikle sadece eski kodu yeni özelliklerle entegre etme mekanizmaları ile sınırlıdır.

Bu zaten büyük bir problem. Ve hiçbir değişiklik belirtisi göstermiyor.

60'larda ve 70'lerde her türlü büyük kurum kağıt üzerinde muhasebe yapmaktan bilgisayar sistemleri üzerinde muhasebe yapmaya kadar gitti. Ezici bir şekilde COBOL'u seçtiler. Çoğu hala bu COBOL sistemlerinin güncellenmiş versiyonlarını kullanıyor. Bununla ilgili bazı istatistikler için http://cis.hfcc.edu/faq/cobol adresine bakın.

Arnold Schwarzenegger'in birkaç yıl önce keşfettiği gibi, ilk önce 6 aylık kalkınma olmadan 200.000 devlet işçisinin ödemesini kesemediği gibi, bunu rastgele hatırlatırız (bkz. Http: //www.infoworld). com / d / geliştirici-dünya / californias-cobol-conundrum-067 ).

Anahtarlama riskleri göz önüne alındığında, bu sistemleri değiştirmeyi haklı çıkarmak çok zordur. Hiç. Bu benim hayatım boyunca gerçek oldu. Ama bu gerçeğin çocuklarımın yaşamında değişmesi için hiçbir neden göremiyorum. Ya da çocuklarının yaşamları.

Onlardan daha eski kodunu korumuş olan arkadaşlarım var. İlk kez orada çalıştıktan 30 yıl sonra bir şirkete geri dönen bir arkadaşım var, programlarının hala hatırlamadığı bir dilde hala değişmediğini bulmak için !

Her ikisinin de olabileceğine dair gerçek bir hikaye ile bitireyim.

1970'lerde bir şirkettüccarlar için bir online pazar sağlamak amacıyla kuruldu. PDP-11 onlar için iyi bir fiyat / performans uyguntu, bu yüzden bunu seçtiler. Bir makinenin performans sınırlarını zorluyorlardı, bu yüzden sistemlerini son derece optimize edilmiş PDP-11 montajında ​​yazdılar. Birkaç yıl sonra PDP-11 satılmayı bıraktı. Ancak iş harikaydı, makineler sürdü ve ikinci el değiştirmeler kolaydı. Platformlarını korudular. Bundan birkaç yıl sonra değiştirmeler zorlaştı. Ticaret platformunun yerine büyük bir proje yapıldı. Başarısız oldu. Tekrar denediler. Ve yine başarısız oldu. Başarısızlığın en büyük nedeni, hiç kimsenin ticaret sisteminin nasıl çalıştığını bilmemesi ve artık PDP-11 meclisini okuyamamasıydı. Sonra kurtuluşa çarptı. Birisi Linux üzerinde çalışan bir PDP-11 derleyicisi oluşturdu.

Böylece, 2000 yılında milyar dolar / yıl ticarete giren ticaretler, ethernet-decnet köprüsü üzerinden Linux makinelerine, son derece optimize edilmiş PDP'de yazılmış bir yazılım sistemi üzerinde ticareti gerçekleştiren taklit PDP-11 makinelerine gitti. 11 montaj. Hız için.

Son on yılda söz konusu şirketle hiçbir bağlantım olmadı. Bu yüzden, hala taklit PDP-11'lerde çalışıp çalışmadığını söyleyemem. Ondalıklaştırmanın marjlarını acı verici bir şekilde sıktığını biliyorum, bu yüzden göç etmek için başka bir çabaları daha vardı. (Hikayeyi sadece öğrendim çünkü oradan işten çıkarılan birkaç kişiyle röportaj yaptım ve ne olduğunu sordum.) Ancak önceki başarısızlıklar göz önüne alındığında, bu sistemi başarılı bir şekilde değiştirmediklerinden bile daha iyi verirdim.

Bir kullanıcının görüşüne göre çok gerçek bir endişe gibi geliyor. Çürümenin ertelenmesi veya daha iyi bir şekilde önlenmesi için, söz konusu yazılımın prangalarından arındırılmış olması gerekir. Yayıncıları kaynak kodunu serbest bırakmış olmalı veya son kullanıcısı kullanmayı bırakana kadar kaynakları koruma ve yükseltme işinde olmalıdır. Aksi takdirde, iş dünyasındaki benzer çürükler nedeniyle işten çıkma şansları çok yüksektir, böylece yazılımı çürümelere tamamen açık bırakırlar.

Yani, yazılım telif hakları ve kısıtlayıcı lisansların süreleri çok kısa olmalıdır, bunun sonunda yazılım ve kod tabanı kamuya girer ve orada kalır. Böylece, kullanıcının kaynakları yükseltmeye devam etmesini veya bunu yapmak için birini işe almasını sağlamak, böylece çürükleri geciktirmek ve / veya kaçınmak.

Veya, özgür yazılım fikrine biraz açıksanız, programlarınızı AGPL veya GPL veya diğer ücretsiz yazılım lisansları gibi ücretsiz bir lisans altında yazabilirsiniz. Gördüğüm kadarıyla, bir yazılımın kaynakları herhangi bir nedenle onu geliştirmek için geliştiricilere daha fazla ilgi göstermediğinde, kaynak tabanı yamyamlaştırılır ve yeni bir hayat alır. Debian işletim sistemindeki paketler, gördüğüm kadarıyla bu yaşam döngüsünü takip etme eğilimindedir.

Çeşitli hükümet ve özel sektör uygulamalarını destekledikten sonra, çoğu şirketin ve en azından ABD Hükümeti'nin kod çürümesine izin vermenin ve en son güvenlik trendlerinin üstünde kalmamasının tehlikelerinin farkında olduğunu söyleyebilirim.

Yazılımımızı çeşitli hassasiyetler için düzenli olarak sertifika almak zorundayız ve çoğu hükümet elektronik sistemi, hatta eski elektronik sistemler, onları güvende tutmak için düzenli güncellemeler almak zorundadır.

Tabii ki istisnalar var ve bilgisayar korsanları her zaman hareket halindeler, ama genel olarak insanların oldukça fazla farkında olduklarını düşünüyorum.

Uyarı: Bu biraz serbest bir form olacak ...

Endişenize bakmanın 2 yolu olduğunu düşünüyorum.

Bunu düşünürseniz, bazı uzay servisleri ve uydular başlangıçta onları başlatan aynı kodu çalıştırıyorlar. Öte yandan, bazıları (çok) uzak olsalar bile güncellenecek şekilde tasarlanmıştır.

Önemli olan çevre. Açıkçası, ortamı değiştirmediğiniz sürece, kodunuz eski haline gelmeyecektir. Bu durumda, kod çürümesi gerçekte mevcut değildir: kodun kendisi (veya üretilen ikili kod) çürümez. Tamamen farklı bir açıdan saldırmaya başlarsanız kırılabilir. Çürümesi değil, çevresine uyum sağlaması değil. Bunu evrimsel bir sorun olarak düşünün.

Ama çevremiz değişiyor. Ve her nasılsa, probleminizin anahtarı da çözümdür. Çevremiz o kadar hızlı değişiyor ki, günümüzde bir yazılım çözümünün zaman içinde gelişmesini beklemiyorduk. Geçtiğimiz yıl güncellenmemiş olan yazılım projelerini göz ardı ediyoruz ve net bir yol haritası üretmeyen ürün ve müşteri desteği hakkında inleyeceğiz. Ve bu iyi sonuç verdiğinde bile - net bir yol haritası, iyi destek, düzenli güncellemeler elde edersiniz ... - artık bir rakibin üstel büyüme ile ortaya çıkma ihtimali her zaman vardır. Çoğu zaman, köklü şirketlerin her zaman baskın olacağını düşünerek hata yaparız, çünkü tam olarak egemen oldukları için. Bununla birlikte, bir sürüdeki baskın unsur yaşlandıkça, süper büyük yazılım / donanım / satıcı ne olursa olsun yaşlanır. Ya da sadece biraz tembel. Ve bir meydan okuyucu içeri girer ve yerleşik baskının 5 veya 10 yıl önce yapmış olabileceğinden daha hızlı bir şekilde geri döner. Ya da baskın sadece iyi bir dayak alacak, piyasada bir bozulma (ekonomik olarak konuşursak, farklı alanlar üzerindeki etkileriyle) görürken zar zor hayatta kalabilir ve sonra işler devam edecek. Belki bu kusurlu görünüyor, ancak kendi içinde organik bir süreç.

Yani, kullanıcı açısından, sorun o kadar büyük değil sanırım. Kod çürümesi, kullanıcının bakış açısından gerçekleşmeyecektir, çünkü bir alternatif (muhtemelen sorunsuz bir geçiş / geçişle ... umarım) kullanacaktır.

Şimdi, kullanıcının bakış açısından bir şey görmediğimizi varsayarsak veya bilinmeyen nedenlerle, hükümetsel gelişim, uzay yolculuğu vb. çok uzun süre yaşamak / hayatta kalmak için inşa edilmek için, referans verdiğiniz metinlere bakmamız gerekir. Ve muhtemelen güvenilir sistemler ve hataya dayanıklı sistem hakkında daha fazla literatür. Yine de daha ileriye gitmek istiyoruz. Sadece hataya dayanıklılık istemiyoruz, evrim sistemleri de istiyoruz.

Evrim ile ilgili sorun, değişiklikleri ve değişikliklerin başarısızlık noktalarını ortaya çıkarmasıdır. Şimdi bunlara ve bunları ele almak için neler yapabileceğimize bakalım.

Bunu yaparken hala altyapı / mimarlık / tasavvur edici metafora güvenebiliriz (sonuçta, hepimiz yazılım mühendisleri, ancak yazılım mühendisliği gibi bir şey yoktur ... şimdilik). Tüp sistemi hala aktifken (bazı aksaklıklarla), Big Ben hala çalışıyorsa (bazı aksaklıklarla) veya Eyfel Kulesi hala ayakta dururken bir neden var. Bunun nedeni, bir altyapının hayati (ya da çok hayati olmayan) unsurlarıyla, yazılımla da yapmamız gereken şeyi yapmaktır: sürekli denetim. Bu varlıklar bu kadar uzun süre dayanacak şekilde tasarlanmamış olmakla birlikte, gerektiğinde sürekli gözetimden ve zamanında iyileştirmelerden ve onarımlardan yararlanmıştır. İsterseniz düzeltmelerinizi çağırın.

Öte yandan, bazı tasarımların sürmesi ve kesintisiz denetimin mümkün olmayacağını bile bilmeden, kesintisiz olarak çalışması amaçlanmıştır. Bu durumda iyi tasarım ve biçimsel modellere yöneliyoruz. Güvenilirlik unsurları (Kullanılabilirlik, Güvenilirlik, Güvenlik, Bütünlük, Sürdürülebilirlik) belirli bir ortam için ölçülebilir. İstatistikler gerisini dinlenme ve gelecek planlamak için yapar. Hangisi şu soruyu getirir: bizim için gerçek anlamda evrimsel olacak sistemler kurmak mümkün mü?

Clean Code'daki Jeff Langer benzer bir soru soruyor ... buhar borularına referanslar olmadan :)

Ya çalıştıkça iyi tasarımlar yaratmanıza yardımcı olacak dört basit kural varsa? Bu kuralları izleyerek, kodunuzun yapısı ve tasarımı hakkında bilgi edindiyseniz SRP ve DIP gibi ilkelerin uygulanmasını kolaylaştıracak olsaydınız? Ya bu dört kural iyi tasarımların ortaya çıkmasını kolaylaştırdıysa?

Birçoğumuz, Kent Beck'in Basit Tasarım'ın dört kuralının iyi tasarlanmış bir yazılım yaratmada çok yardımcı olduğunu düşünüyoruz.

Kent'e göre (Aşırı Programlamada Açıklanmaktadır), bir tasarım şu kurallara uyuyorsa “basit” tir:

• Tüm testleri yapar
• Çoğaltma içermiyor
• Programcının amacını ifade eder
• Sınıf ve yöntem sayısını en aza indirir

Tüm testleri yapabilmek için ... testlere ihtiyacımız var ve bu teknik borcun muazzam bir göstergesidir. Örneğin, Merkür Kalite Merkezi gibi bir sistemde 10.000 test vakası varsa ve hiçbiri bu testlerin otomatiktir, yani inşa edilmiştir teknik borcun bir açık göstergesidir.

İşte bu noktada Tüyler ve “Eski Kodla Etkili Çalışma” kitabı devreye giriyor.