Dimostrare codice errato al client?

I non-techies non sono idioti (per la maggior parte). Possono capire un argomento tecnico se lo si mantiene abbastanza alto. Scegli un'attività che ritieni debba essere semplice e spiegagli perché non lo è.

I expected this change to be one word in one file. The most likely place to change it seemed to be here, but when I changed it there, it only worked in one place, and it broke these 7 other places. When I fixed one, it broke two more places, causing a domino effect, so a change I thought should have taken 10 minutes ended up taking 2 hours. That's just one example. There are a lot more unexpected 2 hour tasks in there.

La struttura del codice, lo stile, il debito tecnico sono una cosa che - almeno inizialmente, finché il cliente si fida di te - con cui dovrai convivere.

Le vulnerabilità della sicurezza sono un'altra questione.

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

Ho avuto una grande gioia a 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 paghino per te.

Major red flag here!

Se il cliente ti chiede di non apportare modifiche diverse da quelle che hai accettato (HTML e CSS), passerò 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 responsabilità potenziale è troppo grande per me per essere a mio agio con. Anche se il cliente non ha mai intrapreso alcuna azione legale o richiesto correzioni dopo un attacco o una violazione; il tuo nome e la tua reputazione sono ancora attaccati al lavoro!

Potresti perdere molto più di quello che guadagnerai.

Spiega e possibilmente dimostra la falla
Quando è la tua parola contro la sua, tutto ciò che dici potrebbe essere solo aria calda per quanto riguarda loro. Una volta che mostri loro come si può abusare della loro app tramite SQL injection, allora improvvisamente sei una persona di cui fidarsi. Avrai bisogno di credibilità per poter rinegoziare. E questo è sufficiente per cambiare gioco.

Sii caritatevole rispetto al tuo predecessore
Ciò non significa far finta che gli errori non ci siano, ma se ti imbatti in condiscendenti, 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à molta più libertà di trattativa. E i "bravi ragazzi" non dicono mai cose cattive. Quando si spiegano gli errori di sicurezza esistenti (come le vulnerabilità di SQL injection) al client, preferisco dire qualcosa del tipo:

Web application security is a rapidly-evolving field. Many of the development tools and techniques that people learn even today evolved before most of these exploits were well-understood. In order to stay ahead of security developments, you have to follow the field very closely and occasionally even change your whole development style. Most programmers don't do this.

Eccoci. Non una parola del male parlata dello sviluppatore; è solo "la maggior parte dei programmatori", il che significa che è in buona compagnia. E ora hai dimostrato che sei non "la maggior parte dei programmatori" che ti dà un po 'più di credibilità e forse un motivo per cui ti pagano di più.

Negozia un nuovo accordo
Una volta che il cliente capirà che la sua app è aperta agli abusi da parte del pubblico, vorrebbe che fosse riparata. Probabilmente sei la persona che sta per chiedere di sistemare. Potresti o meno volere 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 in guardia con la vulnerabilità che probabilmente non ti terranno alla tua stima originale. Ma assicurati che il cliente sappia cosa sei e non risolverà come parte di questo accordo.

Tipicamente lo sviluppatore (tu) preferirebbe rifare 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 azienda fino a quando non verrà creata la nuova app. Ciò significa che anche se stai ricominciando da capo, probabilmente ancora dovresti aggiornare un po 'la vecchia app.

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

Vorrei documentare completamente tutto ciò che ritieni debba essere ridisegnato e perché (cosa succede se non apporta la modifica) e una stima sulla risoluzione del problema. Sarei particolarmente meticoloso con qualsiasi cosa tu percepisca come un rischio per la sicurezza.

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

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

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

Detto questo, una volta che il cliente sottovaluta i rischi, sorridi e sopporti se dicono di fare comunque il lavoro, o se vai via.

Ricorda che il cliente ha intenzione di aiutarti per mantenere la loro applicazione. È il tuo lavoro come professionista per segnalare eventuali problemi che trovi nella loro applicazione. Il cliente probabilmente non ha idea che questi problemi esistano e dovrebbero essere messi a conoscenza di essi. Spiega questi problemi in modo che possano capire e lascia che decidano come vogliono procedere.

Usa esempi del mondo reale per illustrare questi problemi, ad esempio un'auto che si rompe o una lavatrice che ha bisogno di riparazioni. Puntare è usare esempi con cui hanno già familiarità. Per spiegare l'iniezione SQL, vorrei semplicemente dimostrare che cos'è e perché è un problema.

Alla fine vuoi trasmettere che tieni a cuore il successo dell'applicazione a cui ti viene chiesto di lavorare.

