“Eski” kodu ne zaman? [kapalı]


63

Hepimiz yaptık, bazı kodları (genellikle miras aldığımız şeyleri) "miras" olarak etiketledik. Ama yine de üretim sistemlerinde kullanılıyor - yani gerçekten mirası var? Ve onu eski yapan nedir? Mükemmel işleyen kodun bu sınırsız etiketlemesinden uzak durmalı mıyız; etiketleme, yeni maddeleri ilerletmemize ve üst yönetimi güzel ve mutlu tutmamıza izin veren saf bir rahatlıktır?


Cevapların özeti

Cevapları inceleyerek dört genel tema görüyorum. Dağılımı gördüğüm gibi:

  1. Teslim edilen herhangi bir kod: 6
  2. Ölü sistemler: 2.5
  3. Birim testi yok: 2
  4. Geliştiriciler buralarda değil: 1.5


1
Teslim edilir ve çalışmaya başlar başlamaz eski koddur.
Martin Beckett

23
eğer yazmadıysanız eski koddur ;-)
Steven A. Lowe

20
Yazan herkes emekli ya da ölmüşse ve onu sürdürmeye devam edenler ise keşke isterlerse bu eski koddur. Aksi takdirde, sadece mevcut kod tabanı denir.
unpythonic

3
@ StevenA.Lowe, yeterli zaman verilmiş, ben bile eski kodu var did yaz.
Kyralessa

Yanıtlar:


43

Wikipedia'nın özeti için kısmi olarak kendim:

Eski bir sistem, daha yeni bir teknoloji veya daha verimli bir görev yerine getirme yöntemleri mevcut olmasına rağmen, genellikle hala kullanıcıların ihtiyaçları için çalıştığı için eski bir yöntem, teknoloji, bilgisayar sistemi veya kullanılmaya devam eden uygulama programıdır.

Diğer insanların cevaplarında anlattıklarının çoğu, kodun “eski” olma nedenleridir . Ancak asıl sorunun kendisi şudur:

Ama yine de üretim sistemlerinde kullanılıyor - yani gerçekten mirası var? Ve onu eski yapan nedir?

Üretimde hala kullanılıyor olması tam olarak onu miras yapan şeydir . Kod düzgün çalışmıyorsa veya üretimde artık kullanılmıyorsa, bu kod sırasıyla "kırık" veya "emekli" olur. Miras , hala kullanımda olduğu ve iyi çalıştığı, ancak artık ortak kullanımda olmayan tasarımları veya teknikleri içerdiği anlamına gelir.

(A) yükseltmek / güncellemek istediğiniz ancak yapamayacağınız veya (b) yükseltmenin tam ortasında olan herhangi bir kod veya sistem eski bir sistemdir. Bu, yeniden düzenleme veya genel kod temizleme anlamına gelmez , muhtemelen yeni bir çerçeve veya hatta yeni bir platform kullanarak tasarımda önemli değişiklikler anlamına gelir .

