Penso che potresti dover ricordare che l'obiettivo della tua azienda non è probabilmente quello di generare codice bello o perfetto. Personalmente, ritengo che gli standard di codifica (soprattutto quelli rigorosi) siano più uno strumento di microgestione che un utile contributo alla qualità dell'applicazione. Nella maggior parte delle situazioni, gli standard di codifica dovrebbero essere estremamente minimi.
Ad esempio, quelli che sostengono che avere uno standard per stabilire se la parentesi graffa di apertura vada su una nuova riga in qualche modo aumenta la leggibilità del codice in qualche modo sciocco. La coerenza è buona, sembra carina, ma puoi davvero sostenere che in realtà crei un valore aggiunto per l'organizzazione?
Per quanto riguarda il refactoring: questa è solo una di quelle cose che è semplicemente meglio chiedere il perdono che il permesso. Ti impediscono attivamente di refactoring mentre vai avanti? Veramente? Spesso vedo sviluppatori in attesa di una tavoletta di pietra dalla cima della montagna per impiegare buone pratiche di codifica come il refactoring quando hanno solo bisogno di andare a farlo. Se il tuo capo sta guardando da dietro le spalle e schiaffeggia la parte posteriore della testa quando sembra che tu possa essere refactoring, ALLORA potrebbe esserci un problema. Raramente ho visto un negozio, però, che i programmatori non hanno abbastanza autonomia per farlo da soli. Ricorda solo di includere il tempo nelle stime.
Test delle unità: se la mancanza di test delle unità stava creando problemi di qualità, allora non penso che sarebbe difficile venderli al tuo capo. Se non lo è, allora perché ti lamenti? Basta suggerirlo, creare il tuo caso e andare avanti con la tua vita.
La linea di fondo è che dovrai fare il tuo caso in termini di bottom line per l'azienda. Tutte le cose che suggerisci sono solo un mezzo per raggiungere un fine, e quella fine è un'applicazione di qualità sufficiente per soddisfare le esigenze degli utenti. Se non riesci a trovare una giustificazione in termini di problemi con le versioni correnti (qualità o tempo di consegna), potresti considerare che sei ossessionato dai tuoi strumenti invece del prodotto di lavoro. Se è POSSIBILE trovare giustificazioni in termini di risultati finali, basta puntare a quei reclami e al loro costo per l'azienda e legarli a qualsiasi pratica di codifica che si possa offrire per rimediarli.
In conclusione: non cercare di trasformare il tuo problema nel problema del tuo capo. Prendi uno dei suoi problemi e spiega come risolverli con le migliori pratiche.