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 uygulamaya yayılmıştır, çoğaltma işlemi vardır ve hiçbir şey yapmazsa çıkmaz kod vardır. Bunun üzerine, boğulmakta olan istisnalar atmaya devam ediyor, böylece 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ülecek bir kabus olacak. 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 seferlik 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üncelleme

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. Neden html ve css güncellemelerinin gerçekleşmesi için diğer bölümlerin (veri katmanında oluşturulan html gibi) daha iyi uygulamalarla değiştirilmesi gerektiğini açıklamanın yollarını arıyordum. Müvekkilim ile konuştuğumda birlikte yazacağım birçok iyi öneri var

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

Bu değişikliğin bir dosyada tek bir kelime olmasını bekliyordum. Bunu değiştirmenin en muhtemel yeri burada gözüküyordu, ama orayı değiştirdiğimde sadece bir yerde çalıştı ve bu diğer 7 yeri kırdı. Bir tanesini düzelttikten sonra iki yer daha kırdı ve domino etkisine neden oldu, bu yüzden 10 dakika sürmesi gerektiğini düşündüğüm bir değişiklik 2 saat sürdü. Bu sadece bir örnek. Orada daha çok beklenmeyen 2 saatlik görev var.

Kod yapısı, stil, teknik borç - en azından başlangıçta müşteri size güvenene kadar - birlikte yaşamaya ihtiyacınız olacak bir şey.

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 zevk aldım.

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

Burada 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 devreder 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.

Kusurun açıklanması ve muhtemelen gösterilmesi
Onun aleyhine sözünüz olduğunda, söylediğiniz her şey ilgili olduğu kadar sıcak hava olabilir. Onlara uygulamalarının SQL enjeksiyonu yoluyla nasıl kötüye kullanılabileceğini gösterdikten sonra, aniden güvenilecek bir insansınız. Pazarlık yapmak için güvenilirliğe ihtiyacınız olacak. Ve bu size vermesi gereken bir oyun değiştirici için yeterli.

Selefinize saygılı olun
Bu, hataların orada olmadığı gibi davranmak anlamına gelmez, ancak küçümseyeceğe rastlarsanız güvenilirliğini yitirirsiniz. Programcı hakkında bir şey söyleme, belki de ona şüphenin avantajını vermesi dışında. Kodlayıcıya değil, koda odaklanın. Onları senin "iyi adam" gibi hissetmeni sağlamak, görüşmelerde sana daha fazla yer açacak. Ve "iyi adamlar" asla bir şey ifade etmez. Müşteriye mevcut güvenlik hatalarını (örneğin SQL enjeksiyon açıkları gibi) açıklarken, şöyle bir şey söylemeyi tercih ederim:

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 etmeniz ve hatta zaman zaman tüm gelişim tarzınızı bile değiştirmelisiniz. Ç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 sağlayan ve belki de size daha fazla para ödemeleri için bir neden olan "çoğu programcı" olmadığınızı kanıtladınız .

Yeni bir düzenleme için pazarlık
yapma Müşteri, uygulamasının halk tarafından suistimal edilmeye açık olduğunu anladıktan sonra, düzeltilmesini isteyecektir. Muhtemelen düzeltmek isteyeceği kişi sizsiniz. Bu işi isteyebilir veya istemeyebilirsiniz, bu yüzden onlarla konuşmadan önce dikkatlice düşünün.

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

Genelde 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 bile üzerinde başlıyoruz olsa, muhtemelen olduğumuz anlamına gelir hala eski uygulamasını mı biraz güncellemek zorunda olacak.

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 tasarlamanız gerektiğini düşündüğünüz her şeyi ve neden (neden değişiklik yapmazsa ne olur ) ve sorunun çözülmesine dair bir tahminde bulunup bulunmadığını tam olarak belgeleyeceğim . Güvenlik riski olarak algıladığınız her şey için özellikle titiz olurum.

Herhangi bir koda dokunmadan önce bunu 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 kontrolünü işaretleyebilir, ancak bu belgeye işaret etmek ve daha profesyonel bir şekilde, "Gördün mü? Sana söyledim" demek daha kolay olacaktır.