Mi piace usare le analogie con cui il cliente può identificarsi. La quantità di lavoro che ho messo in anticipo per vincere il lavoro dipenderebbe dalla quantità di denaro che il cliente intendeva spendere ($ 100 è molto diverso da $ 20.000). Notate che ho detto "intendendo". La tua stima personale del valore in questione non significa molto se non ottieni ciò che stai chiedendo.

Nella tua situazione - sempre a seconda dei soldi - Potrei disegnare una scatola con una linea che esce da ciascun lato e dire al cliente "Questo è il modo in cui visualizzi il software ora. I dati vanno da una parte e vengono fuori altro, tutto sembra bello, pulito e semplice ". "Questo è quello che pensi che il software assomigli all'interno" e quindi disegna una terza linea che collega le due linee all'interno della scatola.

Poi disegnerei un'altra scatola come la prima con le linee di input e output all'esterno, ma questa volta direi "Ecco come si presenta il software all'interno della scatola in questo momento". e poi per collegare le due linee questa volta disegnerei un mucchio casuale di pasticcio di spaghetti, possibilmente con pause e join e scarabocchi.

Finalmente direi, "Ora quello che mi chiedi di fare è questo ..." e tracciare una forma semplice all'interno della prima scatola, magari un piccolo semicerchio che tocchi la linea e poi dica "ma per farlo , Dovrei farlo ... "e disegnare un tornado dall'aspetto a spirale intorno alla linea e continuare ..." per aggirare tutto questo ..... "e indicare gli spaghetti nel altra scatola.

Penserei che porterebbe a casa il punto in circa 2 minuti. Se insistono che lo fai comunque, documentalo come altri menzionano sopra.

Come posso spiegare al mio cliente quanto è grave questo codice?

Forse puoi usare un'analogia come l'impianto idraulico in una casa che nel tempo, dopo correzioni e rimodellamenti, diventa così volubile e accoppiata che quando si aggiusta una cosa, colpisce e forse rompe qualcos'altro che poi ha bisogno di aggiustare e non c'è proprio modo di per sapere tutti i posti in cui ciò avverrà.

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

Hai ragione, è una parola contro qualsiasi visuale che il consulente precedente ha creato nelle loro teste. Il mio suggerimento è quello di fare solo quello che stai chiedendo, dare esempi semplici e concreti. Poiché si tratta di una riprogettazione, mostra come un frammento HTML definito nel codice compilato viene visualizzato con il resto di una pagina HTML e in che modo la modifica influisce o meno, il resto della pagina. Forse lo stesso codice compilato restituisce markup dopo aver applicato una regola "aziendale". Mostra la differenza.

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

Sii onesto e diretto.

Ma soprattutto non assumere un lavoro che non soddisfi le tue aspettative. La maggior parte delle persone non si rende conto che un appaltatore può licenziare un cliente, può e deve farlo se il lavoro è più difficile di quanto valga.

Ecco un'analogia che ho usato (sebbene non ne dichiari l'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 tentano di preformare le funzioni che gli altri fanno già e nessuno oltre al precedente consulente ha mai visto niente di simile a loro prima.

"See this gizmo here that parses the post variables and then sends this component down a rabbit-hole of if-elses? There isn't just one of these, there is one of these in every page (or whatever), some of them sanitize the input and some don't (or all don't) and without reading the entire thing I can't know which."

Un punto che non è ancora stato menzionato è che potresti semplicemente superare ciò che il tuo cliente desidera davvero da te in questo caso. Il superamento è grande e può darti un sacco di soddisfazione sul lavoro. Ma se il cliente semplicemente non si preoccupa, pensa che le prestazioni correnti siano "abbastanza buone" e vuole solo alcuni aggiornamenti minori, potrebbe essere impossibile persuaderli a fare un grande investimento in te per revisionare il codice base.

A quel punto probabilmente dovrai decidere se appoggiarti ai principi e rifiutarti di accettare un lavoro che ti costringerà ad attribuire il tuo buon nome a un pasticcio imbarazzante del codice o se puoi tenere il naso, entrare, prendere il lavoro fatto con del nastro adesivo e uscire con il pagamento.

Se decidi di andare avanti con il duct tape, assicurati di documentare, documentare, documentare ed essere il più trasparente possibile. L'ultima cosa che vuoi è essere incolpata di qualcosa che sta andando storto in futuro, a causa di un difetto dell'applicazione che hai avvertito il cliente ma che il cliente ha deciso di non essere abbastanza importante da gestire al momento.

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

