เรามีผลิตภัณฑ์มีอายุยืนยาวมาประมาณ 8 ปีแล้ว เมื่อเวลาผ่านไปชื่อของแนวคิดและเอนทิตีเปลี่ยน เราควรให้งานเปลี่ยนชื่อรหัสฐานและตารางและคอลัมน์ฐานข้อมูลทั้งหมดเพื่อให้ตรงกับชื่อใหม่เหล่านี้หรือไม่
มีการศึกษาเกี่ยวกับวิธีปฏิบัติที่ดีที่สุดนี้หรือตีพิมพ์บ้างหรือไม่?
ขอบคุณ
คำตอบ:
ความไม่ตรงกันระหว่างชื่อภายในและภายนอกมีกลิ่นแน่นอน เหมือน Rinzwind ชี้ให้เห็น homophones และคำพ้องความหมายกลิ่นที่เลวร้ายที่สุด
คำถามจริงที่คุณต้องตอบคือ: การแลกเปลี่ยนต้นทุน / ผลประโยชน์ในการเปลี่ยนแปลงคืออะไร?
ค่าใช้จ่ายในการไม่เปลี่ยนแปลงเป็นช่วงการเรียนรู้ที่สูงชันสำหรับสมาชิกทีมใหม่และเพิ่มโอกาสในการเกิดข้อบกพร่องในอนาคต ค่าใช้จ่ายในการเปลี่ยนแปลงเป็นช่วงเวลาที่เห็นได้ชัดเส้นโค้งการเรียนรู้ใหม่สำหรับตัวจับเวลาเก่าในโครงการและความเป็นไปได้ของข้อผิดพลาดใหม่
หากคุณคาดว่าจะมีสมาชิกในทีมใหม่จำนวนค่อนข้างมากมีแนวโน้มที่จะทำให้เกิดการเปลี่ยนแปลง หากคุณไม่คาดหวังว่าการหมุนเวียนใด ๆ ทีมปัจจุบันจะไม่สับสนและทีมก็พอใจกับสภาพที่เป็นอยู่แล้วมันก็ไม่สมเหตุสมผลเลยที่จะเปลี่ยนชื่อสิ่งต่าง ๆ
หากรหัสคาดว่าจะมีชีวิตอยู่เป็นเวลานานและจะมีนักพัฒนาใหม่ที่ทำงานกับมันฉันจะทำการเปลี่ยนแปลง
อาจสับสนและเสียเวลามากสำหรับผู้พัฒนารายใหม่ที่จะเข้าสู่โครงการและค้นหาชื่อของเอนทิตีที่ทำให้เข้าใจผิด
นอกจากนี้ยังมีข้อโต้แย้งที่ถูกต้องของ ... หากยังไม่พังอย่าแก้ไข
เกี่ยวกับคำถามที่สองของคุณฉันไม่ได้ตระหนักถึงการศึกษาที่เผยแพร่หรือแนวทางปฏิบัติที่ดีที่สุด สำหรับคำถามแรก ๆ ฉันสามารถนำเสนอการสังเกตจากประสบการณ์ส่วนตัวด้วยผลิตภัณฑ์ที่มีอายุยืนยาวคล้ายกันซึ่งบางครั้งชื่อ 'ภายใน' และ 'ภายนอก' นั้นแตกต่างกัน
ชื่อที่ฉันต้องการแก้ไขจริงๆคือ“ homophones” ซึ่งชื่อหนึ่งถูกใช้ทั้งภายในและภายนอกสำหรับสิ่งต่างๆ สิ่งนี้อาจสร้างความสับสนโดยเฉพาะอย่างยิ่งหากทั้งสองสิ่งนั้นไม่แตกต่างกันโดยสิ้นเชิง (บริบทนั้นช่วยให้เข้าใจผิด) หนึ่ง (ใจลอย) ตัวอย่างที่อยู่ในประสบการณ์ส่วนตัวของฉันคือที่ภายในคุณมีสิ่งที่ต้องการFooซึ่งเป็นคอลเลกชันของหลายFooEntity; ภายนอกมีเพียงส่วนหลังเท่านั้นที่มองเห็นได้และเรียกว่า "ฟู" เอาฉันสักครู่เพื่อคิดออกว่าเมื่อคู่มือลูกค้าพูดหลาย "Foo" มันจริงหมายถึงหลาย ๆFooEntity(ในครั้งเดียวFoo) ถ้ายังคงมีเหตุผลสำหรับคุณ
ประการที่สองฉันต้องการแก้ไข“ คำพ้องความหมาย” ที่ชื่อภายนอกบางส่วนถูกใช้ภายใน เช่นเดียวกับในชื่อตัวแปรส่วนของชื่อเมธอด / ฟังก์ชั่นและอื่น ๆ สิ่งนี้มักจะเกิดขึ้นเมื่อนักพัฒนาใช้บางสิ่งโดยตรงจากคำอธิบายความต้องการของลูกค้าและลืม "แปล" ชื่อ เมื่อเกิดขึ้นชื่อ 'ผิด' ก็มีแนวโน้มแพร่กระจายเช่นกันเนื่องจากผู้พัฒนารายอื่นเกิดขึ้นเพื่อคัดลอก / วางรหัสบางส่วนเพื่อใช้เป็นแม่แบบสำหรับรหัสใหม่ตัวอย่างเช่น คำพ้องความหมายเหล่านี้ไม่ได้ทำให้สับสน แต่พวกเขาอาจจะน่ารำคาญเพราะถ้าคุณกำลังค้นหารหัสสำหรับการอ้างอิงใด ๆBarคุณอาจต้องทราบว่าบางส่วนอาจอ้างถึงเป็นQuxดังนั้นคุณต้องค้นหาสองครั้ง (สิ่งนี้อาจจะแย่กว่าในภาษาที่พิมพ์แบบไดนามิกมากกว่าแบบสแตติกเนื่องจากคุณต้องค้นหาส่วนของชื่อของตัวแปร / ฟังก์ชั่น / ... แทนที่จะใช้ชื่อของประเภทของพวกเขา) สำหรับกรณีการสนทนาของ "คำพ้องความหมาย ” ซึ่งมีการใช้ชื่อภายในจากภายนอก: สิ่งนี้มีแนวโน้มที่จะไม่เกิดขึ้นบ่อยนักเนื่องจากพนักงานให้ความช่วยเหลือลูกค้าและอื่น ๆ มักจะไม่ค่อยรับรู้ถึงชื่อภายใน แต่ฉันคิดว่ามันจะทำให้ลูกค้าสับสนเมื่อมันเกิดขึ้น
หากคุณสามารถหลีกเลี่ยงหรือแก้ไขอย่างน้อยสองสถานการณ์ข้างต้นฉันไม่แน่ใจว่าคุณควรไปไกลเท่าที่จะทำให้ชื่อภายในทั้งหมดเหมือนกับชื่อภายนอก อาจมีเหตุผลที่ดีว่าทำไมชื่อภายในไม่ได้เปลี่ยนไปเมื่อชื่อภายนอกนั้นแตกต่างจากชื่อภายในในตอนแรก จากประสบการณ์ส่วนตัวของฉันเหตุผลที่ดีคือความต้องการสนับสนุนผลิตภัณฑ์รุ่นเก่า มันอาจกลายเป็นเรื่องยากที่จะรวมการแก้ไขข้อบกพร่องจากรุ่นก่อน - ชื่อ - การล้างข้อมูลให้เป็นรุ่นล่าสุดหากมีการเปลี่ยนแปลงรหัสจำนวนมาก
มันเป็นปัญหาที่พบบ่อยพอสมควร จำนวนโครงการที่ฉันทำงานเกี่ยวกับการใช้ชื่อรหัสแทนชื่อผลิตภัณฑ์ (ซึ่งอาจไม่ได้รับการตัดสินใจในจุดนั้น) และใช้คำศัพท์ที่แตกต่างกันอย่างดุเดือดในรหัสมากกว่าสิ่งที่แสดงให้ผู้ใช้เห็น ฉันอาจจะทิ้งสิ่งต่าง ๆ ตามที่เป็นอยู่เว้นแต่คุณจะได้รับการกำหนดรหัสใหม่จำนวนมากหรือหากมีบางสิ่งที่ทำให้เกิดปัญหาเฉพาะ ไม่มีประโยชน์ในการทำให้แอปเปิ้ลเสียใจ นอกจากนี้ใครจะบอกว่า 5 ปีจากนี้จะไม่มีการเปลี่ยนแปลงอีกต่อไป? จากนั้นคุณต้องเปลี่ยนชื่อใหม่อีกครั้ง และอย่าลืมว่าจะมีผลกับเอกสารรหัสแยกต่างหากที่คุณอาจมี (API ที่เผยแพร่แล้ว) ซึ่งอาจเป็นปัญหาที่มีค่าใช้จ่ายสูงหากพิมพ์ออกมา (สำเนา)
ฉันว่าแก้ไขมันในกรณีใด ๆ ที่รหัสมีไว้เพื่อรักษาระยะเวลาใด ๆ คุณจะประหยัดความสับสนและเวลาในอนาคต
ฉันพบว่าบ่อยครั้งที่เอนทิตี "การตลาด" ไม่สอดคล้องกับเอนทิตีภายในอย่างแน่นอน ในกรณีเช่นนี้การแนะนำเอนทิตีในระดับที่แตกต่างกันของนามธรรมซึ่งทำให้คำศัพท์แตกต่างกันเป็นจุดที่สงสัย
ตัวอย่างเช่นเรามีรูปแบบที่แสดงถึงลำดับชั้น แต่ละระดับในลำดับชั้นมีคำที่เกี่ยวข้องโดยยึดตามวิธีการใช้ลำดับชั้นในการสร้างแบบจำลองความสัมพันธ์ในโลกแห่งความเป็นจริง แต่ภายในนั้นไม่มีความแตกต่างในพฤติกรรมจากระดับหนึ่งของลำดับชั้นไปอีกระดับ คำศัพท์นั้นเป็นเพียงชื่อสำหรับระดับนั้นในลำดับชั้นดังนั้นสำหรับโหนดเฉพาะในทรีชื่อก็อธิบายว่าโหนดคืออะไร มันไม่ได้กำหนดพฤติกรรมเฉพาะใด ๆ
นอกจากนี้ต้นไม้ยังมีหลายรูทดังนั้นจึงมีหลายโหนดที่ไม่มีพาเรนต์ แม้ว่าในทางทฤษฎีแล้วรูตจะมีอยู่ (มันจะเป็นตัวแทนของจักรวาล) และการรวมไว้ในโมเดลจะทำให้การดำเนินการหลายอย่างง่ายขึ้นมาก แต่ก็ไม่มี "คำศัพท์ทางการตลาด" สำหรับมัน
แน่นอนว่าส่วนประกอบต่าง ๆ ในระบบของเราใช้คำศัพท์ต่างกัน พวกเขาได้รับการพัฒนาในเวลาที่ต่างกันโดยทีมที่แตกต่างกันและเราไม่สามารถควบคุมพวกเขาทั้งหมดได้ จริงๆแล้วในบางครั้งมีคนเพิ่มหรือลบระดับในองค์ประกอบหนึ่งและดังนั้นระดับอื่น ๆ จะถูกย้ายเทียบกับแต่ละอื่น ๆ สามระดับเดียวกันนั้นแสดงโดย A, B และ C ในองค์ประกอบหนึ่ง แต่เป็น B, C และ D ในอีกองค์ประกอบหนึ่ง
การก้าวขึ้นไปในสิ่งที่เป็นนามธรรมและเพียงแค่สร้างโมเดลทุกอย่างในฐานะ "โหนด" หรือบางสิ่งที่ธรรมดาพอ ๆ กันทำให้แบบจำลองเหล่านี้ง่ายขึ้นมากในการให้เหตุผล แต่ละโหนดรู้ว่า "คำศัพท์ทางการตลาด" คืออะไรและประเภทที่แสดงถึงคำศัพท์ทางการตลาดที่เฉพาะเจาะจงสามารถรู้ได้ว่าคำนั้นหมายถึงอะไรในแต่ละบริบท