Dimostrare un codice errato per il client?

Un cliente mi ha chiesto di riprogettare il suo sito Web, un'applicazione ASP.NET Webform sviluppata da un altro consulente. Sembrava un lavoro relativamente semplice, ma dopo aver esaminato il codice, è chiaro che non è così.

Questa applicazione non è stata scritta bene. Affatto. È estremamente vulnerabile agli attacchi di SQL injection, la logica di business è diffusa in tutta l'applicazione, c'è molta duplicazione e il codice vicolo cieco che non fa nulla. Inoltre, continua a generare eccezioni che vengono soffocate, quindi il sito sembra funzionare senza problemi.

Il mio compito è semplicemente aggiornare HTML e CSS, ma gran parte dell'HTML viene generato nella logica aziendale e sarebbe un incubo da risolvere. La mia stima sulla riprogettazione è più lunga di quanto il cliente mirasse. Stanno chiedendo perché così a lungo.

Come posso spiegare al mio cliente quanto sia cattivo questo codice? Nella loro mente, l'applicazione funziona alla grande e la riprogettazione dovrebbe essere una tantum una tantum. È la mia parola contro il precedente consulente. Come posso fornire esempi semplici e concreti che un cliente non tecnico capirà?

Aggiornare

Grazie per tutte le risposte. La dimostrazione dell'attacco con iniezione SQL ha senso e lo dimostrerò in un ambiente di test. Questa è solo una parte di molti problemi in questa applicazione. Stavo cercando dei modi per spiegare perché altre parti (come l'html generato nel livello dati) avrebbero dovuto essere sostituite con migliori pratiche per consentire l'aggiornamento dell'html e del CSS. Ci sono molti buoni suggerimenti qui che metterò insieme quando parlo con il mio cliente.

I non tecnici non sono idioti (per la maggior parte). Riescono a comprendere un argomento tecnico se lo tieni abbastanza alto livello. Scegli un'attività che ritieni debba essere semplice e guidale attraverso il perché non lo è.

Mi aspettavo che questa modifica fosse una parola in un file. Il posto più probabile per cambiare sembrava essere qui, ma quando l'ho cambiato lì, ha funzionato solo in un posto, e ha rotto questi altri 7 posti. Quando ne ho riparato uno, ha rotto altri due posti, causando un effetto domino, quindi un cambiamento che pensavo avrebbe dovuto durare 10 minuti ha finito per richiedere 2 ore. Questo è solo un esempio. Ci sono molte altre attività inaspettate di 2 ore.

Struttura del codice, stile, debito tecnico sono una cosa con cui - almeno inizialmente, fino a quando il cliente non si fida di te - dovrai convivere.

Le vulnerabilità della sicurezza sono un'altra questione.

Personalmente, farei una stima in base al lavoro richiesto utilizzando la struttura e lo stile esistenti chiarendo al contempo che ci sono problemi significativi con la base di codice. Solleverei le implicazioni di sicurezza separatamente: fare una dimostrazione di un hack sul database per guidare il punto a casa durante una riunione.

Mi ha fatto molto piacere farlo con un cliente precedente con un sistema di carte regalo fedeltà quando ho messo £ 5000 sulla "mia" carta e gli ho fatto controllare la carta sulla sua cassa.

Alcuni ottimi suggerimenti qui su come trasmettere e comunicare questo al cliente. Spero che ti ripagheranno.

Importante bandiera rossa qui!

Se il cliente ti chiede di non apportare modifiche diverse da quelle che hai accettato (HTML e CSS), trasmetterei questo progetto e ritirare la mia offerta.

Anche con una panoramica scritta e ben comunicata di tutti i difetti e le questioni di sicurezza, la potenziale responsabilità è semplicemente troppo grande per me essere a mio agio. Anche se il cliente non ha mai intrapreso azioni legali o ha richiesto correzioni dopo un hack o una violazione; il tuo nome e la tua reputazione sono ancora associati all'opera!

Potresti perdere molto più di quanto tu possa guadagnare.

Spiega e forse dimostra il difetto
Quando è la tua parola contro la sua, tutto ciò che dici potrebbe essere solo aria calda per quanto li riguarda. Una volta che mostri loro come è possibile abusare della loro app tramite iniezione SQL, allora improvvisamente sei una persona di cui ti puoi fidare. Avrai bisogno di credibilità per rinegoziare. E questo è abbastanza per cambiare il gioco per dartelo.

Sii caritatevole rispetto al tuo predecessore
Ciò non significa che fingi che gli errori non ci siano, ma se ti imbatti in condiscendenza, perdi credibilità. Non dire una parola sul programmatore, tranne forse per dargli il beneficio del dubbio. Concentrati sul codice, non sul programmatore. Farli sentire come se fossi il "bravo ragazzo" ti darà molto più margine di manovra nei negoziati. E i "bravi ragazzi" non dicono mai cose cattive. Quando si spiegano al client errori di sicurezza esistenti (come le vulnerabilità di SQL injection), preferisco dire qualcosa del genere:

