Kötü kod istemciye göstermek?

Bir müşteri benden başka bir danışman tarafından geliştirilen bir ASP.NET Webforms uygulaması olan web sitesini yeniden tasarlamamı istedi. Göreceli olarak basit bir iş gibi görünüyordu, ancak koda baktıktan sonra durum böyle olmadığı açık.

Bu uygulama iyi yazılmış değildi. Hiç. SQL enjeksiyon saldırılarına karşı son derece hassastır, iş mantığı tüm uygulama boyunca yayılır, çok fazla çoğaltma vardır ve hiçbir şey yapmazsa çıkmaz kod vardır. Bunun üzerine, boğulmakta olan istisnalar atmaya devam ediyor, bu yüzden site sorunsuz çalışıyor gibi görünüyor.

Benim işim HTML ve CSS'yi basitçe güncellemektir, ancak HTML'nin çoğu iş mantığında üretiliyor ve çözülmesi kabus gibi. Yeniden tasarlamaya ilişkin tahminim, müşterinin hedeflediğinden daha uzun. Neden bu kadar uzun süredir soruyorlar.

Müşterime bu kodun ne kadar kötü olduğunu nasıl açıklayabilirim? Akılda, uygulama harika çalışıyor ve yeniden tasarımı hızlı bir kereye mahsus olmalıdır. Bu önceki danışmana karşı benim sözüm. Teknik olmayan bir müşterinin anlayacağı basit, somut örneklerimi nasıl verebilirim?

Güncelle

Tüm cevaplar için teşekkürler. SQL enjeksiyon saldırısı gösterimi anlamlıdır ve bunu test ortamında demonte edeceğim. Bu, bu uygulamada birçok sorunun sadece bir parçasıdır. Diğer parçaların nedenini açıklamanın yollarını arıyordum (örneğin, html gibi veri katmanında oluşturuluyor) html ve CSS güncellemelerinin gerçekleşmesi için daha iyi uygulamalarla değiştirilmesi gerekecekti. Müvekkilimle konuştuğumda birlikte yazacağım birçok iyi öneri var.

128
SQL ve hiç kimse Küçük Bobby Tablolar 'dan bahsetti mi?
katma yazar Douglas Tosi, kaynak
Bu uygulama iyi yazılmış değil. Hiç. Neredeyse asla değiller. :)
katma yazar Rob Walker, kaynak
Austin’in dediği gibi sorunları göstermekten başka. bir beyaz tahta ve bir işaretleme kaleminin gücünü hafife almayın. Çoğu insan, resim biçiminde açıkladığı kötü bir tasarıma iyi yanıt verir.
katma yazar Jason Anderson, kaynak
SQL enjeksiyon saldırısı göster?
katma yazar Steffen Ullrich, kaynak
eğer büyük değilse - yeniden yazın, büyükse - alma
katma yazar KevinOrr, kaynak
Müşteri yeniden tasarladığını söylüyor ve HTML/CSS'yi düşünüyor. "Modülerlik eksikliği" terimlerini kullanırdım ve "mantık tasarımı" ile "sunum" u vurgularım. Bina yapımının metaforları yararlıdır. Salon görünümünde bir değişiklik yapmak için, klima sistemine girmem gerekti. İyi bir modüler tasarımda böyle şeyler olmaz.
katma yazar davidbak, kaynak

14 cevap

Teknisyenler aptal değildir (çoğunlukla). Yeterince yüksek tutarsanız, teknik argümanı anlayabilirler. Basit olması gerektiğini düşündüğünüz bir görev seçin ve neden olmadıklarını gözden geçirin.

Bu değişikliğin bir dosyada tek bir kelime olmasını beklerdim. Büyük ihtimalle   değişmesi gereken yer burası gibi görünüyordu, fakat orayı değiştirdiğimde   sadece bir yerde çalıştı ve bu diğer 7 yeri kırdı. Ne zaman ben   bir tanesini düzelttikten sonra iki yer daha kırdı ve domino etkisi yarattı.   10 saat sürmesi gerektiğini düşündüğüm değişiklik 2 saat sürdü.   Bu sadece bir örnek. Orada daha çok beklenmeyen 2 saatlik görev var.

