Come far sapere ai compagni di squadra quali modifiche ho apportato a un oggetto? [chiuso]

Supponiamo che io abbia un oggetto PHP, diciamo: companyObj.

class companyObj
{
  private company_name;
  private company_address;

  public function print_contact()
  {
    //logic
  }
}

Questo è l'oggetto che ho scritto e condiviso con i compagni di squadra. Ora vorrei renderlo più potente, in questo modo:

class companyObj
{
  private company_name;
  private company_address;
  private company_contact_person;

  public function print_contact()
  {
    //logic updated
  }
}

Ora, come posso informare i miei compagni di squadra che il mio oggetto aveva più attributi che possono impostare?

Invece di inviare e-mail a tutti i membri del team di sviluppo, come faccio a far sapere al team cosa sta succedendo, quando non voglio che i miei compagni di squadra perdano il loro tempo a guardare cosa è cambiato a livello di codice sorgente?

Dipende molto dalla situazione concreta. Supponiamo che la nuova proprietà che hai aggiunto sia obbligatoria, vale a dire che deve essere impostata sempre. Quindi devi cercare tu stesso il codice e aggiornarlo ovunque companyObjvenga creato un, per assicurarti che sia costruito correttamente (inclusa l'impostazione della nuova proprietà). Suppongo che PHP abbia dei costruttori, nel qual caso devi solo aggiungere un nuovo parametro del costruttore e il compilatore contrassegnerà automaticamente ogni chiamata del costruttore senza il parametro aggiuntivo come errore di compilazione. Ciò garantirà inoltre che i compagni di squadra vengano a conoscenza della nuova proprietà non appena utilizzano a companyObj.

Se la nuova proprietà è facoltativa, tuttavia, le cose sono meno chiare. È possibile o meno disporre di un valore predefinito adeguato per questo. In quest'ultimo caso, suggerirei comunque di aggiornare tutte le creazioni dell'istanza per impostare la nuova proprietà ogni volta che è opportuno. Questo per garantire che il codice sia sempre mantenuto in uno stato coerente .

Comunicare la modifica ai tuoi compagni di squadra è un altro passo lontano qui. I team agili preferiscono la comunicazione faccia a faccia e, IMHO, per una buona ragione. Affidarsi ai documenti è un mezzo molto lento e inefficace per diffondere informazioni all'interno di una squadra. Un Wiki è un po 'meglio, ma documentare ogni singolo attributo di classe è eccessivo per IMHO. Diventerà solo un enorme onere per la squadra ed è presto destinato a diventare inaffidabile e inutile in ogni caso, poiché siamo umani, quindi siamo tenuti a dimenticare l'aggiornamento a volte, inoltre scommetto che non molti membri del team lo faranno regolarmente controlla la documentazione (sia essa in qualsiasi forma) per essere informato delle ultime modifiche al codice.

Quest'ultimo vale anche per la documentazione generata automaticamente, ad esempio Javadoc o Doxygen. Sebbene possano essere configurati in una build automatica per mantenere sempre aggiornata la documentazione generata, non ho mai visto un team di sviluppo con membri che navigano regolarmente attraverso la documentazione per ottenere informazioni sulle ultime modifiche al codice. E se stai usando un sistema di controllo del codice sorgente, il primo posto in cui notare le modifiche è quando aggiorni la tua copia locale del codice, quindi puoi controllare le modifiche nelle classi familiari e vedere esattamente cosa e come è cambiato (insieme a un breve spiegazione e / o riferimento a un ID attività, se il tuo team è abituato ad aggiungere commenti significativi sul check-in - che mancherà tra i documenti generati automaticamente).

La comunicazione è una delle ragioni principali per cui i team Extreme Programing abbinano la programmazione. Se apporti le modifiche insieme a un compagno di squadra, ci sono subito due di voi che sono a conoscenza di ciascuna modifica e la prossima volta che ciascuno di voi si accoppierà con qualcun altro, così informazioni utili si diffonderanno abbastanza rapidamente. Tuttavia, non è sempre applicabile, per vari motivi. A parte questo, puoi semplicemente parlare con i tuoi vicini del cambiamento in un momento appropriato (ad esempio durante il pranzo, se ti capita di pranzare insieme), o inviare una mail se si tratta di un cambiamento più grande, più importante o più complicato.

In quest'ultimo caso, potrebbe esserci un buon motivo per documentarlo correttamente. I documenti di progettazione IMHO sono i migliori quando offrono una visione generale del sistema a grana grossa, mentre i dettagli di implementazione sono nel codice (aderendo al principio DRY ).

Hai considerato semplicemente di parlare con loro ? Pianifica un breve incontro: "hey, ho apportato alcune modifiche all'oggetto X, voglio mostrarti cosa è cambiato e perché". Oppure parla semplicemente con ciascuna persona se una riunione sembra troppo formale o distruttiva.

Se hai una squadra probabilmente hai anche un documento di progettazione. Altrimenti. iniziare su di esso. E usa alcuni strumenti UML per mappare i tuoi progetti.

Puoi usare uno strumento come doxygen nel tuo codice. Ora crea uno script che generi la documentazione di doxygen ed esegua regolarmente, forse come parte della tua build notturna (fai una build notturna, giusto?).

Penso che tu possa assegnare un attributo personalizzato in doxygen alla tua aggiunta per evidenziarlo come nuovo.

Se i tuoi compagni di squadra sono bravi, passerebbero alla nuova documentazione.

Ora, come posso informare i miei compagni di squadra che il mio oggetto aveva più attributi che possono impostare?

Bene, non dovresti informare i tuoi compagni di squadra su ogni piccola cosa che fai. Altrimenti, dovresti inviare molte e-mail. Se è una cosa importante, puoi organizzare una piccola riunione e far loro sapere cosa hai fatto (se fai la mischia, non è necessario impostare una riunione separata).

Se usi un IDE che supporta il completamento automatico, i tuoi compagni di squadra dovrebbero notare le tue modifiche. Spero solo che tu commenti il ​​tuo codice.