Affrontare un progetto infinito non risolvibile

Io interpreterò l'avvocato del diavolo, avendo visto fin troppo spesso come si rivela: non puoi farcela. Ti garantisco che sei l'unico che vede effettivamente un vero problema con il sistema così com'è, altrimenti non dovresti chiedere come affrontarlo perché la cultura aziendale sarebbe quella di eliminare errori e correggere il codice ove possibile, cioè operando come funzionano i professionisti reali.

Scommetto che è troppo grande per iniziare a scrivere test di unità, perché non ha avuto nessuno che sappia come testare l'unità prima di te (e con fortuna altre persone della tua squadra) ed è impossibile sapere da dove cominciare, e forse anche impossibile da testare perché si basa su implementazioni esatte e dati concreti, quindi ci vorrebbe troppo tempo per spogliarlo a interfacce, mock, stub e simili per poterlo testare in primo luogo. Scommetto anche che non puoi limitarti a fare refactoring su ciò che deve essere refactored perché è troppo stretto e, dal momento che non ci sono test, chissà su cosa verrà risolto correggendo il codice errato. In breve, è probabilmente diventato troppo canceroso per risolverlo seriamente, ma ovviamente non può essere solo tagliato e ricominciare da capo.

Stai combattendo una battaglia persa, amico mio. O ti esaurirai dalla frustrazione e alla fine smetterai o impazzire, o se ti lamenti abbastanza a lungo cercando di convincere gli altri a capire i problemi, penseranno che l'unico problema è tu e tu Ti verrà mostrata la porta.

Le cose di test unitario sono un buon punto di partenza se non ne fai nessuna. Per lo meno ti proteggeranno dall'aggiunta di nuovi bug quando correggi bug vecchi.

Anche il controllo del codice sorgente è utile, a meno che tu non lo stia utilizzando. Le caratteristiche di colpa e registro, in particolare, sono meravigliose per capire come / perché un pezzo di codice bacato sia mai stato commesso.

Dal punto di vista del cliente, ho scoperto che discutere dei prezzi e dei (lunghi) ritardi non appena le modifiche / funzionalità aggiuntive sono richieste funziona in modo ragionevolmente buono, così come fa pagare per il tempo che passi a discutere / progettarle. Spesso i clienti decidono che, a pensarci due volte, possono aspettare.

(Al contrario, se inizi a scavare direttamente nelle specifiche e nelle idee di implementazione con lui, in genere ti preparano per un "oh, pensavo fossimo d'accordo che lo avresti fatto comunque" o (peggio, dopo diversi giorni di avanti e indietro sulle specifiche) "ma guarda, è già stato progettato e noi quello che abbiamo discusso non sembra così difficile!".)

Ultimo ma non meno importante, ho scoperto che essere onesto che leggo solo e-mail una volta al giorno (all'arrivo al lavoro), e che ho un telefono per qualcosa di più urgente, porta ad un enorme aumento della produttività.

Suggerisco di aggiungere alcuni test basati su CI, principalmente sulle aree che si interrompono più frequentemente. Ciò ti aiuterà ad aumentare la qualità man mano che il lavoro viene svolto sul progetto.

Diventa anche più evidente quali aree / funzionalità si interrompono più spesso e quindi è più facile decidere quali parti necessitano di refactoring, o almeno di aumentare i test.

Aggiungere più test manuali rischia di far fallire il progetto in termini di $$$ & tempo richiesto per funzionalità aggiunta.

Qualche revisione del codice è buona, ma forse è parte dello schema di test A- > B- > C- > A- > (Forse la revisione del codice nella direzione opposta?)

Lascia che ti lanci una favola. Stavi facendo una passeggiata con una persona all'inizio della giornata in fondo alla strada e raggiungi la tua destinazione. La persona con cui stai camminando scopre rapidamente che ha perso il suo anello da qualche parte lungo la strada in modo che entrambi decidiate di tornare indietro e andare a cercarlo. La persona con cui stai camminando si ferma rapidamente a un lampione e inizia a cercare freneticamente. Dici: "Perché guardi lì al lampione quando penso che potresti averlo perso quando avremo tagliato il vicolo?". Risponde: "Lo so, ma qui la luce è migliore."

Sono stato in questa situazione più di alcune volte e ho notato alcuni punti in comune. Questi tipi di progetti di incubo di manutenzione sono generalmente eseguiti in un ambiente pesante con pesanti supervisioni e miglioramenti dei processi imposti dalla gestione. Non sto dicendo che i miglioramenti del processo siano una cosa negativa, ma il più delle volte i tipi di miglioramenti del processo che la Gestione in genere vorrà mettere in atto hanno due punti chiave.

1) Generalmente non interrompono la politica dell'ufficio e l'equilibrio del potere. 2) Hanno successo nel creare l'illusione del controllo da parte del management piuttosto che colpire al centro del problema.

