Il nostro team è distribuito nello spazio e nel tempo, quindi non abbiamo la possibilità di discutere l'architettura del codice in tempo reale. Come possiamo discuterlo tramite la documentazione: scrivere le interfacce di codice / commentare / modificare, tracciare la cronologia dell'architettura del codice? Ci sono alcuni strumenti specifici per questo? Quali sono i modi migliori: diagrammi di classe, interfacce di codice, qualcosa di diverso? Stiamo usando c # e VS2010
What is the best way to discuss/plan/negotiate about code architecture remotely?
Ci sono molte tecniche, a seconda della tua squadra. Consiglio vivamente l'utilizzo del controllo di versione e quindi la standardizzazione su un elaboratore di testi e un editor di diagrammi (fino alla versione), a seconda delle preferenze del team. Ciò garantirà che tutti possano visualizzare e modificare i diagrammi e i documenti prodotti.
Un grosso problema con molti sistemi di controllo delle versioni è che i file binari non possono essere diffusi o uniti. È necessario essere consapevoli di ciò, poiché molto di ciò che viene prodotto dai word processor e gli editor di diagrammi sono file binari. Assicurati di non calpestare il lavoro di altre persone.
How can we discuss it via documentation: write code interfaces/ comment/ modify, track history of the code architecture?
Quando si discute un'architettura, è importante realizzare diversi tipi di viste del sistema. Diverse parti interessate richiedono diverse visualizzazioni del sistema per eseguire analisi, progettazione dettagliata e implementazione. Un esempio di un insieme di visualizzazioni sarebbe il 4 + 1 Architectural View Model che utilizza una serie di vari diagrammi UML per mostrare vari aspetti del sistema. Mi sono concentrato sul modello 4 + 1 e ho scelto i diagrammi UML appropriati per ogni vista nel corso di architettura del software che ho seguito.
Se stai usando vari diagrammi UML, devi identificare quelli che vuoi. Il modello 4 + 1 suggerisce vari diagrammi per ogni vista, ma ci sono 14 tipi di diagrammi in UML 2.2, e i diagrammi che troverai utili varieranno a seconda del progetto.
Per quanto riguarda le interfacce di codice, non essere troppo dettagliato nella fase di architettura. Potrebbero esserci alcune interfacce attese dal client che si conoscono (specialmente se si sta creando un'API per il consumo), e va bene lavorare con quelle. Ma non lasciarti coinvolgere in qualcosa di non chiaramente specificato dalle tue esigenze quando si tratta di dettagli specifici a livello di classe - che possono venire più tardi in fase di progettazione.
Qualsiasi controllo di versione che stai utilizzando può tenere traccia delle modifiche. Come ho detto prima, probabilmente lavorerai con un numero di file binari, quindi dovrai fare molta attenzione e usare le note di modifica dettagliate poiché i file diffetti diventano più difficili.
We are using c# and VS2010
L'architettura e anche le decisioni di progettazione di alto livello dovrebbero essere indipendenti dal linguaggio e dagli strumenti di implementazione che state utilizzando. Non lasciare che gli strumenti che stai utilizzando ti guidino fino a quando non prendi decisioni di progettazione dettagliate, quando scegli quali funzionalità linguistiche ti aiuteranno meglio a realizzare la tua architettura e le decisioni progettuali di alto livello fatte in precedenza.
Documenti di Google o file di documentazione controllati nel controllo sorgente insieme all'email andranno bene per la maggior parte delle cose. Essere in grado di documentare la versione è bello, ma Google Docs è in tempo reale, quindi non devi aspettare per i check-in. Questo metodo potrebbe non essere sufficiente per tutti, ma il metodo più semplice è sempre il primo a dare un'occhiata.
Dai un'occhiata a Campfire , sembra abbastanza adatto a quello che cerchi. Fa testo, file, codice, chat immagini. Salva una cronologia in modo da poter controllare ciò che è stato discusso prima. C'è una prova gratuita, quindi dai una possibilità ...
Se hai bisogno di più funzionalità, credo che ci siano plugin che potrebbero essere utili.
(Non ho connessioni con 37signals)
Questo potrebbe sembrare un dato per molti utenti di questo sito, ma è abbastanza nuovo per il mio set di strumenti, quindi sono ancora entusiasta di ciò. Una delle cose che preferisco degli strumenti di controllo delle versioni (ho usato CVS, Subversion e Mercurial per diversi progetti) è il fatto che i file sorgente non sono le uniche cose che puoi inserire in essi. Qualsiasi formato di file può essere nel repository, il che significa che puoi avere file di progettazione e documentazione in qualsiasi formato tu scelga. Oltre al tradizionale controllo di versione come gli oggetti nominati, Dropbox è un ottimo strumento per avere una raccolta condivisa di file su più dispositivi.
Strumenti come questi, abbinati a uno dei tanti strumenti di presentazione remota desktop / remoto disponibili (mi piacciono Teamviewer (Windows) e NoMachine (Linux)), rendono abbastanza facile ottenere l'effetto desiderato.
Oltre agli strumenti ci sono addestramento e un vocabolario comune.
Investire nella formazione dei modelli di architettura.
Quindi, quando qualcuno dice "useremo il modello singleton", "useremo il modello del repository" o "useremo il modello della facciata". Tutti sanno di cosa stanno parlando.
Uso Google Documenti per tutta la mia documentazione. Permette ai miei compagni di lavoro di vedere gli ultimi cambiamenti in tempo reale, mantiene una cronologia delle revisioni, supporta la gestione dei diritti di accesso (quindi il tuo capo stupido non può scherzare con i file;) e puoi lasciare dei commenti. Crea una cartella e condividila con i tuoi colleghi. Puoi anche inserire immagini nei tuoi documenti, quindi è abbastanza completo. Poi, quando sei pronto per andare avanti e programmarlo, hai i documenti accessibili da qualsiasi luogo, quindi puoi anche lavorare da qualsiasi luogo, ma direi che usare un bug tracker è essenziale in un progetto distribuito --- personalmente mi piace Redmine .
Anche se non siamo così sparsi nello spazio e nel tempo, ma a volte usiamo " design video " invece di documenti di design per trasmettere conoscenze relative a design / architettura / documentazione. Penso che questo potrebbe essere utile nel tuo caso.
Poiché stai già utilizzando VS2010, puoi eseguire l'aggiornamento a 2010 Ultimate con TFS?
Puoi confrontare le funzioni qui Abbiamo usato questo in larga misura con team distribuiti in tutto il mondo e operanti in diversi fusi orari. C'è un costo in gioco però. Non sono sicuro di come si paragona ad alcune delle altre soluzioni menzionate qui.
Se ottieni VS2010 Ultimate, puoi generare grafici di dipendenza dal codice per aiutarti a visualizzare relazioni, spazi dei nomi, classi, membri e così via. È inoltre possibile creare diagrammi di livello, diagrammi di sequenza e diagrammi di classe dal codice e anche da altri diagrammi UML.
Per ulteriori informazioni, vedere questo argomento MSDN Library: Modellazione dell'applicazione
Non dimentichiamo la lista di indirizzi e IRC.
Direi anche che potresti usare graphviz, dato che i file .dot sono in puro testo e potresti generarli con il codice ... Il testo semplice è buono per i sistemi di controllo delle versioni.
Leggi altre domande sui tag teamwork c# architecture planning