Depende mucho de la situación concreta. Supongamos que la nueva propiedad que agregó es obligatoria, es decir, debe establecerse siempre. Luego, debe buscar el código usted mismo y actualizarlo en todas partes donde companyObjse cree, para asegurarse de que se construye correctamente (incluida la configuración de la nueva propiedad). Supongo que PHP tiene constructores, en cuyo caso solo necesita agregar un nuevo parámetro de constructor y el compilador marcará automáticamente cada llamada de constructor sin el parámetro adicional como un error de compilación. Esto también asegurará que los compañeros de equipo conozcan la nueva propiedad tan pronto como usen a companyObj.
Si la nueva propiedad es opcional, sin embargo, las cosas están menos claras. Puede o no tener un valor predeterminado adecuado para ello. En el último caso, aún sugeriría que actualice todas las creaciones de instancias para establecer la nueva propiedad siempre que sea apropiado. Esto es para garantizar que el código se mantenga en un estado coherente en todo momento .
Comunicar el cambio a tus compañeros de equipo es otro paso distante aquí. Los equipos ágiles prefieren la comunicación cara a cara y, en mi humilde opinión, por una buena razón. Confiar en los documentos es un medio muy lento e ineficaz de difundir información alrededor de un equipo. Un Wiki es algo mejor, pero aún así, documentar cada atributo de clase es una exageración de mi humilde opinión. Solo se convertirá en una gran carga para el equipo, y de todos modos rápidamente se volverá poco confiable e inútil, ya que somos humanos, por lo que a veces olvidaremos la actualización, además, apuesto a que no muchos miembros del equipo lo harán regularmente revise la documentación (ya sea en cualquier forma) para informarse de los últimos cambios en el código.
Esto último también es válido para la documentación generada automáticamente a través de, por ejemplo, Javadoc o Doxygen. Aunque se pueden configurar en una compilación automática para mantener actualizada la documentación generada en todo momento, nunca he visto un equipo de desarrollo con miembros que naveguen regularmente por la documentación para informarse sobre los últimos cambios en el código. Y si está utilizando algún sistema de control de fuente, el primer lugar para notar los cambios es cuando actualiza su copia local del código de todos modos; luego puede verificar los cambios en las clases conocidas y ver exactamente qué y cómo ha cambiado (junto con un breve explicación y / o referencia a una ID de tarea, si su equipo está acostumbrado a agregar comentarios de registro significativos, que faltarán en los documentos generados automáticamente).
La comunicación es una de las principales razones por las que los equipos de Extreme Programing hacen programación en pares. Si realiza los cambios junto con un compañero de equipo, hay dos de ustedes de inmediato que conocen cada cambio, y la próxima vez que cada uno de ustedes se empareje con otra persona, la información útil se difundirá rápidamente. Sin embargo, no siempre es aplicable por varias razones. Salvo eso, simplemente puede hablar con sus vecinos sobre el cambio en un momento apropiado (por ejemplo, durante el almuerzo, si almuerzan juntos), o enviar un correo electrónico si es un cambio más grande, más importante o más complicado.
En el último caso, puede haber una buena razón para documentarlo adecuadamente. Los documentos de diseño de la OMI son mejores cuando ofrecen una visión general de alto nivel del sistema, mientras que los detalles de implementación están en el código (que se adhiere al principio DRY ).