144
katma
Pek çok hata raporunun içeriği göz önüne alındığında, "daha fazla yer bozdu" gerçekten de domino etkisini tanımlamanın en iyi yolu gibi görünüyor ...
katma yazar Izkata, kaynak
Doğru, zaman ve maliyet arasında daha fazla bağlantı kurardım. Onlara, maliyette ne kadar bir değişiklik beklediğinizi ve bir değişikliğin maliyetinin ne kadar olduğunu bittiğini gösterin. Tecrübelerime göre müşteriler, harcamalarını iki, üç veya daha fazla harcayacağından daha fazla harcamalarını sağlayamazsanız, nadiren dikkat ederler.
katma yazar user1535427, kaynak

Kod yapısı, stil, teknik borç, en azından başlangıçta müşteri size güvenene kadar - birlikte yaşamanız gereken şeylerden biri.

Güvenlik açıkları başka bir konudur.

Şahsen, kod temeli ile ilgili önemli sorunların olduğunu açıkça ortaya koyarken mevcut yapı ve stili kullanarak gereken işi temel alarak bir tahmin yapacağım. Güvenlik etkilerini ayrı ayrı yükseltmek isterdim: bir toplantı sırasında konuyu eve götürmek için veritabanına bir saldırı düzenledi.

Bunu "kartım" kartına 5000 sterlin koyduğum ve hediye kartını kendi kartına kadar kontrol ettirdiğimde, bağlılık hediye kartı sistemi olan önceki bir müşteriyle bunu yapmaktan büyük keyif aldım.

87
katma
@FrustratedWithFormsDesigner, devasa bir ortamı olsa bile ...
katma yazar matte, kaynak
@Philip: ... demo, uygulama için tercihen yalıtılmış bir geliştirme ortamında bulunmalıdır. Üretim veritabanlarının silinmesi bu noktayı ispatlar, ancak sözleşmenizi kaybedebilir (ve bir dava kazanabilirsiniz).
katma yazar FrustratedWithFormsDesigner, kaynak
@FrustratedWithFormsDesigner: tabii ki ne kadar kolay ve dramatik olursa olsun, veritabanının silinmesi tavsiye edilmez. Ancak, özel verileri çıkarmak ve sonra (dikkatlice) bazı miktarları (@Michael tarafından yapılan bir hediye kartındaki bakiye gibi) değiştirmek de (onlar için) şaşırtıcı olabilir. Ekstra puan için, kodu gerçekten görmeniz gerekmediğini açıkça belirtin; Bir tablo listesi bırakarak başlayın, birkaç ilginç ad seçin, içeriği atmak. Bu kadar savunmasız olduğu noktasını delmek çok fazla sürmemelidir.
katma yazar Javier, kaynak
+1 demo, SQL enjeksiyon saldırısının ne kadar kötü olabileceğini gösteriyor. Onların önünde yap. Mümkünse, video tepkilerini kaydedin.
katma yazar Philip, kaynak

Bunun müşteriye nasıl iletileceği ve iletileceği hakkında bazı harika öneriler. Umarım sizin için öderler.

Buradaki büyük kırmızı bayrak!

Müşteri sizden kabul ettiklerinizden (HTML ve CSS) başka bir değişiklik yapmamanızı isterse, bu projeyi kabul eder ve teklifimi geri çekerim.

Tüm kusurların ve güvenlik sorunlarının yazılı ve iyi bir şekilde iletilmiş bir genel görünümüyle bile, potansiyel sorumluluk, rahat edemem için çok büyük. Müşteri, herhangi bir hackleme veya ihlalden sonra herhangi bir yasal işlem yapmamış veya talep edilen düzeltmeleri yapmamış olsa bile; isminiz ve ününüz hala işe bağlı!

Kazanmaya başladığınızdan çok daha fazlasını kaybedebilirsiniz.

76
katma
Daha geniş resmi görmek için +1. Üzerinde çalışırsanız ve işiniz bittiğini söylerseniz, yalnızca onları miras alsanız bile, hatalar ve güvenlik sorunları için bazı sorumluluklar doğurabilirsiniz. Birisi frenlerimi manipüle ederse ve bir tamirci bisikletimi onardı ve sorunu çözdü, ben de onları dava etmeyi düşünebilirim ...
katma yazar Julien Hoarau, kaynak
+1 bu, bir ders danışmanının öğrenmesi çok uzun süren bir derstir (ve kuşkusuz zorlu bir ekonomi boyunca sürdürülmesi zor bir kavramdır). Uzmanlığınızın değeri, yaptığınız işin bir işlevi olduğu kadar reddettiğiniz işlerin bir işlevidir.
katma yazar user1535427, kaynak
+1 Bu zor yoldan öğrendiğim bir ders ve ilk işim neredeyse bu yüzden uğraştı. Genellikle bu durumlarda, tüm 'kusurların' listelenmesi ve düzeltilmesinden alıntı yapılması, müşterinin ödemeye istekli olduğundan daha fazla çaba harcar.
katma yazar Catharz, kaynak

