Binlerce hata!

Geçenlerde yeni bir projeye atandım. Aslında, eski bir proje, klasik ASP ile yazılmış. Şimdi uygulamanın yeni bir sürümü en son ASP.NET'te yazılıyor, ancak bir süre içinde RTM olması beklenmiyor (tahmini çıkış tarihi Ocak 2017'dir), bu nedenle eski uygulamaya kadar bazı bakımları yapmalıyım. atılan.
Ayrıca, tüm müşterilerin derhal yeni programa geçmeyecekleri hissine kapıldım, bu nedenle bu sürüm muhtemelen bir süre civarında olacak.

Ve sorun şu ki, hatalarla dolu. Bazı bölümleri, web standartları olmadığı zaman önceki yüzyıla kadar uzanıyor ve Quirks modunu gerçekten önemsemiyorum widthve heightCSS yerine, düzen için kullanılan tabloları, çerçeve kümelerini vb. width="20px"her yerde, onchange="javascript:..."ve kullandıkları yerlerde css kullanıyorlar style="width:20"ve style="width=20px"sıradan. Çelişki widthve styleniteliklerin olduğu birçok çizgiden bahsetmiyorum bile . Vb vb
Sonuç olarak, web uygulaması sadece IE altında ve sadece uyumluluk modunda çalışır. Geliştiricilerin asla kod geçerliliğine bakmadıkları, ancak aklındaki gibi göründüğü gibi görünen şeylerin ortaya çıkmadığı açıktır.

Ve bununla nasıl başa çıkacağımı bilmiyorum. Diğer hataların koduna bakarken gözlerimi bu hatalara kapatmak imkansız.
Elbette sorunların çoğunu ortadan kaldırmak için küresel bir bulma ve değiştirme yapabilirim, ancak bu benim ilk taahhüdümün binlerce değişik .asp dosyasından oluşması anlamına geliyor. Bunu yapabilir miyim?

Birkaç şeyi "hatalar" terimiyle karıştırıyor gibisiniz.

• eski html özellikleri
• kodlama stili
• hataya neden olmayan kodlama hataları
• bildirilmemiş hatalar
• şimdi özellik olan hatalar
• rapor edilen hatalar
• düzeltmek için atandığın bildirilen hataları bildir

Değiştirilecek olan eski bir uygulamada bu hata türlerinden yalnızca bir tanesi sizi ilgilendirmelidir. Sonuncu.

Söyleyebildiğim kadarıyla, giderilmesi gereken bir özellik üzerinde başka şeylere zarar vermemeniz gerektiğini söylerdim.

• şimdi özellik olan hatalar

Koddan nasıl çalışması gerektiğini, ama hiç yapmadığını, ancak tüm kullanıcıların, son 10 yıldır belirsiz bir şekilde genişletilmiş unsurla birlikte olduklarını görüyorsunuz ve düzeltdiğiniz için teşekkür etmiyorlar.

Artı tarafta, alaycı JFDI kafanızı takarsanız, böcekler çok hızlı bir şekilde yanabilir ve yeni versiyon ekibi eski versiyonların özelliklerine ayak uyduramayacak.

Bu, müşterilere bir krom eklentisi ie6 öykünücüsü önerdiğiniz için size ironik bir kaçıklık dolu bir gülüş gülümsemesi verecek, böylece sevdikleri kayan yazı 'özelliğini' kullanmaya devam edebilecekler.

İstediğiniz teknik bir soru değil ve burada kimse cevap veremez.

Bakım modunda bir yazılım parçası üzerinde çalışıyorsunuz ve modası geçmiş bir teknoloji ve çok sayıda kusur ve tutarsızlık gözlemliyorsunuz. Ne yapacağını sor. Örneğin, tarayıcıyla uyumlu hale getirilmesi için çaba sarfedilmeli mi? Modern standartlara uygun hale getirmeli misiniz? Uygulamadaki sözdizimsel tutarsızlıkları gidermeli misiniz? Mesele şu ki, bunlar iş kararları . Yöneticinize veya ürün sahibinize, hangi sorunları çözmenizi istediklerini ve önceliklerinin ne olduğunu sormalısınız. Uygulamayı yeniden yazmak için halihazırda devam eden bir proje olduğundan, yönetim muhtemelen gözlemlediğiniz sorunların farkındadır.

