ฉันกำลังคิดเกี่ยวกับหัวข้อนี้ในขณะที่
ข้อสรุปของฉันคือ - มันไม่ได้เป็นเรื่องของปริมาณ แต่คุณภาพและบริบท
ตัวอย่างเช่นโครงสร้างของโปรเจ็กต์ที่เหมาะสมจะเป็นการแสดงความคิดเห็นที่อธิบายว่าไฟล์นั้นอยู่ที่ใด (การนำไปปฏิบัติเทียบกับความตั้งใจ)
ในทำนองเดียวกันการจำแนกเพื่อชี้แจงบริบทการตั้งชื่อ (ID ในผู้ป่วย -> ผู้ป่วย. ID)
ฉันเชื่อว่า DDD มีคำพูดในเอกสารที่ดี - การจัดหมวดหมู่ให้บริบทบริบทสร้างขอบเขตและขอบเขตนำไปสู่การใช้งานโดยเจตนา (นี่คือที่ซึ่งสิ่งนี้เป็นของมัน
รหัสในตัวมันไม่ดีพอที่จะพิจารณาเอกสาร ปัญหาในกรณีส่วนใหญ่ไม่ได้อยู่ในความจริงที่ว่าการทำงานของรหัสมีความคิดเห็นหรือไม่แสดงความคิดเห็น แต่แรงผลักดัน (ตรรกะโดเมน) ไม่ได้
บางครั้งเราลืมว่าใครเป็นเจ้านาย - ถ้าโค้ดเปลี่ยนไปตรรกะของโดเมนหรือการให้เหตุผลไม่ควร แต่ถ้าตรรกะของโดเมนหรือการใช้เหตุผลเปลี่ยนรหัสจะแน่นอน
ความสอดคล้องเป็นสิ่งที่สำคัญมากเช่นกัน - การประชุมโดยตัวมันเองนั้นไร้ประโยชน์หากมันไม่สอดคล้องกัน
รูปแบบการออกแบบไม่ได้เป็นเพียง 'แนวปฏิบัติที่ดี' เท่านั้น แต่มันเป็นสิ่งที่นักพัฒนาของเราควรเข้าใจ การบอกนักพัฒนาเพื่อเพิ่มประเภทใหม่ให้กับโรงงานนั้นเป็นที่เข้าใจกันดีกว่าการเพิ่มประเภทใหม่ให้กับวิธีการ (ที่บริบทและความสอดคล้องอ่อนหรืออ่อนแอ)
ครึ่งต่อสู้เป็นความคุ้นเคย
ในหมายเหตุด้าน API ที่ดูเหมือนจะชื่นชอบเอกสารจำนวนมากก็มีโดเมนและบริบทที่อ่อนไหวมาก บางครั้งการทำซ้ำฟังก์ชั่นไม่ได้เลวร้าย (สิ่งเดียวกันบริบทที่แตกต่าง) และควรได้รับการปฏิบัติแยกต่างหาก
ในแง่ของการแสดงความคิดเห็นเป็นการดีที่จะชี้ให้เห็นว่าตรรกะของโดเมนอยู่เบื้องหลังการให้เหตุผล
ตัวอย่างเช่นคุณกำลังทำงานในอุตสาหกรรมการแพทย์ ในวิธีการของคุณคุณเขียน "IsPatientSecure = true;"
ตอนนี้โปรแกรมเมอร์ที่ดีคนใดสามารถคิดได้ว่าคนไข้ถูกทำเครื่องหมายว่าปลอดภัย แต่ทำไม ความหมายคืออะไร?
ในกรณีนี้ผู้ป่วยเป็นผู้ต้องขังที่ถูกส่งไปยังโรงพยาบาลนอกสถานที่อย่างปลอดภัย เมื่อรู้สิ่งนี้จะเป็นการง่ายกว่าที่จะจินตนาการถึงเหตุการณ์ที่นำไปสู่จุดนี้ (และอาจจะต้องมีอะไรเกิดขึ้น)
บางทีโพสต์นี้อาจดูดีที่สุดในเชิงปรัชญา แต่โปรดจำไว้ว่ามันเป็น 'การใช้เหตุผล' หรือ 'ตรรกะ' ที่คุณเขียนไม่ใช่รหัส