Come gestisci il codice intenzionalmente errato?

21

Ci sono molte storie sul codice intenzionalmente cattivo, non solo su TheDailyWTF ma anche su SO. I casi tipici includono:

Avere un costrutto inutile che fa perdere tempo (ad esempio un ciclo vuoto che conta un valore enorme) in modo che i programmatori possano facilmente "accelerare" l'applicazione rimuovendola quando gli viene assegnato il compito.
Fornire documentazione intenzionalmente fuorviante, errata o assente per generare costose richieste di supporto.
Generare prontamente errori, o peggio, generare anche se tutto ha funzionato bene, bloccando l'applicazione, quindi per sbloccare è necessaria una costosa chiamata di supporto.

Questi punti mostrano un atteggiamento più o meno malizioso (anche se a volte per caso), specialmente il primo punto si presenta piuttosto spesso.

Come si dovrebbero affrontare tali costrutti? Ignorare il problema o rimuovere semplicemente il codice offensivo? Avvisare il proprio responsabile o parlare con la persona che ha introdotto la "funzione"?

bad-code

— Mafu
fonte

10

È "a volte per caso" o "intenzionalmente cattivo"? Non vedo come possano essere entrambi.

7

Il codice più cattivo è dovuto alla mancanza di comprensione e la soluzione è l'educazione.

Il codice intenzionalmente errato è completamente diverso, a causa di qualcosa di completamente estraneo all'esperienza del programmatore o al resto del progetto. Come tale, devi scoprire perché stanno sabotando il codice di proposito e affrontare questo problema. Ciò significa, più spesso allora, politiche d'ufficio, e raramente è una situazione piacevole per chiunque.

Il modo in cui gestirò la parte politica dipende da molte circostanze (non dichiarate sopra). Il modo in cui gestirò il codice è innanzitutto assicurarsi che non sia l'unico malinteso - che è davvero un codice errato - quindi correggere le ovvie carenze. Se ragionevolmente possibile, scrivere i test che il codice errato fallirà. Ricontrollare che ho capito correttamente significherebbe parlare con la persona che ha scritto il codice. Ciò dovrebbe essere fatto in un modo molto gentile ed educato, senza assumere intenti, e può aiutare a trovare la ragione (politica) sottostante necessaria in seguito.

La spedizione è più importante della perfezione della torre d'avorio, ma ci sono due punti che vale la pena affrontare. Risolvere ovvie carenze ti dà l'80% dei risultati con il 20% dello sforzo, e quel tipo di frutto a bassa pendenza raramente merita di essere ignorato. Ma ancora più importante, se non si affronta la ragione (politica) di fondo, è probabile che venga scritto un codice più intenzionalmente cattivo e che causi ulteriori problemi e possibilmente impedisca la spedizione.

28

Non ho mai (in 20 anni dispari) trovato intenzionalmente codice errato, ma gli esempi che citi sembrano (almeno per me, ma IANAL) essere tentativi di frodare un datore di lavoro o un cliente, quindi probabilmente hai un legale obbligo di segnalarlo al proprio responsabile.

— gkrogers
fonte

2

Concordato. Nessuno scrive intenzionalmente codice errato. Stanno risolvendo un problema e lo stanno risolvendo nel modo migliore che conoscono. Possono essere fuorviati, scarsamente istruiti, ignoranti, ecc. Ma non riesco davvero a capire uno sviluppatore che scriva intenzionalmente qualcosa che sanno essere cattivo.

— Dan Ray,

8

Anche se non legale, almeno esiste un obbligo etico.

— Chris Farmer,

@ChrisFarmer Non puoi separare l'obbligo etico dal contesto più ampio - ci sono alcuni contesti in cui un codice deliberatamente negativo rappresenta una legittima resistenza collettiva, sia economica che politica. (E un contratto di lavoro merita di essere onorato in buona fede solo quando la relazione che formalizza non è sfruttatrice individualmente o strutturalmente.)

— user234461

11

Dipende dalla cultura dell'azienda. Più spesso, semplicemente non è il tuo lavoro riparare e ripulire tutto il codice errato.

Da Coders at Work , il pensiero di Jamie Zawinski sull'ingegneria genetica , che può essere applicato anche in questa situazione:

Alla fine della giornata, spedisci il cazzo di cosa! È fantastico riscrivere il tuo codice e renderlo più pulito e per la terza volta sarà davvero carino. Ma non è questo il punto: non sei qui per scrivere codice; sei qui per spedire prodotti.