Sistemlerin veya kodların miras kalmasına neden olabilecek çok sayıda neden vardır :

  • Düzenli bakım veya yazılım çürüklüğü eksikliği . Açıkça, uygulama düzenli olarak yapılmazsa, yazılım dünyasında büyük değişikliklere ayak uyduramaz. Bu, basit bir ihmalden kaynaklanıyor olabilir veya işletme öncelikleri veya bütçe kısıtlamalarına dayanan kasıtlı bir tercih olabilir.

  • Test eksikliği. Başka bir cevap , popüler bir yazarın, eski kod olan testlerle kapsanmayan herhangi bir kodun hiperbolik iddiasına atıfta bulunur. Bu gerçekten doğru bir tanım değil ama olan bir olası temel nedeni; iyi testler olmadan (otomatik veya manuel), geliştiriciler çekingen davranır ve büyük değişiklikler yapmaktan korkarlar çünkü bir şeyleri kırmaktan endişe ederler, böylece yukarıdaki "yazılım çürümesine" öncülük ederler.

  • Büyük açık kaynak kodlu kütüphaneler veya çerçeveler kullanan projelerde özellikle sinsi olan, genellikle göz ardı edilen bir faktör olan Rev-lock (ticari araçlarda da görmeme rağmen). Genellikle, çerçeve / kütüphane üzerinde yapılan önemli uyarlamalar yapılacaktır ve bu da yükseltme işleminin zorlaştırılmasının zor ya da pahalıdır. Böylece sistem eski hale gelir, çünkü daha eski (ve muhtemelen artık desteklenmeyen) bir platformda çalışır.

  • Kaynak kodu artık mevcut değil, yani sistemin yalnızca hiçbir zaman eklenemeyeceği, asla değiştirilemediği anlamına gelir. Bu sistemler yükseltmek için yeniden yazılmaları gerektiğinden - artan / yinelemeyle revize edilenlerin aksine - pek çok şirket rahatsız etmeyecektir.

Bir kod tabanındaki güncellemeleri yavaşlatan veya durduran herhangi bir şey, bu kod tabanının eski kalmasına neden olabilir.

Şimdi ayrı, gösterilmeyen ancak ima edilen soru şudur: eski kodda yanlış olan ne? Genellikle aşağılayıcı bir terim olarak kullanılır, bu nedenle soru şu:

Mükemmel işleyen kodun bu sınırsız etiketlemesinden uzak durmalı mıyız?

Ve cevap hayır, yapmamalıyız; etiketleme olduğunu garanti ve dönem kendisi açıkça işleyen kodu ima eder. Nokta değil yani bu fonksiyon, ama nasıl o işlevi olduğuna.

Bazı durumlarda, eski kodlarda yanlış bir şey yoktur. Kötü bir kelime değil. Eski kod / sistemler kötü değildir. Sadece biraz toz topladılar - bazen biraz, bazen çok.

Eski haline eskimiş sistem artık müşterinin ihtiyaçlarına (tüm) hizmet edebilir zaman. Bu etiket, dikkat etmemiz gereken bir etiket. Aksi takdirde, sadece bir maliyet / fayda denklemidir; Yükseltme maliyeti, faydalarının maliyetinden düşük (gelecekteki bakım maliyetleri de dahil olmak üzere) düşük ise, yükseltin, aksi takdirde, yalnız bırakın. "Eski" kelimesini normalde "vergi denetimi" için ayırdığınız tonda belirtmenize gerek yok. Olması çok iyi bir durum.


Bununla birlikte, vergi denetiminin de olması için mükemmel bir durum olması gerektiği belirtildi.
Florian Margaine

Şunu söyleyebilirim: Mevcut Teknoloji Yığını ile artık ölçeklendirilemeyen sistem.
Ramiz Uddin

40

Genellikle, bir dilde yazılmış veya genellikle yeni bir geliştirme yapmadığınız bir sisteme dayanıyor demektir.

Örneğin, çoğu yer Cobol'da yeni programlar yazmaz. Ancak, işlerinin büyük bir kısmı Cobol'da yazılmış uygulamalarda çalışabilir. Bu nedenle, bu uygulamalar "Eski" olarak etiketlenmiştir.


Bu cevaba en çok katılıyorum. Miras, desteklemek istemediğiniz can sıkıcı (henüz modern) bir kod olmaktan çok eski bir platformda sıkışıp kalmakla ilgilidir. Eski kod genellikle oldukça iyidir (aksi halde kimse onu geride bıraktığında umursamaz!) Ama genellikle eski donanımlara ve eski dillere / kütüphanelere / veritabanlarına / vb. Eklenir.
Satanicpuppy

