这在很大程度上取决于具体情况。假设您添加的新属性是强制性的,即必须始终对其进行设置。然后,您必须自己搜索代码,并在companyObj
创建a的任何地方进行更新,以确保其构造正确(包括设置新属性)。我假设PHP具有构造函数,在这种情况下,您只需要添加一个新的构造函数参数,编译器就会自动将每个构造函数调用标记为无额外参数,这是编译错误。这也将确保队友在使用新属性后立即了解新属性companyObj
。
但是,如果new属性是可选的,则情况不太清楚。您可能有或没有合适的默认值。在后一种情况下,我仍然建议您更新所有实例创建以在适当的时候设置新属性。这是为了确保代码始终保持一致状态。
与团队成员交流变更是这里的又一个遥远的步骤。敏捷的团队更喜欢面对面的交流,恕我直言,这是有充分理由的。依赖文档是在团队中传播信息的非常缓慢且无效的方法。Wiki更好一些,但是记录每个类的属性仍然是恕我直言。这只会给团队带来沉重负担,并且很快就会变得不可靠和毫无用处,因为我们是人类,因此我们有时会忘记更新,而且我敢打赌,没有多少团队成员会定期查看文档(采用任何形式),以了解最新的代码更改。
后者也适用于通过Javadoc或Doxygen自动生成的文档。尽管可以将它们配置为自动构建,以始终保持生成的文档为最新,但是我从未见过有开发团队成员定期浏览文档以获取有关最新代码更改的信息。而且,如果您使用的是任何源代码控制系统,那么首先要注意到更改的地方是无论如何都更新代码的本地副本 -然后您可以检查熟悉的类中的更改,并准确查看更改的内容和更改的方式(以及如果您的团队习惯于添加有意义的签入注释(自动生成的文档会丢失),则简要说明和/或参考任务ID 。
沟通是至尊编程团队进行配对编程的主要原因之一。如果您与队友一起进行更改,那么马上就有两个人知道每个更改,并且下次每个人都将与其他人配对时,有用的信息会迅速传播。但是由于种种原因,它并不总是适用。除此以外,您可以在适当的时候(例如午餐时,如果您碰巧一起吃午餐),与邻居谈论变化,或者如果变化更大,更重要或更复杂,则向周围的人发送邮件。
在后一种情况下,可能有充分的理由对其进行正确记录。IMHO设计文档最适合提供粗粒度的系统高级概述,而实现细节在代码中(遵循DRY原理)。