มันขึ้นอยู่กับสถานการณ์ที่เป็นรูปธรรม สมมติว่าคุณสมบัติใหม่ที่คุณเพิ่มนั้นจำเป็นต้องมีการตั้งค่าไว้เสมอ จากนั้นคุณต้องค้นหารหัสด้วยตนเองและอัปเดตทุกที่ที่companyObjสร้างขึ้นเพื่อให้แน่ใจว่าสร้างขึ้นอย่างถูกต้อง (รวมถึงการตั้งค่าคุณสมบัติใหม่) ฉันสมมติว่า PHP มีคอนสตรัคเตอร์ซึ่งในกรณีนี้คุณเพียงแค่เพิ่มพารามิเตอร์คอนสตรัคเตอร์ใหม่เท่านั้นและคอมไพเลอร์จะทำเครื่องหมายการเรียกใช้ตัวสร้างทุกครั้งโดยอัตโนมัติโดยไม่มีพารามิเตอร์พิเศษเป็นข้อผิดพลาดในการรวบรวม companyObjนอกจากนี้ยังจะให้มั่นใจว่าเพื่อนร่วมทีมได้เรียนรู้เกี่ยวกับคุณสมบัติใหม่ที่เร็วที่สุดเท่าที่พวกเขาใช้
อย่างไรก็ตามถ้าคุณสมบัติใหม่เป็นทางเลือกสิ่งต่าง ๆ จะมีความชัดเจนน้อยกว่า คุณอาจจะหรืออาจไม่มีค่าเริ่มต้นที่เหมาะสมสำหรับมัน ในกรณีหลังนี้ฉันขอแนะนำให้คุณอัปเดตการสร้างอินสแตนซ์ทั้งหมดเพื่อตั้งค่าคุณสมบัติใหม่เมื่อใดก็ตามที่เหมาะสม นี่คือเพื่อให้แน่ใจว่ารหัสถูกเก็บไว้ในสถานะที่สอดคล้องกันตลอดเวลา
การสื่อสารการเปลี่ยนแปลงให้เพื่อนร่วมทีมของคุณเป็นอีกก้าวที่ไกลออกไป ทีมเปรียวชอบการสื่อสารแบบตัวต่อตัวและ IMHO ด้วยเหตุผลที่ดี การใช้เอกสารเป็นวิธีที่ช้าและไม่มีประสิทธิภาพในการเผยแพร่ข้อมูลรอบ ๆ ทีม Wiki ค่อนข้างดีกว่า แต่ถึงกระนั้นการจัดทำเอกสารทุก ๆ คลาสของแอ็ตทริบิวต์คือ IMHO overkill มันจะกลายเป็นภาระใหญ่ในทีมและจะกลายเป็นภาระที่ไม่น่าเชื่อถือและไร้ประโยชน์อย่างรวดเร็วในขณะที่เราเป็นมนุษย์ดังนั้นเราต้องผูกพันที่จะลืมการปรับปรุงในบางครั้งยิ่งกว่านั้นฉันพนันได้ว่ามีสมาชิกในทีมจำนวนไม่มาก ตรวจสอบเอกสาร (ไม่ว่าจะในรูปแบบใด) เพื่อรับทราบการเปลี่ยนแปลงรหัสล่าสุด
เอกสารฉบับหลังนี้เป็นจริงสำหรับเอกสารที่สร้างขึ้นโดยอัตโนมัติเช่น Javadoc หรือ Doxygen แม้ว่าพวกเขาจะสามารถกำหนดค่าในการสร้างอัตโนมัติเพื่อให้เอกสารที่สร้างขึ้นอยู่ตลอดเวลาฉันไม่เคยเห็นทีมพัฒนาที่มีสมาชิกเรียกดูเอกสารอย่างสม่ำเสมอเพื่อรับทราบเกี่ยวกับการเปลี่ยนแปลงรหัสล่าสุด และถ้าคุณใช้ระบบควบคุมแหล่งใด ๆสถานที่แรกที่สังเกตเห็นการเปลี่ยนแปลงคือเมื่อคุณอัปเดตรหัสท้องถิ่นของคุณอย่างไรก็ตามคุณสามารถตรวจสอบการเปลี่ยนแปลงในชั้นเรียนที่คุ้นเคยและดูว่ามีการเปลี่ยนแปลงอย่างไร (พร้อมกับ คำอธิบายสั้น ๆ และ / หรือการอ้างอิงถึง ID งานหากทีมของคุณคุ้นเคยกับการเพิ่มความคิดเห็นเช็คอินที่มีความหมายซึ่งจะหายไปจากเอกสารที่สร้างขึ้นโดยอัตโนมัติ)
การสื่อสารเป็นเหตุผลสำคัญประการหนึ่งที่ทีมวางโปรแกรม Extreme ทำโปรแกรมคู่ หากคุณทำการเปลี่ยนแปลงร่วมกับเพื่อนร่วมทีมคุณสองคนจะรู้ทันทีเกี่ยวกับการเปลี่ยนแปลงแต่ละครั้งและครั้งต่อไปที่คุณจะจับคู่กับคนอื่นข้อมูลที่มีประโยชน์จึงแพร่กระจายอย่างรวดเร็ว มันไม่สามารถใช้ได้เสมอแม้ว่าด้วยเหตุผลต่างๆ นอกจากนั้นคุณอาจพูดคุยกับเพื่อนบ้านเกี่ยวกับการเปลี่ยนแปลงในช่วงเวลาที่เหมาะสม (เช่นระหว่างมื้ออาหารกลางวันหรือหากคุณทานอาหารกลางวันด้วยกัน) หรือส่งจดหมายรอบหากเป็นการเปลี่ยนแปลงที่ใหญ่กว่าสำคัญกว่าหรือซับซ้อนกว่า
ในกรณีหลังอาจมีเหตุผลที่ดีที่จะจัดทำเอกสารอย่างถูกต้อง เอกสารการออกแบบของ IMHO นั้นดีที่สุดเมื่อพวกเขาเสนอภาพรวมของระบบที่หยาบและหยาบในขณะที่รายละเอียดการใช้งานจะอยู่ในรหัส (ปฏิบัติตามหลักการของ DRY )