Uygulama birkaç ay içinde tamamen değiştirilirse, yalnızca belirli kritik sorunları çözmenizi ve karışıklığı geri kalanını yalnız bırakmanızı istemeleri muhtemeldir . Ama biz bilmiyoruz.

Binlerce dosyayı değiştirerek, kod tabanı genelinde kapsamlı arama ve değiştirme işlemini yapıp yapamayacağınızı sorarsınız. Tabi ki yapabilirsin. Sorun şu ki yapmalısın . Bu tür kapsamlı değişiklikler, hiçbir şeyin kırılmadığından emin olmak için kapsamlı testler gerektirecektir. Yine, fayda zaman ve risk maliyetinden daha ağır basarsa, bu bir iş kararıdır.

Başvurunun 18 ila 24 hafta içinde değiştirilmesi durumunda (yukarıda belirtilen 6 ila 8 haftaya beklenen gecikmelere eklenmesi beklenir), o zaman gerçekten önemli miktarda iş yatırımı yaparak işletmeye hangi katma değeri kattığınızı kendinize sormanız gerekir. Eski versiyon

Elbette, birkaç yıl boyunca başvuruyu desteklemenizin zorlanacağı durumlarda, teknik borçtan kurtulmanız uzun vadede faydalı olabilir. Ama her şey yine de atılacaksa, neden rahatsız ediyorsun? Sadece yeni sürümün yayınlanmasına kadar bekleyemeyeceğiniz ve bir gün arayacağınız sorunu çözmek için diğer tüm sahte düzeltmelerin üstüne başka bir sabitleme düzeltmesi ekleyin.

Ne Ayrıca kendinize sorun olabilir hala bu kadar az yaşamda uygulama için yapmak. Gerçekten şu anda sıkılmış ve sadece zaman yapacak daha iyi bir şey yok edildiğinde size verebilir bunu büyük bir revizyon vermek ve belirtilen her stil sorunları kaldırmak, ama çok muhtemeldir o çözecektir daha ilk kırılmada bu irade daha işler o . Sonunda yeterli zaman verilen bu yeni sorunlardan kurtulabilirsiniz, ancak o zamana sahip değilsiniz.

Büyük değişiklikler yapmamanın nedenleri:

Bir: Kod birkaç ay içinde kayboluyor. 1 ay sonra atılacak bir sistemi tamir etmek için 5 ay harcamanız gerçekten şirketin zamanına değer mi? Uyarma: Sistemler, zamanlamaları ortadan kalktıklarında nadiren kaybolurlar. Değiştirme sistemi neredeyse her zaman geç kalır, ne sebeple olursa olsun yükseltme yapamayan kullanıcılar vardır, vb. Ancak bu karmaşık bir konudur.

İkincisi: Çok fazla değişiklik yaparsanız, özellikle de toplu arama ve değiştirmeler yaparsanız, hatalar ortaya çıkar. Hata tanıtamazsın: yapacaksın. Bir S&R yaptığını ve "width = 200" 'i "width: 200px" olarak değiştirdiğini varsayalım. ASP sayfalarınızda C # veya VB kodu var mı? Çünkü 200 olarak belirlediğiniz "width" adlı bir değişkeniniz varsa, onu kırdınız. (Veya bu konuda S&R'yi ASP sayfalarıyla sınırlamayı düşündünüz mü?) Veya "genişlik: 200" ü "genişlik: 200px" olarak değiştirdiyseniz, kodda "genişlik: 200mm" yazan bir yer varsa ne olur? "? Şimdi "genişlik: 200pxmm" yazıyor. Tamam, düşünelim dedik ki. Ya elbette yoksayılan geçersiz genişlik spesifikasyonuna sahip bir yer varsa ve şimdi oldukça iyi bir şekilde ortaya çıkıyor. Sen "düzelt" genişlik ve şimdi 200px ile uzanıyor ... ve ekran berbatlaştı, çünkü 200px gerçekte yanlış genişlik veriyor ve sadece bu değer yoksayıldığından işe yaradı? Kütle S & R'ler çok tehlikelidir, çünkü neredeyse kesinlikle değiştirdiğiniz her yerde çalışmıyorsunuz. Muhtemelen ne test edeceğinden bile emin değilsin.