3
@Satanicpuppy: Basitçe hemfikir değilim - Kesinlikle (herhangi bir donanım, kütüphane veya veritabanına bağlı olmayan bir Java'yla (bir örnek için) uğraştım - fakat aldığı kadar "eski" Java ile yeniden yazıldığından, dil de sorun değildi. Ayrıca bazı kod ile uğraştığım edildi belirli donanıma bağlı, ama yine de sadece edilmiş zar zor "eski" kategorisine içine kenar.
Jerry Coffin,

4
@jerry: Peki ne eski mi yaptı? Legacy, "bad" kelimesinin eş anlamlısı değildir.
Satanicpuppy

1
Düşündüğüm durumda, oldukça büyük bir dağınık sistemdi (BEA Tuxedo etrafında inşa edildi). Tasarım , senkronizasyonun gerekli olduğu süreyi / yerleri maksimize ederek senkronizasyon hakkında bilgi vermek için tasarlanan ders kitabı senaryolarına dayanıyor gibiydi . Bu (bir nevi) bir ders kitabı için anlamlıdır, ancak gerçek tasarımlar için korkunçtur . Bir yeniliğin mimarisinin bile çok yıllı bir proje olması yeterince büyüktü. Değiştirme işlemi, işin tamamen yapılması gerektiğinden, zaman aşımına uğramayan aşamalarda yapılmak zorundaydı .
Jerry Coffin

1
@Cawas: Bana göre @ Chad'in cevabı, yeni sistem farklı bir dilde veya farklı bir donanım vb. Kullanılarak yapılırsa / uygulanırsa uygulanır. Bu, hala Java kullanarak, hala Smokin kullanarak, vb. Başvuru olarak görmüyorum.
Jerry Coffin,

28

Legacy, çalışmak yerine değiştirmek istediğiniz herhangi bir kod anlamına gelir . Programcıların çoğunun mevcut koda karşı tutumu göz önüne alındığında, bu, şu anda aktif olarak yazdıklarınız dışında (ve dondurulmuş bir tasarıma kod yazmanız gereken büyük bir projede, hatta yazdıklarınızda bile) an da dahil edilebilir).

  1. "Oldukça" vurgusu, bu eski kodu iletmeyi amaçlar, ayrıca istemeseniz bile onunla çalışmanızın zorlaştığı anlamına gelir. Vurgulamanın yine de yeterli olduğundan emin değilim. Bunun nedenleri değişebilir. Bazıları gerçekten değiştiremeyecek kadar büyük ve karmaşık. Diğerleri, diğer sistemlere arayüzdür. Yine de diğerleri politika ve kişilikleri tarafından yönlendiriliyor (örneğin, kod korkunç, ama kabin bebek şaşırtıcıydı).
  2. Ben yeterince vurguladı olmayabilir başka nokta kodu kalitesi ederken olmasıdır edebilir ve çoğu zaman hatta özellikle önemli bir - bir faktör olabilir (hiç değilse), nadiren tek faktördür.
  3. Tek belirleyici faktör olarak ünite testlerini yapan insanların , eşinin bir blok ötede bıraktığı küpeye karşı sokak lambası altında görünen adam gibi olduklarını düşünüyorum . Işık daha iyi olabilir, ama yine de yanlış yere bakıyorsun. Kool-Aid'i içmeden önce düşünün .
  4. (Sonuç olarak 3.) Bana göre bazı insanlar olayların gerçekte oldukları gibi olmalarını nasıl diledikleri hakkında konuşuyorlar. Eğer John Conways ' Hayat Oyunu bir için Apple IIc Plus'ın mirası değil o yere kadar yeniden uygulanması kolay olduğunu yeterince küçük ve basit, çünkü bu kadar. Şimdiye kadar yazılmış en mükemmel birim testi, tek bir iota'nın değişmesine neden olmaz .

Son nokta, genellikle doğru olduğunu düşündüğüm diğer iki noktaya yol açıyor.