Explain and possibly demonstrate the flaw
When it's your word against his, everything you say could just be hot air as far as they're concerned. Once you show them how their app can be abused via SQL injection, then suddenly you're a person to be trusted. You're going to need credibility in order to renegotiate. And this is enough of a game-changer to give it to you.

Be charitable with respect to your predecessor
That doesn't mean pretend the mistakes aren't there, but if you come across condescending then you lose credibility. Don't say a word about the programmer except perhaps to give him the benefit of the doubt. Focus on the code, not the coder. Making them feel like you're the "good guy" will give you a lot more leeway in negotiations. And "good guys" never say mean things. When explaining existing security mistakes (such as SQL injection vulnerabilities) to the client, I prefer to say something like this:

Web uygulaması güvenliği hızla gelişen bir alandır. İnsanların bugün bile öğrendiği geliştirme araç ve tekniklerinin çoğu, bu istismarların çoğu iyi anlaşılmadan önce gelişti. Güvenlik gelişmelerinden uzak durmak için, alanı çok yakından takip etmek zorundasınız ve hatta tüm gelişim tarzınızı bile değiştirebiliyorsunuz. Çoğu programcı bunu yapmaz.

Oraya gidiyoruz. Geliştirici hakkında konuşulan bir kötülük kelimesi değil; O sadece "çoğu programcı" dır, yani oldukça iyi bir şirkettedir. Ve şimdi, size biraz daha güvenilirlik ve belki de size daha fazla para ödemeleri için bir neden veren "çoğu programcı" nın olmadığınızı olduğunuzu kanıtladınız.

Negotiate a new arrangement
Once the client understands that his app is open to abuse by the public, he's going to want it to be fixed. You are probably the person he's going to ask to fix it. You may or may not want that job, so think it over carefully before you talk to them.

En azından, size verdikleri işi bitirmek için daha fazla zaman istiyorsunuz. Onları, muhtemelen sizi orijinal tahmininizde tutamayacakları güvenlik açığı konularında yeterince korumasız bıraktınız. Ancak müşterinin ne olduğunu bildiğinden ve bu düzenlemenin bir parçası olarak tamir edemeyeceğinizden emin olun.

Genellikle geliştirici (siz) her şeyi sıfırdan yeniden yapmayı tercih eder. Ve böyle durumlarda, bu bir seçenek bile olabilir. Ancak o zaman bile, müşteri yeni uygulama yapılana kadar işini devam ettirebilecek bir şey isteyecek. Bu, yeniden başlamanıza rağmen, muhtemelen eski uygulamayı biraz güncellemeniz gerekecek hala olacaksınız.

30
katma
Asla küçümsemediğim için +1. Sadece gerçeklerin kendileri için konuşmasına izin ver ...
katma yazar Julien Hoarau, kaynak
"Selefinize göre hayırsever olun" için +1.
katma yazar typeseven, kaynak

Bunu bir yorum olarak başlattım, çünkü ilk başta bunun bir kenara olduğunu düşünmüştüm, ama muhtemelen gerçekten değil.

