Dipende molto dalla situazione concreta. Supponiamo che la nuova proprietà che hai aggiunto sia obbligatoria, cioè deve essere sempre impostata. Quindi devi cercare il codice da solo e aggiornarlo ovunque venga creato companyObj , per assicurarti che sia stato costruito correttamente (inclusa l'impostazione della nuova proprietà). Presumo che PHP abbia costruttori, nel qual caso è sufficiente aggiungere un nuovo parametro costruttore e il compilatore segnerà automaticamente ogni chiamata del costruttore senza il parametro extra come errore di compilazione. Ciò assicurerà inoltre che i membri del team conoscano la nuova proprietà non appena utilizzano companyObj .
Se la nuova proprietà è facoltativa, tuttavia, le cose sono meno chiare. Si può o non può avere un valore predefinito adatto per questo. In quest'ultimo caso, ti suggerirei comunque di aggiornare tutte le creazioni di istanze per impostare la nuova proprietà ogni volta che lo ritieni opportuno. In questo modo assicurati che il codice sia sempre mantenuto in uno stato coerente .
Comunicare il cambiamento ai compagni di squadra è un altro, lontano passo qui. I gruppi 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 attorno a una squadra. Un Wiki è in qualche modo migliore, ma comunque, documentare ogni singolo attributo di classe è eccessivo. Diventerà un enorme fardello per il team, ed è presto destinato a diventare inaffidabile e inutile comunque, dato che siamo umani, quindi siamo costretti a dimenticare l'aggiornamento a volte, inoltre scommetto che non molti membri del team stanno andando regolarmente controlla la documentazione (sia in qualsiasi forma) per essere informato delle ultime modifiche al codice.
Anche quest'ultimo è vero per la documentazione generata automaticamente tramite ad es. 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 nella documentazione per essere informati sulle ultime modifiche al codice. E se utilizzi un qualsiasi sistema di controllo del codice sorgente, il primo posto in cui notare le modifiche si verifica quando aggiorni la tua copia locale del codice, quindi puoi verificare le modifiche nelle classi familiari e vedere con precisione cosa e come è cambiato (insieme a una breve spiegazione e / o riferimento a un ID di attività, se il tuo team è abituato a aggiungere commenti di controllo significativi - che mancherà ai documenti generati automaticamente).
La comunicazione è uno dei motivi principali per cui i team di programmazione Extreme accoppiano la programmazione. Se apporti le modifiche insieme a un compagno di squadra, sei subito in due a sapere di ogni cambiamento, e la prossima volta che ognuno di voi abbinerà qualcun altro, le informazioni così utili si diffonderanno abbastanza rapidamente. Tuttavia, non è sempre applicabile, per vari motivi. Salvo che, potresti 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 in giro se è più grande, più importante o cambiamenti più complicati.
In quest'ultimo caso, ci può essere una buona ragione per documentarlo correttamente. I documenti di progettazione IMHO sono i migliori quando offrono una panoramica a grana grossa e di alto livello del sistema, mentre i dettagli di implementazione sono nel codice (attenendosi a il principio di DRY ).