Come mantieni i pattern (anti) del software organizzati? [chiuso]

In effetti, posso confermare questi stessi problemi nel mio lavoro. Sfortunatamente, non posso affermare di aver trovato la soluzione , ma almeno sono arrivato a un punto in cui non mi dà più fastidio. Ecco alcune idee che aiutano a mitigare questi problemi:

• Come Basile ha menzionato nel suo commento, è importante lasciare gli URL come commenti per tutti i tipi di codici che dovevi cercare altrove. Si noti tuttavia che questi luoghi sono piuttosto rari. Non puoi semplicemente copiare il codice postale del blog nel codice di produzione (solo i problemi legali dovrebbero fermarti lì, la qualità e altri argomenti simili sono disponibili in seguito). Quindi, il più delle volte, è più simile a un'idea elegante, che viene spiegata in modo più approfondito nel post del blog o nella risposta StackOverflow. Anche questo si collega al punto successivo, quindi in pratica questi commenti aiutano ancora meno.

• ASCIUGA . Respira. Vivilo. Non essere ripetitivo! Quando ti rendi conto che la nuova funzionalità su cui stai lavorando è simile a qualcos'altro, allora devi cercarla e eliminare ogni duplicazione nel miglior modo possibile. A lungo termine, questo limita strongmente il numero di punti nel codice che dovresti cercare.

• Probabilmente il modo più semplice e più facile per gestirlo è quello di esternalizzarlo. Non in qualche altro paese, ma per i membri del tuo team! Quando ti viene in mente questo nuovo fantastico schema, vai a raccontarlo a qualcuno! Mai e poi mai tenerlo per te, perché tu sei quello che deve ricordarlo. Se vedi qualcuno che scrive un Anti-pattern - diglielo, non aggiustare il problema! Oltre a trasferire le tue conoscenze ai membri del team, le recensioni ti aiutano a trarre profitto dalle tue conoscenze precedentemente esternalizzate. Le persone hanno anche diversi skillset. Alcuni hanno una buona memoria. Spesso è più preciso e veloce di Google, perché ha una conoscenza completa del tuo progetto. Usalo! È una vittoria per tutti nel team.

• Il rilevamento dei problemi con la tracciabilità è particolarmente utile per gestire gli errori. Se hai un problema dall'ultima volta in cui hai risolto questo errore, il tuo sistema di tracciamento dei problemi dovrebbe essere in grado di trovarlo per te (da uno stacktrace, un messaggio di errore, qualunque cosa - ma in qualche modo deve essere nella descrizione del ticket ovviamente). Poi viene la tracciabilità, cioè dato il tuo biglietto dovresti avere un modo per trovare rapidamente la parte del tuo codice che ha affrontato quel problema la prima volta. Non molto google o blog-reading lasciato davvero. Ciò si ricollega anche al controllo della versione, in quanto è possibile trovare rapidamente il changeset corrispondente quando si conosce la parte del codice ("la colpa") o quando i commit fanno riferimento al numero del problema.