Yeniden tasarlanması gerektiğini düşündüğünüz her şeyi tam olarak belgeleyeceğim ve neden (( yapmazlarsa değişirse) ve sorunun düzeltilmesiyle ilgili bir tahmin. Güvenlik riski olarak algıladığınız her şey için özellikle titiz olurum.

Bunu herhangi bir koduna dokunmadan önce yapardım ve müşterinizin bu raporun bir kopyasına sahip olduğundan emin olun, tercihen bir zaman damgası. Biraz zaman alabilir, ancak bu güvenlik risklerinden birinin zarar görmesi durumunda sizi de kapsayacaktır. Daha da iyisi, belgeyi aldıklarını söyleyen bir şey imzalamanız durumunda.

Tabii, eğer olduysa, miras aldığınız orijinal kodun kaynağını kontrol etmeyi işaret edebilirsiniz, ancak bu belgeye işaret etmek ve daha profesyonel bir şekilde, "Bakın, size söylemiştim" demek daha kolay olacaktır.

Bu belge daha fazla tartışmanın başlangıç ​​noktası olabilir ve hatta müşteriniz tarafından değişikliklerin bir kısmını veya tamamını yapma izni vermek için "doğru kişileri" almak için bile kullanılabilir.

Müşteri bir kez riskleri anladıktan sonra, işi yine de yapmayı ya da çekip gitmediğini söylerse sırıtarak ve taşıyarak söylenir.

19
katma
sleske: Kabul edildi. İşin kabul edildiği varsayımını yaptım: "Yeni bir müşterim var ..." Ayrıca, "uzaklaşmak" bir seçenek.
katma yazar Daniel Wright, kaynak
sleske: Çok fazla çalışma yapacağını kabul etti, ancak en kötü durumun ortaya çıkması ve güvenlik ihlali olması durumunda size yardımcı olacağımıza inanıyorum. En azından, güvenlik riskleri gördüğünüzü ve önceden var olan bu risklerden sorumlu olmak istemediğinizi söyleyen bir şeye ihtiyacınız var.
katma yazar Daniel Wright, kaynak
@WonkotheSane: Doğru, ancak yalnızca projeyi alırsanız . Sorunlar çok büyükse ve planladığınız iş bu kadar küçükse, projeyi reddetmeniz daha iyi olabilir. Elbette, endişelerinizi hala belgelemelisiniz (güvenlik ve başka türlü), ancak proje üzerinde hiç çalışmamışsanız, hiçbir sorumluluk riski olmamalıdır. Sonunda, müşterinizin temizleme ücretini ödemeye istekli olup olmadığını ölçmeniz gerekecektir.
katma yazar Julien Hoarau, kaynak
Prensipte iyi fikir - ancak bunun bir olabileceğini unutmayın. Bu muhtemelen sadece büyük işler için pratiktir, aksi halde sadece 20 fatura alabileceğiniz bir iş için sorunları belgelemek için 50 saat harcarsınız.
katma yazar Julien Hoarau, kaynak
Umalım da aslında kaynak kontrolü kullanıyorlar.
katma yazar Mike W, kaynak
Mükemmel cevap. Ancak, tam bir dokümantasyon ve müşteri imzası içeren benzer bir durumla ilgili mahkemeye çıkmış biri olarak, bu bana hala çok para ve baş ağrısına mal oldu.
katma yazar TomOnTime, kaynak
@ Bardard Yapmazlarsa, ilk görevinin ne olacağını bilir.
katma yazar AndSoYouCode, kaynak

Müşterinin, uygulamalarını sürdürmede yardım için size gideceğini unutmayın. Başvurularında bulduğunuz sorunları belirtmek profesyonel olarak sizin işinizdir. Müvekkilin bu konuların var olduğu hakkında hiçbir fikri yoktur ve onlardan haberdar edilmeleri gerekir. Bu konuları anlayabilecekleri ve nasıl ilerlemek istediklerine karar vermelerine izin verecek şekilde açıklayın.

Araba yıkma veya tamirat gerektiren bir çamaşır makinesi gibi bu sorunları göstermek için gerçek dünya örneklerini kullanın. İşaret etmek, aşina oldukları örnekleri kullanmaktır. SQL enjeksiyonunu açıklamak için, bunun ne olduğunu ve neden bir sorun olduğunu göstereceğim.

Sonunda, üzerinde çalışmanız istenen uygulamanın başarısına önem verdiğinizi belirtmek istersiniz.

14
katma
Bu, amatör bir tamirci tarafından rastgele parçalardan yapılmış olmadıkça, parçalanmış bir arabaya benzemez. Beceriksiz bir yüklenici tarafından inşa edilmiş bir garaj gibidir ve sahibi OP'nin otomatik bir kapı açacağı koymasını ister. OP, garajın güvensiz olduğunu ve derhal büyük bir yeniden çalışmaya ihtiyacı olduğunu keşfetti.
katma yazar miguel.de.icaza, kaynak
Veya elle çalıştırılan hızlandırma için konsola bağlayabileceğiniz 'özel' kefalet sicim hızlandırıcı kablosunu not edin. Kırmızı Yeşil Şov'da yaptıkları hemen hemen her şey geçerli olabilir. Sahip oldukları “işleri”, ama hoş değil ve el yazısı incelemesinde kırılgan olduğu ve herhangi bir değişiklik riskini büyüttüğü gibi görünüyor.
katma yazar Amir, kaynak
Parçaları bir arada tutmak için koli bandı kullanan ve kontrol panelinin sürücüye herhangi bir uyarı veya uyarı vermesini engellerken, direksiyon simidinin herhangi bir anda düşebileceğini gösteren parçalanmış bir araba düşünün. Biraz yaratıcılık gerektirir, ancak bir sorunu göstermek için farklı analojiler kullanmak mümkündür.
katma yazar Mike W, kaynak
Buna ilave oylar ekleyebilseydim, 'Müşterinin başvurusunu sürdürmek için yardım edeceğini hatırladım.'
katma yazar chefgustav, kaynak

Müşterinin ilgili olabileceği analojileri kullanmayı seviyorum. İşi kazanmak için önceden koyduğum iş miktarı, müşterinin harcamak istediği para miktarına bağlı olacaktır (100 dolar, 20.000 dolardan çok farklıdır). Dikkat "niyet" demiştim. İstediğiniz değeri kişisel olarak tahmin etmek, sorduğunuz şeyi alamazsanız çok bir şey ifade etmiyor.

Sizin durumunuzda - yine paraya bağlı olarak - her bir taraftan çıkan bir çizgi içeren bir kutu çizip müşteriye "Bu, yazılımı şimdi nasıl görselleştirdiğinizdir. Veriler bir uçtan diğerine çıkar güzel, temiz ve basit görünüyor ". "Yazılımın iç kısımda nasıl göründüğünü düşünüyorsunuz" ve ardından kutunun içindeki iki çizgiyi birbirine bağlayan üçüncü bir çizgi çizin.

Sonra dışardaki giriş ve çıkış hatlarında ilk olan gibi başka bir kutu çizerdim, ama bu sefer "Yazılımın şu anki kutuda gerçekten nasıl göründüğü" diyordum. ve sonra bu sefer iki çizgiyi birbirine bağlamak için, muhtemelen ara vermeler, birleştirmeler ve karalamalar ile rastgele bir spagetti karmaşası yığını çizdim.

Sonunda, "Şimdi benden yapmamı istediğiniz şey şudur ..." derim ve ilk kutunun içine basit bir şekil çizerim, hatta hatta dokunan küçük bir yarım daire çizer ve sonra "ama bunu yaparım" derim. Bunu yapmak zorundayım ... "ve bir kasırga gibi görünen bir spiral şekil çizin ve çizginin etrafına devam edin ..." tüm bunları doyurmak için ..... "ve diğer kutudaki spagettiyi işaret edin.

2 dakika içinde bu konuyu eve götüreceğini düşünürdüm. Yine de yapmakta ısrar ediyorlarsa, o zaman yukarıda belirtilen diğerlerini belgeleyin.

7
katma

Dürüst ol ve doğrudan ol.

Ancak en önemlisi beklentilerinizi karşılamayacak bir işe girmeyin. Çoğu insan, bir müteahhitin bir müşteriyi kovabileceğinin farkında değil, işin değerinden daha fazla sorun olması durumunda yapabilir.

6
katma

Bu kodun ne kadar kötü olduğunu müşterime nasıl açıklayabilirim?

Belki de zaman içinde, düzeltmelerden ve yeniden yapılanmalardan sonra, o kadar kararsız hale gelen ve bir şeyi tamir ederken, bir şeyi düzeltirken, etkilemesi ve muhtemelen tamir etmesi gereken bir şeyi kırması ve bilmesi için hiçbir yolu olmadığı bir evde tesisatçılık gibi bir benzetme kullanabilirsiniz. Bunun gerçekleşeceği tüm yerler.

Bu önceki danışmana karşı benim sözümdür, bu yüzden teknik olmayan bir müşterinin anlayabileceği basit, somut örneklerimi nasıl verebilirim?

Haklısın, önceki danışmanın kafasında yarattığı görsellere karşı bir söz. Benim önerim, sadece ne istiyorsan onu yapmak, basit, somut örnekler vermektir. Bu yeniden bir tasarım olduğundan, derlenen kodda tanımlanan bir HTML parçasının bir HTML sayfasının geri kalanıyla nasıl görüntülendiğini ve bunun değiştirilmesinin sayfanın geri kalanını nasıl etkilediğini veya etkilemediğini gösterin. Belki de aynı derlenmiş kod, bazı "iş" kurallarını uyguladıktan sonra biçimlendirme oluşturur. Farkı göster.

Bu zor ve çok yaygın bir sorundur. Onunla iyi şanslar.

6
katma

İşte kullandığım bir benzetme (etkinliğini garanti etmeme rağmen): Web sitelerinin, bir şekilde girişi kabul eden mekanik bir matbaa gibi, fiziksel bir makine olduğunu hayal edin.

Muhtemelen makineyi X ve Y'yi yapan diğer bileşenler üzerinde olduğunu düşünüyorlar. Gerçekte, 20 veya daha fazla benzer makineye sahipler. Bazıları artık hiçbir şey yapmıyor, hepsi diğerlerinin yaptığı fonksiyonları önceden oluşturmaya çalışıyor ve önceki danışman dışında hiç kimse tam olarak onlar gibi bir şey görmemişti.

"Post değişkenlerini ayrıştırıp gönderen bu gizmoya bakın   bu bileşen if-elsesin tavşan deliğinden aşağıya doğru iniyor mu? Sadece bir tane yok   bunlardan, her sayfada bunlardan biri var (veya her neyse), bazıları   girişleri sterilize ederler ve bazıları etmiyor (veya hepsi yok) ve yok   Tüm bunları okurken hangisini bilemiyorum. "

3
katma
"Web sayfalarını, mekanik baskı makineleri gibi fiziksel bir makine olduğunu hayal edin" - ve baskı parası! Fakat, çünkü kırıldı, onları kandırması gereken kadar para basmıyor ...
katma yazar Rytis, kaynak

Henüz bahsetmediğim bir nokta, bu durumda müşterinizin sizden gerçekten ne istediğini alamayacağınızdır. Overachieving harika ve size bolca iş tatmini verebilir. Ancak müşteri basitçe umursamıyorsa, mevcut performansın "yeterince iyi" olduğunu düşünüyor ve bazı küçük güncellemeler istiyorsa, kod tabanını elden geçirmeleri için size büyük bir yatırım yapmaya ikna etmek mümkün olmayabilir.

Bu noktada, prensiplere dayanıp durmamaya karar vermeniz ve sizi iyi adınızı utanç verici bir kod karmaşasına eklemeye zorlayacak bir işe girmeyi reddetmeniz veya burnunuzu tutup tutmamanız, girmeniz, işinizin bitmesi gerekip gerekmediğine karar vermeniz gerekir. biraz koli bandı ile, ve ödeme ile çıkın.

Bununla birlikte, koli bandı işinde ilerlemeye karar verirseniz, belgelemeyi, belgelendirmeyi, belgelendirmeyi ve mümkün olduğunca şeffaf olduğundan emin olun. İstediğiniz son şey, müşteriyi hakkında uyardığınız bir uygulama hatası nedeniyle gelecekte yanlış giden bir şey için suçlanmak, ancak müşterinin o zaman başa çıkacak kadar önemli olmadığına karar vermesidir.

SQL enjeksiyon riskleri gittiği sürece, diğerlerinin dediği gibi, üretimde yıkıcı bir şey yapmadan, riskleri kendilerine gösterebilecek bir şekilde onlara tehlikeleri gösterebilmelisiniz. Fakat yine de, onu görürlerse ve düzeltmek için size yeterli parayı ödemiyorlarsa, bu durumda iyi niyetle çalışmanız gerekir.

2
katma

Kuşkusuz, uygulamadaki SQL enjeksiyon saldırıları ve diğer işlevsel hatalar önceliklidir, ancak hatalı kod kalitesini ve uygulamalarını "gösterebilirsiniz". Kod ölçüm araçlarıyla, kodun ne kadar kötü olduğunu açıkça gösterebilir ve gelecekteki değişikliklerin ve hata düzeltmenin maliyeti ne kadar tutacağını ona gösterebilirsiniz. Net ortamına aşina değilim, ancak alınacak birkaç tane olduğundan eminim.

1
katma
Neden bu konuda aşağı oy? Elbette, müşteri teknoloji dışı olabilir, ancak kod ölçütleri sayılar üretir ve herkes bunları anlayabilir. Özellikle iyi bir şekilde belgelenmiş, fazla teknik olmayan, bu sayıların ne anlama geldiğinin bir açıklaması varsa
katma yazar Rytis, kaynak

Burada şeytanın avukatı oynayacağım (biraz @khrome'nin söylediği satırlar boyunca: "müşterilere hayatınızı kolaylaştırmak için para ödemezsiniz"). Sunulan davanın çok yönlü olduğunu belirten bir noktaya kadar giderdim, çünkü davayı genel bir şekilde tanımladınız. Yeni bir projeye gelen çoğu danışman, bir öncekine kötü bir ışık yakar ... Burada ne yaptığınızı söylemiyorum, ama örnekleri görene kadar, bunun için sizin sözünüzü alamam.

Bu, size sorunları nokta nokta değinmeye çalışacağım dedi:

  • SQL Injections. OK, so I guess the programmer was using string concatenations instead of parameterized queries and/or stored procedure. This is very easy to fix especially in ADO.NET...I personally would mention it to the client but not make too much of a big deal out of it.
  • HTML is being generated in business logic and would be a nightmare to sort out. OK, dude, this is one of those where you give me more details. Unless you're using MVC, this is a tendency to happen...but it's not necessarily a bad thing...it's one of those things where most programmers would say "goto is bad; never use it" but you know what? I've used goto where it made sense! So, are you sure they're not using helper classes that happen to be sharing the same namespace as the business code DLL? Again, it's not that difficult to isolate.
  • business logic is spread throughout the entire application, there is a lot of duplication, and dead end code that does nothing.. And? Client is just asking you to change HTML/CSS. Why would you care about these issues at all?
  • it keeps throwing exceptions that are being smothered, so site appears to run smoothly. Again, very vague. Exceptions are normal in any applications, that's why we have try/catch clauses in our code. Unless they bubble up in UI and ruin the user experience (like displaying HTTP 500's unnecessarily), I don't think this is something that you should care about, either..

Kısacası, yüksek yollara çıkmanızı tavsiye ederim. Zamanınızın değmeyeceğini düşünüyorsanız ve bunu müşterinizin pahasına yeniden yazmak istiyorsanız, işten uzaklaşın. Cidden, sonunda, müşteri her şeyi en az $$$ ile çalışmasını sağlamak için zamanınızı öder.

Alandaki uzun yıllara dayanan tecrübemle, karşılaştığım en iyi programcıların bir sistemi en az miktarda kod yazarak kararlı hale getirebileceklerini söylüyorum > her şeyi yeniden yazma .

Düzenleme: Cevabımın en popüler olmadığını zaten görmüştüm (bunu çoktan ummuştum), ancak yanıtımın yanındayım. Bunu daha az becerikli yapmak için düzenledim. ;-)

