Come tieni traccia di quali classi e funzioni ha scritto il tuo team?

43

Quando si lavora sul codice, affronterò molte delle stesse sfide che i miei compagni di squadra fanno, e ho scritto alcune funzioni e classi utili, e così anche loro. Se c'è una buona comunicazione, sentirò parlare di una cosa grandiosa che qualcuno ha messo insieme, e sei mesi dopo, quando ne ho bisogno, potrei ricordarlo e chiamare quella funzione, risparmiando tempo. Se non lo ricordo, o non lo sapessi mai, probabilmente reinventerò la ruota.

C'è una particolare pratica nel documentare questo tipo di cose? Come puoi renderli facili da trovare?

Se la tua squadra non ha tale documentazione, come fai a sapere se la tua ruota esiste già?

Modifica

Tutte tranne una delle risposte finora si occupa di una situazione ideale, quindi riassumiamo queste soluzioni: documentazione e amp; comunicazione; wiki, incontri di stand-up, ecc. Sono tutte cose grandiose, ma si basano su programmatori che hanno il tempo (e le competenze) per scrivere la documentazione e partecipare alle riunioni e prendere appunti e ricordare tutto.

La risposta più popolare finora (Caleb's) è l'unica che potrebbe essere utilizzata da un programmatore che è incapace di documentazione e riunioni, e fa solo una cosa: la programmazione. La programmazione è ciò che fa un programmatore, e sì, un grande programmatore può scrivere documentazione, test unitari, ecc., Ma ammettiamolo: la maggior parte di noi preferisce la programmazione alla documentazione. La sua soluzione è quella in cui il programmatore riconosce il codice riutilizzabile e lo estrae alla propria classe o repository o qualsiasi altra cosa, e dal fatto che è isolato, diventa reperibile e facilita l'apprendimento curva per usarlo .... e questo è stato realizzato dalla programmazione.

In un certo senso la vedo così: ho appena scritto tre funzioni e mi viene in mente che qualcun altro dovrebbe saperlo. Potrei documentarli, scriverli, annunciarli in una riunione, ecc. - cosa che posso fare, ma non è la mia forza - o ... Posso estrarli in una classe, nominarla bene, farli funzionare come una scatola nera e incollala dove vanno gli altri file di classe. Quindi una breve e-mail che annuncia è facile. Altri sviluppatori possono eseguire la scansione del codice e comprenderlo meglio di quanto non possa utilizzare una funzione isolata nel codice che non comprendono appieno - tale contesto viene rimosso.

Mi piace perché significa che avere una serie di file di classi ben definiti, con metodi ben denominati, è una buona soluzione che si ottiene con una buona programmazione. Non richiede riunioni e riduce la necessità di una documentazione dettagliata.

Ci sono altre idee in questo senso ... per sviluppatori isolati e con pressioni temporali?

    
posta changokun 30.04.2013 - 16:37
fonte

7 risposte

29

Biblioteche. Framework. Controllo della versione.

Se hai codice riusabile, l'ultima cosa che vuoi è che i membri del team diversi copino il codice sorgente nel loro progetto. Se lo fanno, è probabile che cambieranno un po 'qui e li modificheranno un po', e presto avrai dozzine di funzioni o metodi che hanno tutti lo stesso nome, ma ognuno di essi funziona in modo leggermente diverso. O, forse più probabilmente, l'autore originale continuerà a perfezionare il codice per correggere i bug, renderlo più efficiente o aggiungere funzionalità, ma il codice copiato non verrà mai aggiornato. Il nome tecnico è un enorme pasticcio .

La soluzione giusta è quella di estrarre quella roba riutilizzabile da qualsiasi progetto per cui l'hai costruita e metterla in una libreria o in un framework nel proprio repository di controllo della versione. Ciò lo rende facile da trovare, ma scoraggia anche le modifiche senza tener conto di tutti gli altri progetti che potrebbero utilizzarlo. Potresti considerare di avere diverse librerie diverse: una per codice ben testato che non è più probabile che cambi, uno per cose che sembrano stabili ma che non sono state completamente testate e riviste, una per le aggiunte proposte.

    
risposta data 30.04.2013 - 17:12
fonte
13

Un approccio per questo è impostare un Wiki per questo scopo e scrivere alcuni documenti di alto livello su quali componenti riutilizzabili hai, come hai risolto un problema, ecc.

La parte difficile è far sì che ognuno nella tua squadra mantenga costantemente Wiki. Ma qualsiasi altro tipo di documentazione soffre dello stesso problema.

Alcuni dei tuoi codici potrebbero anche essere sufficienti per essere inseriti in una libreria riutilizzabile. Questo rende anche più facile trovare il codice più tardi.

    
risposta data 30.04.2013 - 16:51
fonte
7

Essendo in un'azienda con 700 dipendenti, all'interno di team che variano tra 2 e 20 persone, ecco la mia esperienza.

A livello di squadra

Abbiamo "riunioni in piedi" ogni giorno per circa 15-20 minuti. Siamo in grado di condividere rapidamente conoscenze comuni come "Ho fatto questa funzione ieri, è così difficile".

Abbiamo anche una wiki per progetto. Ciò significa che possiamo condividere informazioni (tecniche) su ciò che è stato fatto nel progetto, incluse le classi / funzioni personalizzate che sono state integrate.

A livello di agenzia

A livello di agenzia, abbiamo 4 strumenti:

  • Un altro wiki. È principalmente lì per darci informazioni su hardware e cose, ma a volte lo usiamo per condividere informazioni tecniche da rivedere prima di metterle a livello aziendale.
  • Riunioni settimanali. Per lo più conoscono i progressi di ogni team / progetto, ma dal momento che siamo per lo più appassionati di tecnologia, possiamo portare cose interessanti.
  • Mailing list. Abbiamo una mailing con tutti i membri dell'agenzia. Ci sono un sacco di cose interessanti / cose divertenti / cose utili.
  • repository VCS. Ogni agenzia ha il suo repository personale in cui abbiamo piccoli progetti, per lo più moduli che utilizziamo in diversi progetti.

A livello di azienda

A livello aziendale, è più organizzato.

Il wiki "agency level" è in realtà parte del wiki della società.

E il wiki viene quindi suddiviso in base alle tecnologie. Quindi, chiunque può migliorarlo, cercarlo e sostanzialmente dare una vita al wiki.

Sono disponibili anche mailing list a cui possiamo iscriverci. Chiunque nell'agenzia può iscriversi e la maggior parte delle persone segue almeno una o due tecnologie, in realtà la maggior parte delle persone ne segue 5-10.

E il VCS è ovviamente il miglior sistema di condivisione del codice.

Conclusione

Per riassumere, non esiste una soluzione chiara. La condivisione delle conoscenze è sempre stata un grosso problema e probabilmente rimarrà. Ci sono molte soluzioni per creare basi di conoscenza , e uno potrebbe probabilmente adattarsi al tuo conto. Tuttavia, alcune persone stanno cercando di ottenere un KB ancora migliore poiché le soluzioni attuali non sono sempre molto intelligenti.

    
risposta data 30.04.2013 - 17:21
fonte
6

Bene, tutto si riduce alla comunicazione.

I Wiki sono fantastici e dovresti assolutamente installarne uno e utilizzarne uno. Una buona intranet dei programmatori interni è buona se la gente la legge e la aggiorna, quindi in realtà stai parlando di un problema con le persone. Potresti suggerire riunioni settimanali di "aggiornamento del team" in cui tutti si riuniscono e forniscono una panoramica di cosa sta succedendo. I leader della tecnologia (almeno!) Dovrebbero stare insieme e discutere su cosa sta facendo ogni squadra. Le sessioni informali di "Brown Bag" sono grandiose, programmarle all'ora di pranzo e far parlare la gente.

Hai anche bisogno di un modo per condividere il codice, impacchettarlo, metterlo in versione e distribuirlo. Le cose sarebbero più facili se si dispone di un repository di codice sorgente ben gestito, ben organizzato in cartelle "comuni" e di progetto.

Se non viene fatto nulla di simile, fai rapporto con il tuo capo, spiega come andrà a beneficio dell'azienda e suggerisci una via da seguire:)

    
risposta data 30.04.2013 - 17:13
fonte
4

Le sessioni di revisione del codice possono aiutarti. Se la tua squadra si incontra regolarmente per discutere di ciò che è stato sviluppato, allora la persona che ha escogitato una soluzione può mostrare agli altri come usarla. Se qualcuno fa emergere un punto su cui si stanno attaccando, gli altri membri del team potrebbero proporre un approccio che aumenti il riutilizzo dei componenti esistenti.

    
risposta data 30.04.2013 - 17:07
fonte
2

Il modo migliore per gestire una cosa del genere è avere una struttura di repository che abbia alcune convenzioni semplici così che io sappia, come programmatore, se c'è una funzione doXYZ , approssimativamente dove dovrei cercare quella funzione. Sia che si utilizzino spazi dei nomi, directory, moduli, plug-in, pacchetti, qualsiasi cosa, il codice dovrebbe essere modulare in modo che le funzioni che fanno la stessa cosa o che accedono alle stesse origini dati si trovino nello stesso punto.

    
risposta data 30.04.2013 - 17:17
fonte
0

Idealmente, ci dovrebbe essere almeno un'altra persona oltre all'autore che fa una revisione del codice su ogni check-in. Il processo di revisione del codice può aiutare a mitigare il problema di molti metodi duplicati che vengono controllati. Ovviamente, sei limitato dalla conoscenza dei revisori.

TL; DR: revisione del codice per ogni controllo.

    
risposta data 30.04.2013 - 22:09
fonte

Leggi altre domande sui tag