İlk olarak, kod gerçekten olması gerekmese bile, genellikle eski olarak korunur. Daha yüksek seviyedeki yöneticiler, genellikle bir sistemin yeniden uygulanmasının, başlangıçtaki uygulamanın maliyetinden daha fazla veya daha pahalı olacağını, bunun da nadiren doğru olacağını varsaymaktadır.

İkincisi, birim testleri iki ucu keskin bir kılıçtır. Uygulamadaki yerel değişikliklerin gerçekten önemli olduğunu düşünmeyi çok kolaylaştırıyorlar. Daha büyük bir sistemde önemli iyileştirmeler yapmak için, sık sık (genellikle?), Birim testlerin çoğunun (çoğu değilse) alakasız hale geldiği genel tasarımın yeterince değişmesi gerekir. Ne yazık ki, birim testlerin varlığı ve yaptıkları tutum gerçekten gerekli olan değişiklikleri görmezden gelmeyi çok kolaylaştırabilir.

Belki de bunun bir örneği yardımcı olacaktır: Bir programın harika ünite testine sahip bir UI kütüphanesi ve bu kütüphaneyi kullanan birkaç program olduğunu varsayalım . Üst yönetimdeki birileri "web etkin" in önemli olduğuna ikna olur (ve sadece tartışma uğruna, bu durumda aslında bu konuda haklı olduğunu varsayalım). Dikkatli bir gözden geçirme sonrasında, orta düzey yöneticiler, mevcut birim testlerinin, tüm orijinal giriş validasyonunu korurken, yerel işletim sisteminin pencereleme kabiliyeti ile görüntülenen bir kullanıcı arayüzünden, HTML / CSS / AJAX aracılığıyla uzaktan gösterilmesine geçmek için yeterli olduğunu tespit etti.

Bu harika değil mi? Birim testinin ne kadar faydalı olabileceğini gösterir. Tüm UI'nin tüm uygulamasını değiştirdik, ancak görünümün, hissin ve işlevselliğin neredeyse tutarlı kalmasını sağladık ve veri bütünlüğünü sağlamak için tüm kullanıcı girişlerinin doğrulandığından emin olduk. Birim testi günü kurtardı!

Ya da değil! Bu harika, son derece esnek, dikkatlice test edilmiş UI kütüphanesi, bu program için kullanıcıları ile pazarındaki web tabanlı bir UI'nin tamamen üzerinde çalışılacak yanlış bir şey olduğu gerçeğini körleştirmiştir. Gerçekte ihtiyaç duyulan şey , RESTful arayüze sahip bir web servisidir ve kendine ait hiçbir kullanıcı arayüzü yoktur .

Şimdi, ünite testlerinin insanların kendi pazarlarını anlama veya gerçekten gerekli olduğunu anlama yeteneklerini ortadan kaldırmadığı kesinlikle doğrudur. Aynı zamanda, çekiçler ve çivilerle ilgili eski çizgi neredeyse akla sıçramaktadır. Eğer sadece zaman daha da kötü olabilir var çekiç, ancak sahip çok bu çekiç ile tecrübe ve birçok farklı durumlarda inanılmaz derecede iyi çalışır gerçekten kaliteli bir çekiç olduğunu biliyorum. Bu kadar çok durumda pek çok konuda iyi olması gerçeği, eldeki iş için tamamen yanlış bir araç olduğunun farkına varmayı bile zorlaştırıyor.


3
Bakın, şimdi bunu işaretleyip işaretlemeyeceğimi bilmiyorum, ne yazık ki bu doğru, ama merak etmemiz gereken bir tutum mu ...
Nim

+1. Aynı derecede bir şeyi cevaplamak üzereydim. Eski, aktif olarak sürdürülmek yerine kullanılan herhangi bir koddur.
Denis de Bernardy,

@Nim: Bunun "biz" in kaçması gereken bir tutum olduğunu sanmıyorum. Bu bariz bir ifadedir. :-) Bir an için düşünün ve yeni bir ortama varırsanız eski kod olarak ne düşüneceğinizi düşünün; Aktif olarak geliştirilen yeni ve havalı şeyler dışında her şey olacak.
Denis de Bernardy