Üç: "Açıkçası" yanlış olan kod aslında kullanıcının istediği şey olabilir. Açıkça yanlış ve çılgınca davranış gerektiren bir davranış şartı görmüştüm ... ve sonra kullanıcılara geri dönüp GERÇEKTEN istediklerini soruyorum ve bu gerçekten çılgınca davranışları istediklerini ortaya koyuyor, çünkü bu işlerinin nasıl yürüdüğünü veya hükümet düzenlemelerinin neye ya da neye ihtiyaç duyduğunu gösterir.

Davranış gerçekten yanlış olsa bile, belki de kullanıcılar onu beklemeye geldiler ve rutin olarak işlerine devam ediyorlar ve onu düzelterek geçici çözümlerini bozacaksınız. Örnek: Bir satışın halka açık olduğunu belirlediğiniz tarihler arasında belirlediğiniz bir yerin olduğu bir sistem üzerinde çalışıyorum. Her iki tarih de o güne başlayan gece yarısıydı, yani "30 Temmuz'a kadar" derseniz, bunun 29 Temmuz günü bitmesiyle, yani 30 Temmuz günü 12: 01'den 30 dakika önce bitmesi anlamına geliyorsa Bir noktada bunu düzelttim, ancak bunu yapabildim, çünkü bu ekranı kullanma yetkisi olan yarım düzine insan vardı ve ben de onlara tamir ettiğimin hepsini söyleyebilirdim. Eğer yüzlerce kullanıcı olsaydı ve hepsi şimdiye dek gerçekten son günden sonra bir gün vermek zorunda kaldığınızı anladılar.

Elbette sorunların çoğunu ortadan kaldırmak için küresel bir bulma ve değiştirme yapabilirim, ancak bu benim ilk taahhüdümün binlerce değişik .asp dosyasından oluşması anlamına geliyor. Bunu yapabilir miyim?

Ben neden görmüyorum. Bir olmalıdır taahhüt kavramsal bir şey, ama ben bir küresel bulma ve değiştirme için bir neden görmüyorum style="width=20"için style="width: 20px""tek şey" olarak, kavramsal konuşma saymak olmaz. Ve daha iyi uyumana yardım ederse, başka şeyleri düzeltirken dikkatinizi dağıtmaktan kurtarın ve hiçbir şeyi mahvetmemek için neden olmasın?

Sorununuz öncelikleri belirlemek : Göstergelerdeki sorunlardan hangileri (üretimde)? Hangileri bomba atıyor? Ve bir süre sonra hangisi daha uzun süre kalabilir?

Sizin durumunuzda yapacağım şey, bakmak istediğim sorun sınıflarının listesini yapmaktı . Örneğin, yerine style="width=(\d+)"ile style="width: \1px"(muhtemelen küresel Bul ile düzeltilmesi olabilir ki / regexp'in kullanarak yerine - mine% 100 değilse üzgün) bir sınıf olacaktır ve sadece bir olay varsa, öyle olsun. Her kategori listesi için bir öncelik (bunu yapmak ne kadar acil) ve bir iş tahmini (bu kategoriyi yapmak ne kadar sürer).

Bakım görevleriniz de bu listede olacaktır. Artık sadece kendinize bile olsa bazı yönetim uygulamaları yapmaya başlıyorsunuz ve elinizde vaktiniz varsa ve yapacak bir şey yokken veya iş yapmak için yöneticinizle görüşmeniz gerektiğinde (veya istekte bulunduğunuzda) kullanmak için bir aracınız var. farkında olamayacağı bir şeye tahsis edilme zamanı). (Bu proaktivite, doğru yapıldığında promosyonlardan haberdar olmanıza yardımcı olabilir.)

Sanırım programlamadan hoşlanıyorsunuz, çünkü bir dereceye kadar mükemmel bir mükemmellik kişiliğiniz var. AMA ticari bir ortamda, mükemmelin iyinin düşmanı olduğunu fark etmeye başlamanız gerekir (ve paraya iyi gelir, mükemmel, çok daha fazla iş için farkedilir ölçüde daha fazla getirmeyebilir). İlk önce gerekenleri yapın, sonra sahip olabileceğiniz şeyleri yapın. Evet, bu tahılın bitmesine karşı gelebilir. Sadece sırıtın ve ona katlanın ve belki de mükemmeliyetçiliğinizi geliştirmek ve aklı başında tutmak için bir hobi edin ;-)