Ho iniziato a lavorare in un'azienda poco tempo fa e quello che vedo molto all'interno di un progetto è una quantità elevata di codice di bassa qualità e alcune idee personalizzate al posto degli standard del settore e delle best practice selezionate.
Ma quando cerco di parlarne con il manager, vedo spesso le risposte, che i ragazzi che lo fanno fanno le cose in fretta e sono brave ecc. ecc. ecc.
Questo è fondamentalmente un problema culturale. Prima di tutto, fai attenzione a pensare che puoi "dimostrare" che una diversa metodologia è migliore. Con il tempo e l'esperienza, farai meglio a "convincere" i tuoi colleghi sulle migliori pratiche.
Il problema è che le persone in un negozio sviluppano certe abitudini e arrivano a certe comprensioni condivise e si sentono piuttosto a loro agio. Sperimentano "bias di conferma", in cui le loro esperienze confermano le loro cattive pratiche ("L'ho scritto veramente veloce e sporco, e siamo ancora spediti in tempo!") E prove di sconto che contraddicono le loro convinzioni ("Ho passato tre settimane su quell'errore , ma ora sto passando al nuovo codice. ")
La mia esperienza è che i negozi con cattive pratiche sono particolarmente resistenti alle buone pratiche. Il motivo per cui il negozio ha optato per le cattive pratiche in primo luogo è che non erano interessati alle alternative.
All'altro estremo, ho lavorato in negozi che erano così intelligenti e aperti a nuove idee, che è diventato folle perché l'infrastruttura era così dinamica anche di settimana in settimana, era difficile dire come scrivere codice e rilasciarlo (sono attualmente in una situazione in cui ho aspettato un mese per una scatola di controllo qualità, ma hanno appena riprogettato il flusso di lavoro per il check-in del codice, quindi sono tornato al punto di partenza, senza scatola QA o forse quadrata -1.)
Mentre stai in un negozio e man mano che acquisisci responsabilità, avrai sempre più influenza sulla cultura. Dopotutto, il ragazzo seduto alla tastiera alla fine prende molte decisioni. Ma sarà un lungo processo di identificazione di cose specifiche che potrebbero essere migliorate, e sia modificandole individualmente da soli, sia educando e persuadendo gli altri a seguire un modo migliore.
...
... o, dovrei aggiungere, trasferirmi in un altro negozio. In questo settore, a volte l'erba è decisamente più verde dall'altra parte.
Nel caso del refactoring, ad esempio: il refactoring richiede tempo. Il tempo costa denaro. Pertanto, il refactoring è utile solo se si ottengono benefici che superano il costo di refactoring.
Subito dopo aver creato una soluzione di tipo lavorativo, questo è il momento in cui il refactoring è più economico (perché conosci il codice dentro e fuori in quel punto), e può dare benefici immediati se refactoring rende i bug visibili e il debugging più facile, in modo da ottenere un codice privo di bug più veloce.
L'altro momento in cui il refactoring è utile è poco prima o mentre si devono apportare comunque delle modifiche, se il codice esistente è sufficientemente cattivo, ed è più economico trasformare il codice errato in un buon codice e modificare un buon codice piuttosto che cercare di capire male codice e modificarlo.
Il codice di refactoring che nessuno guarda è inutile.
Leggi altre domande sui tag project-management programming-practices