Come gestire un TODO in una richiesta pull?

Quando rivedo le modifiche in una richiesta pull, a volte mi imbatto in un commento con una nota "TODO" che può essere lì per diversi motivi, nel nostro caso principalmente a causa di:

• la soluzione utilizzata per risolvere un problema può essere migliorata ma richiederebbe molto più tempo per gli investimenti. Un autore ha scelto una soluzione più rapida ma ha commentato che è potenzialmente disponibile un'opzione migliore
• esiste un codice temporaneo per risolvere un bug esistente che dovrebbe essere risolto presto

Sapendo che TODOgeneralmente rimangono nella base di codice per tutta la durata della base di codice, come devo reagire a loro in una richiesta pull? Come posso cortesemente richiedere di evitarlo, o se è veramente giustificato, come posso assicurarmi che l'autore del PR lo seguirà più avanti in futuro?

Quando dici che "rimangono generalmente nella base di codice per tutta la durata della base di codice" nel tuo team / dipartimento / organizzazione, considera quanto segue:

• Scriverlo nel Dipartimento della Difesa che TODO, FIXMEo tag simili dovrebbero essere evitati.
• Utilizzare uno strumento di analisi del codice statico come SonarQube per contrassegnare automaticamente la build instabile.
• Consentili temporaneamente se, e solo se, è presente un ticket corrispondente nel tracker dei problemi. Quindi, il codice potrebbe apparire comeTODO [ID-123] Description ...

Come menzionato nel mio commento , l'ultima affermazione probabilmente ha senso solo in un ambiente che non lascia marcire i biglietti (ad esempio se segui una politica a zero bug ).

Personalmente, penso TODOche a volte siano ragionevoli, ma non si dovrebbero usare eccessivamente. Tratto da "Clean Code: A Hand of Agile Software Craftsrafts" (p. 59) di Robert C. Martin :

TODOsono lavori che il programmatore pensa dovrebbero essere fatti, ma per qualche ragione non può fare al momento. Potrebbe essere un promemoria per eliminare una funzione obsoleta o un appello affinché qualcun altro osservi un problema. Potrebbe essere una richiesta per qualcun altro di pensare a un nome migliore o un promemoria per apportare una modifica che dipende da un evento pianificato. Qualsiasi altra cosa una TODOpotrebbe essere, è non è una scusa per lasciare codice cattivo nel sistema.

Gli stessi TODO non sono cattivi. Sono un grande fan di non andare mai più in profondità di uno strato e risolvere sempre 1 problema per ticket tracker.

Uso spesso TODO o FIXME come un modo per ricordare a me stesso che avevo bisogno o che volevo tornare per risolvere un problema.

Ad esempio, posso chiamare add (a, b) e aggiungere un TODO per riformattare il metodo add. Non voglio lavorare sul metodo add ora, ma voglio tornare su di esso.

Quindi in una richiesta pull vedrai TODO o FIXME. Uso FIXME per esempio per avvisare gli altri sviluppatori di aree di codice di cui hanno la responsabilità, che non dovrei confondere. Ad esempio, l'aggiunta di FIXME non può accettare numeri negativi.

Per ovviare al problema di non essere visti o ignorati, uso uno script che elenca tutte le righe TODO FIXME e DEGUG. E questo viene aggiunto al messaggio di commit.

È difficile ignorare un messaggio di commit a 400 righe che è tutto TODO. Quindi le persone li risolvono, sia già toccando il codice in questione o creando nuovi ticket e risolvendo il codice problema autonomo.