Il concetto di "la luce è meglio qui" tipicamente va in giro dicendo: "Ogni nuova funzione deve avere una specifica tecnica dettagliata" oppure "Ogni ora ha una riunione sullo stato orario per discutere dei problemi e come superarli".

Nessuna di queste cose colpisce il cuore dei problemi e potrebbe solo ridurre la produttività, ma certamente convalida l'illusione del controllo da parte della direzione.

Gli unici veri cambiamenti che puoi aiutare a spingere sarebbero quelli che scuotono le cose. Sospetto però che la tua mostruosità di un sito web sia probabilmente irreparabile a questo punto e che tu sia più avanti nel ricostruire e riscrivere. Per il futuro, tuttavia, è possibile tenere presente l'importanza della metodologia Agile, dell'integrazione continua, dello sviluppo basato sui test, delle recensioni dei codici e delle specifiche dei requisiti aziendali che sono regolate in base a rigorose procedure di controllo delle modifiche per ridurre al minimo l'oscillazione dell'ambito. p>

Questo tipo di cambiamenti richiede davvero un cambiamento nel modo di pensare a livello di gestione e in tutta la mia esperienza professionale non ho mai riscontrato che ciò avvenga senza una sorta di scuotimento a livello di middle management. Spero che non sia troppo scoraggiante come dovresti provare per quello che è giusto, indipendentemente se stai combattendo una battaglia in salita, perché probabilmente incontrerai una fiera resistenza da parte di persone che amano lo status quo.

Sono stato nello stesso posto qualche tempo fa. Non sono più grazie a due semplici regole:

• Ogni settimana uno o due giorni vengono utilizzati per correggere / riscrivere la maggior parte delle parti pelose dell'app. Nessuna ricerca di bug, nessun nuovo sviluppo di funzionalità.
• Durante l'implementazione di nuove funzionalità, ci impegniamo a farlo bene anche quando impieghiamo più tempo del previsto.

L'unico problema è convincere le altre persone a rispettarle. La parte facile è stata sorprendentemente cliente. Non so davvero spiegare perché, ma in qualche modo lo abbiamo convinto, che quando lavoriamo su un film un po 'più lungo è meglio per tutti. Rispettare la prima regola si rivela più problematica, ma riteniamo che ci aiuti molto. Garantisce progressi costanti in quanto le diverse parti dell'applicazione stanno migliorando.

Recensioni del codice. Test unitari Test del QA reale. Processo di raccolta delle specifiche e sviluppo incrementale: queste sono alcune cose che dovrebbero risolvere la maggior parte dei tuoi problemi.

Inoltre, non lasciare che i clienti facciano direttamente il ping ai tuoi sviluppatori: questo è solitamente il modo più improduttivo per risolvere i problemi. Assumi un buon Program manager che formerà l'interfaccia tra i tuoi clienti e sviluppatori. Il suo compito sarebbe quello di conoscere il prodotto end-to-end, lo stato attuale, le direzioni future e così via. Ogni volta che il cliente desidera un'altra nuova funzionalità, dovrebbe essere in grado di fornire l'elenco corrente di articoli e mostrare ai clienti cosa verrà scocciato se questa nuova richiesta verrà presa.

Il processo è cattivo quando è usato troppo poco o troppo. Penso che tu sia allo stato precedente.

Come menziona Deni, se sei in grado di aggiungere test di unità al progetto, allora questo ti aiuterà. Esegui un test che copra una parte del sistema che stai per modificare / correggere, quindi quando utilizzi il codice di refactoring, usa quel test come guida per assicurarti di non rompere nulla.

Inoltre, triage le parti più spezzate del codice. Cerca di mettere i peggiori colpiti in una lista di rischi e gestirli autonomamente. Cerca di farti un'idea di quanto codice ci sia nella base di codice interrogando dove si trovano di solito gli errori. Puoi quindi elencare l'area interessata in base al conteggio dei bug (o ai problemi segnalati, qualunque cosa funzioni per te.).

L'installazione e la pulizia del codice richiederanno del tempo, ma se ogni sviluppatore del team può lasciare il codice un po 'più pulito di quanto non lo fosse prima, nel tempo il codebase migliorerà. Se stai cercando uno stile rapido e militare, risolvi la soluzione ora, dubito che ci sia qualcosa di pratico (o consigliato) che possa aiutarti.