@ Jerry, o zaman birim testlerini beğenmedin mi? ;)
Nim

1
@Nim: Öyle değil - yararlı olduklarını düşünüyorum, ancak sık sık resmedildikleri her derde deva kadar kısa.
Jerry Coffin

17

Eski kod genellikle bir şekilde yetim kalmıştır. Lider geliştirici, onu anlayan tek kişi bir otobüse çarptı ve notları, artık ölü bir dil olan Ukrayna dili lehçesinde yazılmıştı. Veya, dönüşümlü olarak, Visual Basic 6.0 ile yazılmış herhangi bir şey .

Her zaman eski kod üzerinde çalışıyorum. Özellikleri şöyle derdim:

  • Büyük çaba göstermeden uzatılamaz
  • Kolayca yeni donanıma geçirilemez
  • Kolayca değiştirilemeyecek kadar kritiktir

Bu özelliklere sahip değilse, o zaman muhtemelen eski değil. Selefinizin Perl yazılarını beğenmiyorsanız, sempati duyuyorum ama bunun eski olduğunu düşünmüyorum. Geçenlerde, eski bir Sybase veritabanına gömülmüş 15 yaşındaki bazı Perl senaryolarını modernize ettim . Bu kek, tanrı-korkunç COBOL muhasebe sistemimizde en ufak bir değişikliği bile yapmıştı .


Korkunç, lider geliştiricimiz de Ukraynalı ... haha ​​... Cevabınızın orta kısmına katılıyorum, ilk nokta - çok fazla değil - Sanırım bu, dev ekibinizin nasıl kurulduğuna bağlı.
Nim

1
lol, muhtemelen bir paragrafta (otobüs şoförleri, Ukrayna dili ve VB6 aygıtları) rahatsız etmeyi başardınız. Ama kahretsin, güldüm :)
Darknight

1999'dan beri zaman yolcuyum, yani Visual Basic 6'nın 2011'den itibaren mirası kaldığını söylüyorsunuz ?
saat

@hjk Ben sallantılı bir zeminde olacağını, 2005 yılında C # / asp.net gelişiyle sonra hemen hemen bir şey söylemek, ama kesinlikle Microsoft desteği sonuna kez 2008'de etrafında haddelenmiş ediyorum
Satanicpuppy

12

Eski Kodla Etkili Çalışma adlı kitabında, Michael Feathers, eski kodu birim testleriyle kaplanmayan bir kod olarak tanımlar. Kabul ettiğim tek tanım bu. Ayrıca eski kodu eski ama yine de kullanışlı görüyorum.


24
Bu beni, “benim seçtiğim metodolojiyi izlemeyen herhangi bir şeyi” “miras” olarak tanımlamaya teşebbüs ettiğimde ortaya çıkıyor. Bu, ucuz bir tartışma taktiğinden başka bir şey değil, temel olarak sadece Godwin kanununu almak ve okurları takip etmeyen herkese desteklenmeyen (ve genellikle desteklenmeyen) bir saldırının ötesinde bir şey olmadığını anında fark etmesini engellemek için yeterli bir dili (zar zor) tercihleri.
Jerry Coffin

4
@ Jerry: Feather'ın tanımına katılıyorum. Unit Tests olmadan Kod çalışmak için bir korku. Bazı kısımlarını yeniden düzenlemek istediğinize karar verirseniz, bu yüzden mantıklı olmanız kolaylaşır, unut gitsin! Her halükarda hataları ve kodu muhtemelen test edilemez olduğu şekilde tanıtıyor olabilirsiniz! Feather'ın tanımını alışılmadık buluyorum, ancak o eski yasalarla çalışarak geçimini sağlayan biri.
yutulan elysium,