La sicurezza delle applicazioni Web è un campo in rapida evoluzione. Molti degli strumenti e delle tecniche di sviluppo che le persone imparano ancora oggi si sono evoluti prima che la maggior parte di questi exploit fossero ben compresi. Per stare al passo con gli sviluppi della sicurezza, devi seguire il campo molto da vicino e, occasionalmente, anche cambiare l'intero stile di sviluppo. La maggior parte dei programmatori non lo fa.

Eccoci. Non una parola malvagia parlata dallo sviluppatore; è solo "la maggior parte dei programmatori", il che significa che è in ottima compagnia. E ora hai dimostrato che sei non "maggior parte dei programmatori" che vi danno un po 'più di credibilità e forse un motivo per loro di pagare più soldi.

Negoziare un nuovo accordo
Una volta che il cliente avrà capito che la sua app è aperta agli abusi da parte del pubblico, vorrà che venga risolto. Probabilmente sei la persona che chiederà di ripararlo. Potresti o non vuoi quel lavoro, quindi pensaci attentamente prima di parlare con loro.

Per lo meno, vuoi più tempo per finire il lavoro che ti hanno già dato. Li hai messi abbastanza alla sprovvista con le cose vulnerabili che probabilmente non ti terranno alla tua stima originale. Ma assicurati che il cliente sappia cosa sei e che non risolverà come parte di questo accordo.

In genere lo sviluppatore (tu) preferiresti ripetere tutto da zero. E in casi come questo, potrebbe anche essere un'opzione. Ma anche in questo caso, il cliente vorrà qualcosa che possa far funzionare la sua attività fino alla creazione della nuova app. Ciò significa che anche se stai ricominciando, probabilmente dovrai comunque aggiornare un po 'la vecchia app.

Ho iniziato questo come un commento, perché all'inizio pensavo fosse un accantonamento, ma probabilmente non lo è.

Vorrei documentare pienamente tutto ciò che ritieni debba essere riprogettato e perché (cosa succede se non apportano la modifica) e una stima per risolvere il problema. Sarei particolarmente meticoloso con qualsiasi cosa tu percepisca come un rischio per la sicurezza.

Lo farei prima di toccare qualsiasi codice e assicurerei che il tuo cliente abbia una copia di questo rapporto, preferibilmente con un qualche tipo di data e ora. Potrebbe volerci del tempo, ma ti coprirà anche se uno di questi rischi per la sicurezza dovesse mai realizzarsi. Ancora meglio se riesci a ottenere qualcosa firmato che dice che hanno ricevuto il documento.

Certo, puoi indicare il controllo del codice originale del codice che hai ereditato, se mai dovesse accadere, ma sarà molto più facile puntare a questo documento e dire, in modo più professionale, "Vedi? Te l'ho detto."

Questo documento può essere il punto di partenza di ulteriori discussioni e può anche essere utilizzato dal tuo cliente per ottenere le "persone giuste" per dare il permesso di apportare alcune o tutte le modifiche.

Detto questo, una volta che il cliente capisce i rischi, sorridi e sopporta se gli dicono di fare comunque il lavoro o se ne vanno.

Ricorda che il cliente ti chiederà aiuto per mantenere la sua applicazione. Il tuo lavoro come professionista è quello di evidenziare eventuali problemi riscontrati con la loro applicazione. Il cliente probabilmente non ha idea che questi problemi esistano e dovrebbero esserne informati. Spiega questi problemi in modo che possano capire e lascia che decidano come vogliono procedere.

Usa esempi del mondo reale per illustrare questi problemi, come un'auto in panne o una lavatrice che necessita di riparazione. Indicare è usare esempi con cui hanno già familiarità. Per spiegare l'iniezione di SQL, vorrei semplicemente dimostrare di cosa si tratta e perché è un problema.

Alla fine, vuoi comunicare che ti preoccupi del successo dell'applicazione su cui ti viene chiesto di lavorare.

Mi piace usare le analogie a cui il cliente può fare riferimento. La quantità di lavoro che ho messo in primo piano per vincere il lavoro dipenderebbe dalla quantità di denaro che il cliente intendeva spendere ($ 100 è molto diverso da $ 20.000). Si noti che ho detto "intenzionale". La tua stima personale del valore coinvolto non significa molto se non ottieni quello che stai chiedendo.

Nella tua situazione, sempre a seconda del denaro, potrei disegnare una scatola con una linea che esce da ogni lato e dire al cliente "Ecco come visualizzi il software adesso. I dati vanno da un lato e vengono dall'altro, tutto sembra bello, pulito e semplice ". "Questo è ciò che pensi che il software assomigli all'interno" e quindi disegna una terza linea che collega le due linee all'interno della scatola.

