Qual è il modo migliore per comprendere il codice in un progetto con documentazione nulla?

Naviga le tue risposte
4

È il nostro primo gioco e siamo una start-up. Avevamo un programmatore che all'improvviso sembra essere un peso morto. Anche se lo conoscevamo personalmente, pensavamo che fosse così motivato e quindi non ho mai cercato una recensione o una documentazione del codice. Ora sembra che stia rallentando molto e lo vogliamo fuori.

Ora durante una conversazione ha detto che non avrebbe documentato il codice così da poter dipendere da lui. Ho guardato il codice e non c'è documentazione.

Il codice è dappertutto. Quale sarebbe il modo migliore per capire il suo codice?

Dettagli del codice:

  • Scritto in C # e targeting per piattaforma mobile con Unity3D.
  • La meccanica del gioco e la fotocamera sono gli script sono i principali e non hanno documentazione.
  • Troppi messaggi Invia / Trasmetti quindi non sono in grado di vedere i riferimenti tramite Mono.
  • Ancora un uso pesante delle stringhe nei metodi di richiamo o nel passare parametri
  • Funzione di aggiornamento ovunque che potrebbe essere stata ridotta a coroutine.
  • Il naming è scarso e inconsistet
  • Assolutamente nessun raggruppamento con l'uso di distruzione e istanziazione. Mi aspetto perdite di memoria.

Quali protocolli dovrei adottare per comprendere il codice e lavorarci sopra?

    
posta karsnen 22.04.2013 - 20:14
fonte

5 risposte

6

Ciò di cui hai bisogno sono Test di caratterizzazione .

A characterization test is a test that characterizes the actual behavior of a piece of code. THere's no "Well, it should do this" or "I think it does that." The tests document the actual current behavior of the system. (Feathers, Working Effectively with Legacy Code, 186)

È possibile utilizzare i test di caratterizzazione per sviluppare la documentazione per il codice dopo il fatto. Questo non è il modo preferito per farlo, ovviamente; è meglio scrivere test prima scrivendo codice. Ma quando si ha a che fare con una base di codice legacy (e secondo Feathers una base di codice legacy non deve essere vecchia, una nuova base di codice ha le stesse caratteristiche di una versione antica se non ha test) i test di caratterizzazione sono un grande vantaggio .

Feathers dice (186):

Here is a little algorithm for writing characterization tests:

  1. Use a piece of code in a test harness.

  2. Write an assertion that you know will fail.

  3. Let the failure tell you what the behavior is.

  4. Change the test so that it expects the behavior that the code produces.

  5. Repeat

Si noti che questi test sono diversi dai normali test TDD in quanto non intendono descrivere cosa debba fare il codice base . Descrivono solo ciò che fa -quale è esattamente ciò che vuoi determinare.

Se, naturalmente, trovi che fa qualcosa di sbagliato, ora hai dei test che ti permettono di cambiare questo comportamento con TDD. Puoi cambiare il test per aspettarti che cosa vuoi realmente, quindi correggere il codice finché non lo fa.

Le piume hanno un trattamento abbastanza dettagliato su come scrivere tali test. Discute anche in altre parti del suo libro su come ottenere il codice in un'imbracatura di test in primo luogo (e quindi lo assume al punto # 1 sopra) ma che va oltre lo scopo di questa domanda.

    
risposta data 22.04.2013 - 23:25
fonte
5

Buttalo e ricomincia.

  • È impossibile scrivere codice che altre persone non possono seguire che tu stesso possa seguire. O quello è anche buono. Il codice suona non vale la pena di essere gestito in base alle tue poche righe di descrizione.
  • Sembra il tipo di persona che lascerebbe le bombe logiche. Vuoi disinnescarli?
  • Sembra che tu voglia notevolmente sottovalutare il costo della manutenzione del software.
  • licenziare il dipendente AL PIÙ PRESTO. Ha già espresso la sua opinione che ritiene che il modo migliore per crescere in azienda sia quello di contribuire con il maggior valore possibile. Al momento sta lavorando a valori negativi.
risposta data 22.04.2013 - 23:23
fonte
1