0
katma

Bir projeye gelip yeniden yazmak için ilk şeyi önermek, değişikliklerin küçük bir alt kümesini gerçekleştirmek ve bunları ne kadar basit ve daha ucuz olabileceğini göstermek için kullanın. Ardından, daha temiz bir geliştirme maliyetinin neden düşük bir bakım maliyeti sağladığına ve uzun bir yazı tipi fiyatına bakıldığında uzun vadede daha hızlı bir gelişime neden olacağına dair kanıtlanabilir bir durum var.

Asla, temelde, kendi hayatınızı kolaylaştırmak için size para ödemelerini istediğinizi, onların aklında, X'in Y maliyetine göre özellik gösterebilen ve projenizin karmaşıklığını büyütmenin sadece ihtiyacını bulmanız gerektiğini asla unutmayın. senin için. Yeniden yazılan bir ay olduğunda zor bir yol ve yalnızca uygulamanın tamamen anlaşılan bir pencerede yazılan tüm ödünleri tam olarak anlayan bir geliştirici tarafından yazıldığını anlamak için orijinal geliştiriciyle görüşüyorsunuz. Uygulama dahili olarak korkunç görünüyorsa, ancak harici olarak iyi çalışıyorsa, dediğiniz gibi, bu muhtemelen böyle olacaktır. Genellikle, bir kod temeli içindeki teknik borç, kodun geliştirildiği kaynak kısıtlamalarının bir ürünüdür ve eğer bir ekip oluşturmazlarsa ve bunun yerine bir şeyleri kesiyorlarsa ... muhtemelen hala bakım konusunda ciddi değillerdir.

Sadece söylüyorum'

0
katma