È salsa noob per entrare in un progetto e suggerire di riscrivere la prima cosa, eseguire qualche piccolo sottoinsieme delle modifiche e usarle per illustrare quanto potrebbe essere stato più semplice ed economico. Poi hai un caso dimostrabile sul perché il maggior costo di uno sviluppo più pulito porterà a costi di manutenzione più bassi ea uno sviluppo più rapido nel lungo periodo, a fronte di un piccolo costo di carattere tipografico.

Non dimenticare mai che fondamentalmente chiedi loro di pagarti per rendere la tua vita più facile, nella loro mente il solo bisogno di trovare "il ragazzo" che può X funzioni a Y costo e ingrandendo la complessità del tuo progetto può solo elimina l'opportunità per te. È una strada difficile quando sei in fase di riscrittura e hai incontrato lo sviluppatore originale solo per capire che l'intera app è stata scritta in una finestra estremamente contrattata da uno sviluppatore che ha compreso appieno tutti i compromessi che sono stati fatti. Se l'applicazione internamente sembra orribile ma funziona esternamente bene, come dici tu, è molto probabile che sia così. Spesso il debito tecnico all'interno di un codebase è un prodotto dei limiti di risorse in cui il codice è stato sviluppato e se non stanno costruendo una squadra e stanno invece contraendo le cose ... probabilmente non sono ancora seri sulla manutenzione.

Sto solo dicendo

Vado qui a fare l'avvocato del diavolo (in qualche modo sulla falsariga di ciò che @khrome sta dicendo: "non stai pagando i clienti per rendere la tua vita più facile"). Mi spingerei persino a dire che il caso che hai presentato è troppo unilaterale perché hai descritto il caso in maniera generale. La maggior parte dei consulenti in arrivo a un nuovo progetto farebbe breccia a quella precedente ... Non sto dicendo che è quello che stai facendo qui, ma finché non vediamo esempi, non posso semplicemente crederci sulla parola.

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

• Iniezioni SQL . OK, quindi suppongo che il programmatore stia usando concatenazioni di stringhe invece di query parametrizzate e / o stored procedure. Questo è molto facile da correggere, specialmente in ADO.NET ... Personalmente lo menzionerei al cliente ma non ne trarrai troppa importanza.
• L'HTML viene generato nella logica di business e sarebbe un incubo da risolvere . OK, amico, questo è uno di quelli in cui mi dai maggiori dettagli. A meno che tu non stia utilizzando MVC, è probabile che succeda ... ma non è necessariamente una brutta cosa ... è una di quelle cose in cui la maggior parte dei programmatori direbbe che " goto è cattivo, mai usato "ma sai una cosa? Ho usato goto dove aveva senso! Quindi, sei sicuro che non stiano utilizzando classi helper che condividono lo stesso spazio dei nomi della DLL del codice aziendale? Di nuovo, non è così difficile isolare.
• la logica aziendale è diffusa nell'intera applicazione, c'è molta duplicazione e codice di vicolo cieco che non fa nulla. . E? Il cliente ti chiede semplicemente di cambiare HTML / CSS. Perché dovresti preoccuparti di questi problemi?
• continua a generare eccezioni che vengono soffocate, quindi il sito sembra funzionare senza intoppi . Di nuovo, molto vago. Le eccezioni sono normali in tutte le applicazioni, ecco perché abbiamo provato / prendere le clausole nel nostro codice. A meno che non emergano nell'interfaccia utente e rovinino l'esperienza dell'utente (come la visualizzazione di HTTP 500 inutilmente), non penso che sia qualcosa di cui dovresti preoccuparti, sia ..

Quindi, in breve, ti consiglierei di prendere la strada maestra. Se pensi che non valga il tuo tempo e vuoi riscriverlo a spese del tuo cliente, allora abbandona il lavoro. Seriamente, alla fine, il cliente paga il tuo tempo per far funzionare tutto con la minima quantità di $$$.

In tanti anni di esperienza nel settore, dico sempre che i migliori programmatori che ho incontrato sono quelli che possono rendere stabile un sistema scrivendo la minor quantità di codice , non da riscrivere il tutto .

Modifica: vedo già che la mia risposta non è la più popolare (me l'aspettavo già), ma resto dalla mia risposta. Ho modificato questo per renderlo meno snarky. ; -)

Sicuramente gli attacchi di SQL injection e altri difetti funzionali nell'applicazione hanno avuto la precedenza, ma è anche possibile "dimostrare" cattive qualità e pratiche del codice. Con gli strumenti di metrica del codice è possibile dimostrare chiaramente quanto sia pericoloso il codice e mostrargli quanto questo comporterà costi aggiuntivi per eventuali modifiche future e bug fixing. Non ho familiarità con l'ambiente .net ma sono sicuro che ce ne sono diversi da cui partire.