Quindi disegnerei un'altra scatola come la prima con le linee di input e output all'esterno, tranne che stavolta direi "Ecco come appare il software all'interno della box in questo momento". e poi per collegare le due linee questa volta disegnavo un mucchio casuale di pasticcio di spaghetti, possibilmente con pause, giunzioni e scarabocchi.

Alla fine direi "Ora quello che mi stai chiedendo di fare è questo ..." e disegnare una forma semplice all'interno della prima casella, forse un piccolo semicerchio che tocca la linea e poi dire "ma per farlo, io ' dovrei farlo ... "e disegnare un tornado dall'aspetto a forma di spirale attorno alla linea e continuare ..." per aggirare tutto questo ..... "e indicare gli spaghetti nell'altra scatola.

Penserei che porterebbe il punto a casa in circa 2 minuti. Se insistono che tu lo faccia comunque, allora documentalo come altri citano sopra.

Come posso spiegare al mio cliente quanto sia cattivo questo codice?

Forse puoi usare un'analogia come l'impianto idraulico in una casa che nel tempo, dopo correzioni e rimodellamenti, diventa così instabile e accoppiato che quando ripara una cosa, influenza e forse rompe qualcos'altro che poi ha bisogno di essere riparato e non c'è proprio modo di saperlo tutti i luoghi in cui ciò accadrà.

È la mia parola contro il consulente precedente, quindi come posso effettivamente fornire esempi semplici e concreti che un cliente non tecnico comprenderebbe?

Hai ragione, è una parola contro qualsiasi immagine visiva creata dal consulente precedente. Il mio consiglio è di fare proprio quello che stai chiedendo, dare esempi semplici e concreti. Poiché si tratta di una riprogettazione, mostra come viene visualizzato un frammento HTML definito nel codice compilato con il resto di una pagina HTML e come la modifica che influisce o meno, il resto della pagina. Forse lo stesso codice compilato rende il markup dopo l'applicazione di una regola "aziendale". Mostra la differenza

Questo è un problema difficile e MOLTO comune. Buona fortuna.

Sii onesto e sii diretto.

Ma soprattutto non assumere un lavoro che non soddisfi le tue aspettative. Molte persone non si rendono conto che un appaltatore può licenziare un cliente, possono e dovrebbero se il lavoro è più un problema di quanto valga la pena.

Ecco un'analogia che ho usato (anche se non garantisco la sua efficacia): Immagina che il loro sito Web sia una macchina fisica, come una macchina da stampa meccanica che in qualche modo accetta input.

Probabilmente pensano che la macchina abbia un componente che fa X e un altro che fa Y. In realtà, sono circa 20 macchine per lo più simili. Alcuni di loro non fanno più nulla, tutti cercano di preformare le funzioni che altri già fanno e nessuno, a parte il consulente precedente, non ha mai visto nulla di simile esattamente prima.

"Vedi questo gizmo qui che analizza le variabili post e quindi invia questo componente in una tana di coniglio di if-elses? Non ce n'è solo uno, ce n'è uno in ogni pagina (o qualunque cosa), alcuni disinfetta l'input e alcuni non lo fanno (o tutti non lo fanno) e senza leggere l'intera cosa non so quale. "

Un punto non ancora menzionato è che potresti semplicemente superare quello che il tuo cliente vuole davvero da te in questo caso. Overachieving è fantastico e può darti molte soddisfazioni lavorative. Ma se al cliente semplicemente non importa, pensa che le prestazioni attuali siano "abbastanza buone" e vogliono solo alcuni aggiornamenti minori, potrebbe essere impossibile convincerle a fare un grande investimento in te per revisionare la base di codice.

A quel punto probabilmente dovrai decidere se mantenere i principi e rifiutarti di accettare un lavoro che ti costringerebbe ad associare il tuo buon nome a un pasticcio imbarazzante di codice o se puoi trattenere il naso, entrare, fare il lavoro con un po 'di nastro adesivo e uscire con il pagamento.

Se decidi di proseguire con il processo del nastro adesivo, assicurati di documentare, documentare, documentare ed essere il più trasparente possibile. L'ultima cosa che vuoi è essere incolpato per qualcosa che non va in futuro a causa di un difetto dell'applicazione di cui hai avvertito il cliente ma che il cliente ha deciso che non era abbastanza importante da affrontare in quel momento.

Per quanto riguarda i rischi di iniezione di SQL, come altri hanno detto che dovresti essere in grado di dimostrare loro i pericoli in un modo che mostri i rischi senza effettivamente fare qualcosa di distruttivo nella produzione. Ma ancora una volta, se lo vedono e non si preoccupano abbastanza di pagarti per ripararlo, hai fatto la tua diligenza in buona fede in questo caso.