10
@ gelişmiş: birim testleri, kodla çalışabilme becerisi için kesin bir turnusol testi değildir. Birim testleri olmayan, ancak bir esinti olan ve birim testleri olan ve hala bir kabus olan kodla uğraştım. Sonuçta, birim testleri kendi içinde hiçbir şeyi çözmez. Birim için birimlere bölünmenin (örneğin) yetersiz yapıldığı bir tasarım için birim testleri hala tamamen değersizdir ve yararlı bir şey üretmek için tüm tasarımın (testler dahil) atılması gerekir.
Jerry Coffin,

6
Jerry'nin yorumlarına katılıyorum. Birim testlerinin yokluğu, kötülüğü gösterebilecek (veya etmeyecek ) bir sürü kod kokusundan yalnızca biridir .
smci

4
Yine Feather'ın tanımının yanı sıra yutulduğu gibi aynı fikirdeyim. Birim testinin yokluğu her şeydir, çünkü bu en güzel kod pasajının bile eksik olduğunu gösterir. Birim testleri, belgelerin% 51'i ve kodun belirtiminin% 100'üdür. Belgelerinin çoğunu eksik olan bir kod ve tüm belirtimleri haklı olarak miras olarak sınıflandırılmalıdır.

8

Teknik olarak, miras, hazır herhangi bir koddur. Yani üretimde olur olmaz, miras. Çünkü orada zaten bir değer var, onu dışarı atamazsınız ... Bununla başa çıkmak zorundasınız.

"Vaktinden önce" ama "hala başın ağrıyor" .


5

Eski kod, yalnızca kod tabanında kalan koddur, çünkü aksi halde bir çok şey çalışmayı bırakacaktır. Başka bir deyişle: olmanın tek nedeni geriye dönük uyumluluktur.

Değiştirmeyi veya atmayı bile tercih edersiniz, ama yapamazsınız çünkü ona bağlı olan tüm kodları kıracaksınız (buna göre uyarlayamayacağınız kod olabilir). Bu nedenle, onu saklamanız (ve hatta bazen tutmanız) gerekir, ancak tüm yeni kodların buna karşı yazılmasını istemezsiniz.

Bir örnek, bir kütüphanenin API'sinin kullanımdan kaldırılmış yöntemleridir. Hala oradalar, böylece kütüphaneyi her kim güncellerse yine de projesini inşa edebilir, ancak onaylanmamış olarak işaretlendi ve derleyici size bir uyarı vermelidir.

Başka bir örnek, Microsoft'un işletim sistemlerinin sürümleri için yazılmış programları tamamen kullanımdan kaldırmaları için çalıştırılmasını sağlamak için yaptığı tuhaf hilelerdir. Bunun varlığının zirvesi:

Bunu ilk olarak, uygulamasında kritik bir hata olduğunu söyleyen SimCity hit oyununun geliştiricilerinden birinden duydum: boşalttıktan hemen sonra bellek kullandı, büyük bir hayır-hayır, DOS’da işe yaradı. serbest çalışan belleğin derhal başka bir çalışan uygulama tarafından kapatılabileceği Windows altında çalışmaz. Windows ekibindeki test uzmanları çeşitli popüler uygulamalardan geçiyorlardı, iyi çalıştıklarından emin olmak için test ediyorlardı, ancak SimCity çökmeye devam etti. Bunu, SimCity'yi demonte eden, hata ayıklayıcıda adım attığını, hatayı bulduğunu ve SimCity'nin çalışıp çalışmadığını kontrol eden özel bir kod eklediğini ve eğer öyleyse, bellek ayırıcısını içinde bulunduğunuz özel bir modda çalıştırdığını belirten özel kod eklediklerini bildirdiler. serbest bıraktıktan sonra hala belleği kullanabilir.
- Yazılım Joel


4

Miras kalıtım gerektirir. Eski kod basitçe geçmişten devraldığınız koddur. Daha önce kendiniz yazsanız bile eski kod!