Saluti. Giac.

Scrivi specifiche funzionali chiare; pedante quindi se puoi sopportarlo e rivedere regolarmente la funzionalità rispetto a quelle specifiche. Meno un'idea di un dev ha su ciò che si suppone stia sviluppando, meno possibilità ci sono di come si suppone che sviluppi.

Prima di iniziare a scrivere il codice, fai un po 'di lavoro di progettazione frontale; questo non ha bisogno di essere perfetto, o enorme, o contenere UML, ma dovrebbe delineare una soluzione abbastanza solida al problema che deve essere risolto. Per quanto posso dire, meno software è pianificato, peggio è. Discutere il progetto prima di iniziare a lavorarci.

Quando inizi a lavorare su un'area del codice che è chiaramente negativa e ostacola davvero i tuoi progressi; smettila di aggiungerlo, fai un passo indietro dal problema, scopri come potresti ridisegnare l'architettura in modo che gli impedimenti non esistessero e in modo che fosse più adattabile in futuro. Più a lungo lo lasci prima di affrontare il debito tecnico, più difficile sarà affrontarlo senza una completa riscrittura. Direi che è una cosa esponenziale.

I test di progettazione che testano comportamento e non si accoppiano strettamente alla tua architettura. Non è molto alla moda, ma direi che non iniziare i test fino a quando il vero scopo del tuo codice non è chiaro. In particolare, non iniziare i test fino a quando non sai cosa vuoi veramente testare; IMO un test mal concepito è peggio di nessun test. E più test hai più difficile è quello di cambiare il tuo codice internamente. Tratta il tuo codice di prova come faresti con il codice di produzione; deve essere pianificato e ben scritto.

Esegui revisioni periodiche / periodiche del codice: questo è più che altro per quanto riguarda il controllo dell'igiene per assicurarsi che lo sviluppatore non sia andato troppo lontano. Usa queste sessioni per pianificare il lavoro nei prossimi giorni. Potrebbero esserci giorni in cui questi richiedono 5 minuti o 1 ora; il punto è mantenere aperto il dialogo e dare agli sviluppatori la possibilità di discutere del loro lavoro con altri sviluppatori e di chiedere consiglio. Fai delle sessioni di abbinamento su parti difficili del codice o per creare prototipi di idee, ma lascia che le persone abbiano il loro tempo libero per lavorare.

Semplifica la creazione e l'implementazione del tuo codice. Cerca di mantenere i tempi di costruzione brevi. Più è facile costruire più sarà costruito, più è veloce più sarà costruito.

Adotta gli standard di codifica e applicali rigidamente. Questo dovrebbe riguardare tutto da dove un progetto dovrebbe vivere nel file system al case di un const privato. Questo potrebbe sembrare inutile e fastidioso, ma le buone abitudini sono la pietra angolare di un processo di sviluppo.

Fondamentalmente non penso che il processo che usi sia così importante, le mode vanno e vengono. Ciò che conta davvero è che tu sia professionale su come sviluppi software e che sei disciplinato nella tua pratica.

Inizerei progettando e automatizzando i test del fumo e lanciandoli nell'ambiente CI. Quelli dovrebbero essere funzionali Quando il cliente ti dice che qualcosa dovrebbe funzionare così e così, chiedi di annotarlo, in modo che tu possa fare riferimento ad esso più tardi. Quando vedi una certa soluzione nel software, fai domande e non appena ricevi le risposte, inseriscile nella knowledge base e rendili tracciabili.

Assicurati che la funzionalità di base per i casi positivi funzioni. Quindi iniziare a costruire test incrementali per la gestione dei dati errati, inserendo i difetti laddove ritenuto necessario. Avere una discussione lunga e approfondita sulle priorità e far sì che il responsabile dei test ne sia a conoscenza, in modo da poter assegnare i tempi di prova di conseguenza. Non tentare di automatizzare tutto, ma non appena alcuni testicoli hanno senso essere automatizzati, non esitare.

In generale, utilizzare i test per aumentare la fiducia nel prodotto e non come lo strumento che aumenterà istantaneamente la qualità. Sii calmo, ma assertivo :). Forse provare ad andare agile, ma solo se tu, in modo assolutamente positivo, puoi coinvolgere un PM certificato. Introdurre Agile da una persona che non conosce Agile, molto probabilmente ucciderà il progetto.