Sembra molto simile a un progetto su cui ho lavorato per un po '. Quando sono stato assunto per il lavoro al quale lavoro attualmente, mi è stata data una cartella sul desktop di una vecchia macchina e ho detto che probabilmente era la versione più recente del codice per un sito web. Nessuna documentazione, copia del codice e incollata ovunque, parte della logica di business nel codice, parte di essa in stored procedure in più database, ecc. Inoltre, la persona che stavo sostituendo era l'unica persona che l'aveva toccata codice in modo che nessuno potesse davvero aiutarmi.

Sto ancora lavorando per portare quel codice su un livello misurabile di sanità mentale, ma questo è ciò che ha funzionato per me.

  • Gioca con il progetto: ho appena fatto un tour attraverso il nostro sito (per fortuna avevamo un ambiente beta su cui avrei potuto farlo senza temere di corrompere i dati, ecc.). Ho fatto clic, ho provato a utilizzare diverse funzionalità, ecc. Ho anche guardato il codice un po 'mentre lo facevo, così ho potuto avere un'idea di cosa fosse e come funzionasse.
  • Risolto un piccolo bug: ho iniziato con alcuni piccoli bug e ho provato a risolverli. Ci è voluto un po 'per risolverli, ma ho acquisito maggiore familiarità con il sistema man mano che procedevo. Dopo un po 'è diventato più facile e più facile trovare le cose e capire il codice. Non è ancora un compito piacevole lavorare sul codice, ma è diventato più facile.
  • Continua a farlo: non è una cosa facile lavorare sul codice senza aiuto, ma diventa più facile.

TL / DR: ottieni un ambiente di test e inizia a risolvere i bug e a giocare con la tua app. Non arrenderti, diventerà più facile.

    
risposta data 22.04.2013 - 23:17
fonte
0

Ciò che I farebbe è sedersi alla tastiera, inventare un problema e provare a risolverlo, ovvero scegliere alcune parti dell'app e provare a modificarla. Non importa molto quello che provi a cambiare: l'atto di scavare in profondità nel codice per fare in modo che il cambiamento ti costringa ad affrontare tutte le cattive pratiche di codifica mentre cerchi di capirle.

Dedicare un sacco di tempo ininterrotto a questa attività, perché avrai bisogno di un po 'di flusso in corso. Probabilmente dovrai destreggiarti tra un sacco di cose finché non capirai tutto. Non prendere alla leggera il problema: ci vorrà molta concentrazione. Accettalo come una sfida professionale e tuffati in testa per primo.

Ho avuto un problema simile una volta, molto, molto tempo fa. Era un codice gnarly di database scritto in fortran, da qualcuno che secondo me conosceva fortran-66. Aveva alcuni bug sgradevoli che avevano eluso parecchie persone. Mi sono tuffato e ho tenuto un registro. Ho scritto i miei pensieri come sono accaduti - "Oh, FOO variabile è sia un locale in questo posto e un mondiale in quel punto", "questa classe non viene mai utilizzato", "questo è talvolta chiamato con tre argomenti, a volte quattro, e il quarto non viene mai usato ", ecc. Questo mi è stato di grande aiuto quando ho scoperto lentamente la follia all'interno.

Mi ci sono voluti alcuni giorni, ma alla fine l'ho risolto.

E parla con un avvocato. Sembra che tu stia ricattando.

    
risposta data 22.04.2013 - 23:04
fonte
-2

molto semplice?
Vorrei solo utilizzare il codice e refactoring / riscrivere parti di esso che necessitano di un cambiamento ogni volta che è necessario.
Non è necessario riscrivere tutto il suo codice se funziona.

Modifica:
Venendo a pensare al fatto che potrebbe essere quel tipo di programmatore,
Potrebbero esserci alcune soluzioni che potrebbero essere poco pratiche, ma potrebbero valerne la pena:
1. un suo ex collega che conosce il suo stile di codifica.
2. Qualcuno che non commenta il suo codice, questo tipo di persone si capiscono meglio.

    
risposta data 22.04.2013 - 20:22
fonte

Leggi altre domande sui tag

Come diventare più constrongvole con i termini tecnici OOP migliore in Javascript: più metodi o metodi con opzioni?