Nó phụ thuộc rất nhiều vào tình hình cụ thể. Giả sử tài sản mới mà bạn thêm là bắt buộc, nghĩa là nó phải luôn được đặt. Sau đó, bạn phải tự tìm kiếm thông qua mã và cập nhật nó ở mọi nơi a companyObjđược tạo, để đảm bảo rằng nó được xây dựng đúng (bao gồm thiết lập thuộc tính mới). Tôi giả sử PHP có các hàm tạo, trong trường hợp đó bạn chỉ cần thêm một tham số hàm tạo mới và trình biên dịch sẽ tự động đánh dấu mọi lệnh gọi của hàm tạo mà không có tham số phụ là lỗi biên dịch. Điều này cũng sẽ đảm bảo rằng các đồng đội tìm hiểu về tài sản mới ngay khi họ sử dụng a companyObj.
Nếu thuộc tính mới là tùy chọn, tuy nhiên, mọi thứ sẽ không rõ ràng. Bạn có thể có hoặc không có giá trị mặc định phù hợp cho nó. Trong trường hợp sau, tôi vẫn sẽ đề nghị bạn cập nhật tất cả các sáng tạo cá thể để đặt thuộc tính mới bất cứ khi nào thích hợp. Điều này là để đảm bảo rằng mã được giữ ở trạng thái nhất quán mọi lúc .
Truyền đạt sự thay đổi cho đồng đội của bạn là một bước tiến xa khác ở đây. Các nhóm nhanh nhẹn thích giao tiếp trực tiếp và IMHO vì một lý do chính đáng. Dựa vào tài liệu là một phương tiện truyền bá thông tin rất chậm và không hiệu quả xung quanh một đội. Một Wiki có phần tốt hơn, nhưng vẫn vậy, ghi lại mọi thuộc tính của từng lớp là IMHO quá mức cần thiết. Nó sẽ chỉ trở thành một gánh nặng lớn cho đội và nhanh chóng trở nên không đáng tin cậy và vô dụng, vì chúng ta là con người nên đôi khi chúng ta quên mất việc cập nhật, hơn nữa tôi cá rằng không có nhiều thành viên trong nhóm sẽ thường xuyên kiểm tra tài liệu (dưới mọi hình thức) để được thông báo về những thay đổi mã mới nhất.
Điều này cũng đúng với tài liệu được tạo tự động thông qua ví dụ Javadoc hoặc Doxygen. Mặc dù chúng có thể được cấu hình thành bản dựng tự động để luôn cập nhật tài liệu đã tạo, tôi chưa bao giờ thấy một nhóm phát triển với các thành viên thường xuyên duyệt qua tài liệu để được thông báo về các thay đổi mã mới nhất. Và nếu bạn đang sử dụng bất kỳ hệ thống kiểm soát nguồn nào, nơi đầu tiên nhận thấy các thay đổi là khi bạn cập nhật bản sao mã cục bộ của mình - sau đó bạn có thể kiểm tra các thay đổi trong các lớp quen thuộc và xem chính xác những gì và cách thay đổi (cùng với giải thích ngắn gọn và / hoặc tham chiếu đến ID nhiệm vụ, nếu nhóm của bạn đã quen với việc thêm nhận xét đăng nhập có ý nghĩa - sẽ bị thiếu trong các tài liệu được tạo tự động).
Giao tiếp là một lý do chính tại sao các nhóm lập trình cực đoan thực hiện lập trình cặp. Nếu bạn thực hiện các thay đổi cùng với một đồng đội, có hai bạn ngay lập tức biết về từng thay đổi và lần sau mỗi bạn sẽ bắt cặp với người khác, vì vậy thông tin hữu ích sẽ lan truyền khá nhanh. Nó không phải luôn luôn được áp dụng mặc dù, vì nhiều lý do. Chặn rằng, bạn có thể chỉ cần nói chuyện với hàng xóm về sự thay đổi trong một thời điểm thích hợp (ví dụ như trong bữa trưa, nếu bạn tình cờ ăn trưa cùng nhau) hoặc gửi thư xung quanh nếu đó là một thay đổi lớn hơn, quan trọng hơn hoặc phức tạp hơn.
Trong trường hợp sau, có thể có một lý do chính đáng để ghi lại nó đúng. Tài liệu thiết kế IMHO là tốt nhất khi chúng cung cấp một tổng quan cấp cao, chi tiết về hệ thống, trong khi các chi tiết triển khai nằm trong mã (tuân thủ nguyên tắc DRY ).