Per essere onesti, mi assicuro anche che ogni progetto abbia un tempo di pulizia del codice integrato. Sì, si può essere pronti per il lancio il 15, ma stavano facendo la pulizia del codice dal 15 al 30. (sembra strano ma se hai mai gestito un prodotto, sai che se provi ad avere attività a bassa visibilità prima del lancio, non ti sarà mai permesso di raggiungerli. Qualcos'altro avrà la priorità.)

Accadrà che ci sono richieste pull che non sono perfette. In questo momento sto facendo un lavoro che può essere svolto "abbastanza bene" nel tempo disponibile, ma non perfetto. Quindi invio una richiesta pull, inserisco TODO con i commenti nei punti giusti nel codice e allo stesso tempo aggiungo un'altra richiesta di modifica per cambiare le cose da "abbastanza buono" a "perfetto".

A questa nuova richiesta di modifica può quindi essere assegnata la priorità e verrà gestita quando si tratta dell'elemento con la priorità più alta. Se si decide che deve essere perfetto in questo momento , allora sarà la prossima cosa consegnata.

Ora la tua domanda: "Come posso cortesemente richiedere di evitarlo, o se è veramente giustificato, come posso assicurarmi che l'autore del PR lo seguirà più avanti in futuro?" Con quello che descrivo, sembra essere piuttosto stupido. Se ho la scelta tra la spedizione in ritardo e la spedizione di ciò che è abbastanza buono, non è una tua decisione da prendere. Se lo desideri, puoi chiedere al responsabile del prodotto. E "assicurati che l'autore del PR lo segua"? Se hai un team, dovresti assicurarti che questo sia registrato nei tuoi sistemi e, si spera, il tuo team è abbastanza ben organizzato da non perdere le cose registrate, e qualcuno lo risolverà alla fine, quando non ci sono elementi con priorità più alta. Ricorda, è uno sforzo di squadra.

Se il tuo progetto tiene traccia degli articoli in sospeso nel codice sorgente con TODOcommenti, allora devi permetterlo.

Il fatto che la presenza di un TODOcommento nella richiesta pull stia disturbando dovrebbe dirti che tenere traccia degli elementi in sospeso nel codice sorgente è una cattiva idea. Le cose tendono a perdersi o essere ignorate in quel modo. Ora, se stai parlando di una richiesta pull a un "fork di lavoro", la situazione è diversa. Un "fork di lavoro" è proprio questo: un lavoro in corso. Ma una forcella del genere di solito non richiede una richiesta pull. Le "Regole della casa" qui suggerite sono per le richieste pull per il ramo principale .

Regola n. 1 della casa - Tutti i commit per il master devono essere pronti per il test, poiché il master viene creato ogni giorno dopo ogni check-in. Tali impegni dovrebbero includere anche eventuali test aggiuntivi richiesti.

Se la TODO commento è presente perché il codice non è terminato o i test non sono finiti o il codice non è in alcun modo pronto per il test, quel codice appartiene a un commit locale, non a una richiesta pull. Chiamami quando è pronto.

Regola n. 2: tutte le informazioni relative ai problemi aperti vengono archiviate nel tracker dei problemi. Tutto. Note, scarabocchi, intuizioni, qualunque cosa.

Se la TODO commento riguarda un problema aperto e non è una soluzione effettiva per quel problema, tali informazioni appartengono al tracker del problema. In questo modo, prima della chiusura di un problema, è possibile rivedere e verificare tutte le informazioni, se necessario, per assicurarsi che il problema sia effettivamente risolto.

Regola n. 3: tutte le informazioni relative alle attività di progetto in sospeso appartengono alla coda prioritaria (o qualunque sia il nome del sistema per quello).

Per chiarimenti, un'attività di progetto in sospeso è qualcosa che deve essere fatto nel progetto che ha una priorità prefissata, sia che si tratti di un difetto scoperto prima che generasse un ticket di emissione o dell'implementazione di un requisito di progettazione specifico, sia di uno dei componenti necessari di tale requisito.

Se la TODO commento è lì per dire che il nuovo codice avrà un impatto su un'attività in sospeso o per indicare qualcos'altro nella base di codice che deve essere esaminato che è stato scoperto durante l'implementazione del nuovo codice, allora quelle informazioni appartengono alla coda prioritaria, sia su l'attività esistente o come nuova.

Regola n. 4 della casa - I suggerimenti appartengono alla Idea Box (o qualsiasi altra cosa).

Se la TODO commento suggerisce un cambiamento nella progettazione o nell'implementazione del software, tali informazioni appartengono al riquadro delle idee del progetto, o "vNext", o "Design Notes", o qualsiasi altra cosa tu abbia per quel genere di cose.

Regola n. 5: i TODOcommenti non sono consentiti nel codice sorgente. PERIODO.

Se ti attieni a questa regola, non dovrai preoccuparti che nessuno segua nulla.