Diğer tüm düşünceler, temelde, mevcut projeniz için özellikle yazmamış olmanızdan kaynaklanmaktadır. Bu mutlaka kendi başına kötü bir şey değil.


Geçmiş 1 gün, 1 saat veya 1 yıl olabilir. Bu onu miras yapmaz.
Vince Panuccio

2

Benim fikrim, eski kod olarak kabul edilen şeyin birçok şeye bağlı olduğu ve 'eski' etiketinin muhtemelen kuruluşa özgü olduğu yönünde.

Eğer çalıştığı donanım / işletim sistemi eskiyse ve satıcı tarafından durdurulmuş - grev 1.

Herhangi bir nedenden ötürü düzeltmeye çalışmak, yeniden yazmaktan daha fazla iş varsa, çünkü

  • orijinal geliştirici / kullanıcılar gitti
  • program kötü yazılmış
  • daha yeni bir platformda daha iyi yapılabilir ve yine de şirkete değer.

böyle yaparak

  • orijinal kaynak artık mevcut değil ve / veya eksik parçalar var

2. atış.

Birden fazla örgütün birle birleştirilmesi - Grev 3 - bir taraf muhtemelen miras olarak etiketlenecek.

Üçüncü taraf bir uygulama ve / veya servis - grev 4 olarak satılan daha iyi, daha ucuz bir alternatif var mı?

Örgüt, günlük faaliyetler söz konusu olduğunda, yeni teknoloji konusunda tutarlılığa değer verilen bir hastane veya okul bölgesi gibi bir şey mi? Bir uygulamanın, ticari / rekabetçi bir kuruluştaki aynı uygulamaya kıyasla eski olarak kabul edilmesi daha uzun sürer.

Şirket, müşterilerin ihtiyaç duyduğu şeyi yapmak için uygulamayı geliştirmeye / desteklemeye devam eden küçük bir geliştirme şirketi ise, eski kod veya sadece 'eski' kod olarak kabul edilir. Mc2Ok adında bir şirket biliyorum - yazılımı Windows 3.1 gibi görünen yazılım üzerine geliştirdiler ve daha ileri taşımaya devam ettiler. Hala çok bir Windows 3.1 görünüm ve his var, ancak buna bir web arayüzü de eklediler. Bu iki kişilik bir geliştirici firma (tahminimce) ve üzerinde çalışmayı bıraktıklarında derhal kabul edileceğini ve kullandıktan sonra bir veya iki yıl sonra göç etme zamanlarının geleceğini söyleyeceğim. Fakat bu 10 yıl veya daha uzun olabilir.

Bazen yönetim değiştiğinde, birçok damlama etkisine sahip dalgalar halinde değişebilir ... Yeni yönetimin gizliliğine bağlı olarak, pek çok uygulamanın aksi takdirde iyi olabilecek mirasını ortaya çıkarabilir.

Her kuruluşun, 'eski kodun' onlar için ne anlama geldiğini tanımlaması gerektiğine inanıyorum. Ben bakmak için kullanılan Sunday Times kuruluşlar aradığını görmek için her hafta ilanlar. Artık benim ilgimi çekmeyen şeyler için barometremdi (eski). Eh, The Sunday Times artık önemli değil :-) Ve COBOL'un miraslı olduğunu, ASP Classic'in miraslı olduğunu vb.


+1, güzel cevap - ordunun perspektifinden bir şey miras düşünmek daha iyi ...
Nim

0

Kod, biri değişmekten korktuğu zaman eskidir, çünkü onu kırabilir. Bu koddaki değişikliklerle tüm sistem ne zaman açılabiliyorsa daha da acı verir.

Bu yüzden Michael Feathers'ın tanımına katılıyorum. İyi birim testlerine sahip olan kod korkusuzca değiştirilebilir.

Ayrıca, eski kodun kaç yaşında olduğu ile ilgisi olmadığını düşünüyorum. Kişi en baştan eski bir kod yazabilir.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.