Bu belge daha fazla tartışmanın başlangıç ​​noktası olabilir ve 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.

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 onarım 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.

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çta gider ve diğerinden çı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, ancak bu sefer “İşte yazılımın şu anki kutuda gerçekten nasıl göründüğünü” söylüyorum. ve 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" Bunu yapmak zorundayım ... "ve bir kasırga gibi bir sarmal şekli çizerek çizginin çevresine çizin ve devam edin ..." bütün bunların etrafını sarmak 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.

Müşterime bu kodun ne kadar kötü olduğunu 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 olmaması gibi bir evde tesisatçılık gibi bir benzetme kullanabilirsiniz. Bunun gerçekleşeceği tüm yerler.

Bu benim önceki danışmana karşı 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, tam olarak ne istiyorsan onu yapmak, basit, somut örnekler vermek. Bu yeniden bir tasarım olduğundan, derlenmiş 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 sağlar. Farkı göster.

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

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

Fakat 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.

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

Muhtemelen makineyi X ve Y yi yapan diğer bileşenlerin üzerinde olduğunu düşünürler. 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 kimse daha önce tam olarak onun gibi bir şey görmedi.

"Post değişkenlerini ayrıştırıp bu bileşeni iflasların tavşan deliğine gönderen bu gizmoya bakın? Bunlardan sadece biri yok, her sayfada bunlardan biri var (veya her neyse), bazıları girdiyi sterilize edin ve bazıları bilmiyor (ya da hepsi yok) ve bunların hepsini bilmeden hangisini bilemiyorum. "

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 imkansız olabilir.

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 bitip bitmemesi gerektiğ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österen 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.

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 daha 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 kısa bir yazı tipi yan maliyeti göz önüne alındığında uzun vadede daha hızlı gelişime neden olacağı konusunda 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 yoldur ve yalnızca tüm uygulamanın, yapılan tüm ödünleri tam olarak anlayan bir geliştirici tarafından son derece sözleşmeli bir pencerede yazıldığını anlamak için orijinal geliştiriciyle görüşmeniz gerekir. 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 ve bir takım oluşturmazlarsa ve bunun yerine sözleşmelerle uğraşıyorlarsa, kodun geliştirildiği kaynak kısıtlamalarının bir ürünüdür ...

Sadece söylüyorum'

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

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

• SQL enjeksiyonları . Tamam, programcının parametreli hale getirilmiş sorgular ve / veya saklı yordam yerine dize bitiştirmeler kullandığını düşünüyorum. Bu, özellikle ADO.NET'te düzeltilmesi çok kolaydır ... Şahsen bunu müşteriye söyleyeceğim, ancak çok fazla bir şey yapamayacağım.
• HTML iş mantığında üretiliyor ve çözülecek bir kabus olacak . Tamam, dostum, bu bana daha fazla ayrıntı verdiğin yerlerden biri. MVC kullanmıyorsanız, bu bir eğilimdir ... ama mutlaka kötü bir şey değil ... çoğu programcının " goto kötü; asla kullanmayın " diyeceği şeylerden biri ama ne biliyorsunuz? Ben kullandım goto ifadesi olduğu zamana! Peki, iş kodu DLL ile aynı ad alanını paylaşan yardımcı sınıfları kullanmadıklarından emin misiniz? Yine, izole etmek o kadar zor değil.
• iş mantığı tüm uygulamaya yayılmıştır, çoğaltma işlemi vardır ve hiçbir şey yapmazsa çıkmaz kod vardır. . Ve? Müşteri yalnızca sizden HTML / CSS'yi değiştirmenizi istiyor. Neden bu konuları umursuyorsun?
• boğulmakta olan istisnalar atmaya devam ediyor, böylece site sorunsuz çalışıyor gibi görünüyor . Yine, çok belirsiz. İstisnalar tüm uygulamalarda normaldir, bu yüzden kodumuzda try / catch cümleciklerimiz var. Kullanıcı arabiriminde kabarmadıkça ve kullanıcı deneyimini mahvetmedikçe (Gereksiz yere HTTP 500’leri göstermek gibi), bunun ya da umursamanız gereken bir şey olduğunu sanmıyorum.

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, her zaman karşılaştığım en iyi programcıların , her şeyi yeniden yazarak değil, en az miktarda kod yazarak bir sistemi istikrarlı hale getirebilecekleri olduğunu söylerim .

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. ;-)

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.