È una salsa noob entrare in un progetto e suggerire una prima riscrittura, eseguire alcuni piccoli sottogruppi delle modifiche e usarli per illustrare quanto avrebbe potuto essere più semplice ed economico . Quindi hai un caso dimostrabile sul perché l'aumento del costo di uno sviluppo più pulito porterà a costi di manutenzione più bassi e uno sviluppo più rapido a lungo termine, dato un piccolo costo laterale del font.

Non dimenticare mai che fondamentalmente stai chiedendo loro di pagarti per rendere la tua vita più facile, nella loro mente la necessità di trovare "il ragazzo" che può X funzioni a costo di Y e aumentare la complessità del tuo progetto potrebbe semplicemente eliminare l'opportunità per te. È una strada difficile quando hai un mese di riscrittura e hai un incontro con lo sviluppatore originale solo per rendersi conto che l'intera app è stata scritta in una finestra estremamente contratta da uno sviluppatore che ha compreso appieno tutti i compromessi che sono stati fatti. Se l'app internamente sembra orribile ma funziona esternamente bene, come dici tu, è molto probabile che sia così. Spesso il debito tecnico all'interno di una base di codice è un prodotto dei vincoli di risorse in cui il codice è stato sviluppato e se non stanno costruendo una squadra e stanno invece contraendo cose ...

Sto solo dicendo'

Qui interpreterò l'avvocato del diavolo (un po 'sulla falsariga di ciò che @khrome sta dicendo: "non stai pagando i clienti per semplificarti la vita"). Andrei persino al punto di affermare che il caso che hai presentato è troppo unilaterale perché lo hai descritto in modo generale. La maggior parte dei consulenti in arrivo per un nuovo progetto farebbe brutta luce a quello precedente ... Non sto dicendo che è quello che stai facendo qui, ma finché non vediamo esempi, non posso semplicemente prendere la tua parola per questo.

Detto questo, cercherò di affrontare i problemi punto per punto:

• Iniezioni SQL . OK, quindi immagino che il programmatore stesse usando concatenazioni di stringhe invece di query con parametri e / o stored procedure. Questo è molto facile da risolvere soprattutto in ADO.NET ... Personalmente lo menzionerei al client ma non ne trarrebbe troppi problemi.
• L'HTML viene generato nella logica aziendale e sarebbe un incubo da risolvere . Ok amico, questo è uno di quelli in cui mi dai maggiori dettagli. A meno che tu non stia usando MVC, questa è una tendenza che accadrà ... ma non è necessariamente una cosa negativa ... è una di quelle cose in cui la maggior parte dei programmatori direbbe " vai male, non usarlo mai" ma sai cosa? Ho usato goto dove aveva senso! Quindi, sei sicuro che non stiano usando classi helper che condividono lo stesso spazio dei nomi della DLL del codice aziendale? Ancora una volta, non è così difficile isolare.
• la logica aziendale è diffusa in tutta l'applicazione, c'è molta duplicazione e un codice vicolo cieco che non fa nulla. . E? Il cliente ti sta solo chiedendo di cambiare HTML / CSS. Perché dovresti preoccuparti di questi problemi?
• continua a generare eccezioni che vengono soffocate, quindi il sito sembra funzionare senza problemi . Ancora una volta, molto vago. Le eccezioni sono normali in qualsiasi applicazione, ecco perché abbiamo clausole try / catch nel nostro codice. A meno che non si diffondano nell'interfaccia utente e rovinino l'esperienza dell'utente (come visualizzare inutilmente gli HTTP 500), non penso che questo sia qualcosa di cui dovresti preoccuparti, ..

Quindi in breve, ti consiglierei di prendere la strada maestra. Se ritieni che non valga la pena dedicare tempo e vuoi riscriverlo a spese del tuo cliente, allontanati dal lavoro. Seriamente, alla fine, il cliente paga per il tuo tempo per far funzionare il tutto con il minimo importo di $$$.

Nella mia pluriennale esperienza nel settore, dico sempre che i migliori programmatori che ho incontrato sono quelli che possono rendere stabile un sistema scrivendo la minima quantità di codice , non riscrivendo il tutto .

Modifica: vedo già che la mia risposta non è la più popolare (me l'aspettavo già) ma resto fedele alla mia risposta. L'ho modificato per renderlo meno appariscente. ;-)

Sicuramente gli attacchi SQL injection e altri difetti funzionali nell'applicazione hanno avuto la precedenza, ma è anche possibile "dimostrare" la qualità e le pratiche del codice errato. Con gli strumenti di metrica del codice puoi dimostrare chiaramente quanto è cattivo il codice e mostrargli quanto questo si sommerà nel costo per eventuali modifiche future e correzione di bug. Non ho familiarità con l'ambiente .net ma sono sicuro che ce ne sono diversi da cui prelevare.