Ci sono molti programmatori e codici cattivi là fuori, e il semplice tentativo di risolverli tutti quando lo si incontra, a spese del progetto / attività corrente, potrebbe semplicemente non valerne la pena se il prodotto "funziona". Troppo spesso siamo solo programmatori di nastri isolanti.

Vedi anche il post di Joel Spolsky: The Duct Tape Programmer

— Spong
fonte

+1 Sono davvero un fan del concetto di spedizione dei prodotti. Penso che a troppi profili tecnici manchi proprio questo concetto.

+1 Anche io. Ci sono troppi tipi di libri "Clean code" ecc. Che sostengono una visione distorta di ciò che è importante. La qualità del codice è solo così importante. I vincitori non sono quelli che hanno il miglior prodotto. Sono quelli che hanno un prodotto abbastanza buono spedito abbastanza velocemente.

— Joonas Pulakka,

4

Penso che ti sia sfuggito il punto della domanda: il ragazzo ha parlato di codice intenzionalmente errato , non semplicemente di codice scritto da programmatori inadeguati.

— Hila,

@Hila Credo che il mio punto valga ancora se il cattivo codice era intenzionale o no. A meno che non sia un problema presente nell'elenco progetti / attività assegnato, non è responsabilità di un programmatore di nastri isolanti riparare e pulire tutto il codice errato . La cultura là fuori non è accademica e scrivere codice pulito / bello. Si tratta di spedire e supportare un prodotto / azienda. Personalmente mi piacerebbe correggere tutto il codice errato che trovo, ma non posso dedicare il 100% del mio tempo a quello - semplicemente non sarei mai in grado di completare l'attività / progetto assegnato a me in quel momento.

— spong

3

@sunpech Ma pulire intenzionalmente un codice errato non equivale a pulire qualsiasi codice. Non si tratta di rendere la tua applicazione più "bella", si tratta di riparare codice dannoso che è stato messo lì apposta. È come dire che un medico non dovrebbe togliere le forbici dimenticate da un collega all'interno di un paziente perché un intervento cardiotoracico riguarda il salvataggio e non la bellezza dei punti.

— Hila,

4

Questo atteggiamento è il sintomo di qualcosa di peggio.

Il management incoraggia la concorrenza degli sviluppatori?
Dov'è lo spirito di squadra?
I compiti sono assegnati da qualcun altro oltre al team stesso?
...

In ogni caso, la rimozione del codice offensivo non è sufficiente. Lamentarsi con il suo manager non aiuterà certamente a migliorare lo spirito di squadra.

Vorrei provare a parlare direttamente con la persona e cercare di capire perché ponendo molte domande senza giudicarlo. L'intero team deve farlo senza aggressività.

Nella maggior parte dei casi, quel comportamento costruttivo mette in luce il vero problema (il peggiore), e quindi puoi lavorarci sopra.

Se davvero non funziona. Rimuovi quello sviluppatore dal team.

4

Se pensassi che fosse intenzionale, probabilmente licenzierei il ragazzo! Se il risultato è che qualcuno non è un programmatore abbastanza bravo, lavorerei sulle sue capacità. Se venisse spinto dall'alto, probabilmente inizierei a cercare un nuovo lavoro.

— Zachary K
fonte

2

Come si dovrebbero affrontare tali costrutti? Ignorare il problema o rimuovere semplicemente il codice offensivo? Avvisare il proprio responsabile o parlare con la persona che ha introdotto la "funzione"?

A seconda del contesto, uno di questi potrebbe essere il più appropriato. Altre possibilità includono, chiedere di trasferirsi in un altro progetto, ottenere un nuovo lavoro e vari atti di moralità e / o legalità discutibili.

Tuttavia, dato che non conosciamo i fatti reali e le persone reali coinvolte, non c'è modo che qualcuno nella posizione che stai descrivendo dovrebbe prestare molta attenzione ai nostri consigli / valore di 2 centesimi.

Se questa è una situazione reale di cui stai parlando, potrebbe valere la pena parlare con il tuo manager in silenzio , chiedendo loro consigli su cosa dovresti fare. Se possibile, prova a parlare di ciò che puoi / dovresti fare, non di puntare il dito. Se possibile, non nominare i nomi. C'è una buona probabilità che il tuo manager abbia già una vaga idea del problema.

Ma il rovescio della medaglia è che potresti soffiare questo sproporzionato. Pensaci a lungo prima di fare qualsiasi cosa. Pensa alle conseguenze, inclusa la possibilità che qualsiasi passo intrapreso possa ritorcersi contro di te ... male.

— Stephen C
fonte