เราควรเปลี่ยนชื่อรหัสและข้อมูลเมื่อผู้ใช้ปลายทางเปลี่ยนชื่ออย่างไร?

เมื่อนานมาแล้วเราได้เพิ่มคุณสมบัติที่ผู้ใช้ของเราสามารถ "ยอมรับ" ภาพหลังจากที่เพิ่มเข้าไปในคิวเวิร์กโฟลว์ ปรากฎว่าเราใช้คำผิดและผู้ใช้ "อนุมัติ" รูปภาพ

การเปลี่ยนยอมรับเป็นอนุมัติบนอินเทอร์เฟซของเรานั้นง่ายดายเพียงแค่เปลี่ยนคำเดียว แต่เราตั้งโปรแกรมเลเยอร์ทั้งหมดด้วยคำว่า "accept" จากชื่อคลาส CSS ไปจนถึงค่าฐานข้อมูล

• คลาส CSS ที่เปลี่ยนเป็นปุ่มสีเขียว: ".accepted";
• เมธอดโมเดลที่ตรวจสอบและผูกแอ็ตทริบิวต์คลาสบนโหนด DOM: "isAccepted";
• แอตทริบิวต์สถานะ JavaScript: อาร์เรย์ที่มี "unreviewed", "ยอมรับ" และ "เผยแพร่";
• คอลัมน์สถานะ Mysql: ENUM ที่มี "ไม่ได้ตรวจสอบ", "ยอมรับ" และ "เผยแพร่";
• ชื่อทดสอบ

เป็นเรื่องเล็กน้อย (โดยเฉพาะเมื่อคุณมีการทดสอบ) เพื่อแทนที่การยอมรับส่วนใหญ่ที่จะอนุมัติ ยากกว่าเล็กน้อยคือการโยกย้ายข้อมูลโดยเฉพาะอย่างยิ่งเนื่องจากต้องมีการซิงโครไนซ์กับการปรับใช้

คดีเฉพาะเรื่องนี้เรียบง่าย แต่ฉันเคยเจอคดีที่คล้ายกัน แต่มีความซับซ้อนมากกว่าในระหว่างการทำงาน เมื่อไฟล์ถูกเปลี่ยนชื่อและการปรับใช้เกิดขึ้นในเซิร์ฟเวอร์หลายสิบเครื่องหรือเมื่อแคชพร็อกซี memcached และ mysql เกี่ยวข้อง

การปล่อย "ยอมรับ" ในทุก ๆ เลเยอร์ยกเว้นอินเทอร์เฟซเป็นความคิดที่ไม่ดีเนื่องจากโปรแกรมเมอร์ใหม่ที่เข้าร่วมทีมอาจไม่ได้เรียนรู้เหตุผลทางประวัติศาสตร์ที่นำไปสู่การตัดสินใจนี้และในขณะที่การยอมรับ -> อนุมัติเป็นคำใกล้เคียง ถูกเปลี่ยนชื่อเป็น "จัดคิวสำหรับการประชุมสถานะครั้งต่อไปของผู้บริหาร" แน่นอนว่าคงไม่มีเหตุผลใด ๆ และรู้สึกว่าถ้าเราประนีประนอมที่นี่และที่นั่นในการทำซ้ำสองสามแนวคิดส่วนติดต่อผู้ใช้จะไม่มีแบริ่งไปยังระบบภายในและแน่นอนฉันไม่ต้องการทำงานในระบบที่ครึ่งหนึ่งของการส่งออกไม่มีการเชื่อมต่อกับอวัยวะภายใน

ดังนั้นคุณจะเปลี่ยนชื่อทุกสิ่งเมื่อจำเป็นหรือไม่ หากสิ่งนี้เกิดขึ้นกับคุณและคุณตัดสินใจว่าการแลกเปลี่ยนไม่คุ้มค่าคุณจะกัดคุณหรือไม่ ความคิดเห็นเกี่ยวกับรหัสหรือเอกสารสำหรับนักพัฒนาเพียงพอที่จะหลีกเลี่ยงปัญหานี้หรือไม่?

สำหรับฉันมันเป็นการดีที่สุดที่จะเปลี่ยนแปลงทุกอย่างที่เกี่ยวข้องกับรายการที่เป็นปัญหา

มันเป็นรูปแบบของการย่อยสลายของรหัสและในขณะที่ 1 รายการที่ไม่ได้เปลี่ยนอาจไม่เป็นเรื่องใหญ่

มันอาจนำไปสู่ความสับสนในอนาคตและทำให้มันยากขึ้นสำหรับ devs ใหม่ที่จะเข้าใจรหัสฐาน / โดเมน

จากเนื้อหาคำถามและแท็กฉันจะระบุว่าคุณกำลังใช้ภาษาที่แพร่หลาย

จากประสบการณ์ของฉัน UL นั้นยอดเยี่ยม แต่อย่างที่คุณพูดถึงสามารถนำไปสู่งานบำรุงรักษาเพิ่มเติมตามที่ภาษาวิวัฒนาการ ในตัวมันเองไม่ได้เลวร้ายอะไร แน่นอนว่ามันไม่สะดวก แต่ก็คาดหวังเช่นกัน

สิ่งที่ฉันทำโดยทั่วไป (และเห็นเสร็จแล้ว) เป็นอย่างใดอย่างหนึ่ง:

• การปรับโครงสร้างใหม่แบบ 1 ช็อต: Refactor เลเยอร์ทั้งหมดของแอปพลิเคชันเพื่อปรับใช้ภาษาที่ได้รับการปรับปรุง หรือ
• บันทึกหนี้ด้านเทคนิค: คุณสามารถเปลี่ยนรหัสผู้ใช้ทันทีจากนั้นบันทึกงานด้านเทคนิคหนี้เพื่อให้เลเยอร์แอปพลิเคชั่นที่เหลือสอดคล้องกับภาษาที่อัปเดต โดยทั่วไปแล้วจะส่งผลให้มีงานที่น่าเบื่อ (แต่สามารถจัดการได้) จำนวนหนึ่ง (เหมาะสำหรับ 5 โมงเย็น!)

ฉันคิดว่าสิ่งสำคัญที่นี่คือสิ่งที่คุณอธิบายคือหนี้ทางเทคนิคและควรได้รับการยอมรับเช่นนี้

ฉันมีผู้จัดการที่แย้งว่าเราไม่ควรเสียเวลากับงานที่ไม่สำคัญเช่นนี้ที่ไม่ได้เพิ่มฟังก์ชั่นที่มองเห็นได้ นี่คือเมื่อการเปรียบเทียบหนี้มีประโยชน์จริง ๆ มันลดลงถึงสิ่งนี้:

ทีมเลือกที่จะทำ DDD ด้วยภาษาที่แพร่หลาย หลงทางจากวิธีนี้โดยปล่อยให้รหัสอยู่ในสถานะไม่สอดคล้องเพิ่มความสับสนและกำจัดผลประโยชน์มากมายที่ DDD และ UL ให้ ในแง่ผู้จัดการมันเพิ่มต้นทุนให้กับโครงการ รหัสจะยากขึ้น (แพง) ในการจัดการและสร้างความสับสนให้กับนักพัฒนาใหม่ (แพง)

คุณอาจต้องการดูตัวเลือกการแปล (l10n) แม้ว่ามันอาจดูไม่รุนแรงเท่าการไปจากภาษาอังกฤษเป็นภาษาสเปน แต่คุณกำลังเผชิญกับคำศัพท์ที่แตกต่างสำหรับแนวคิดเดียวกัน หากสิ่งนี้ดูเหมือนจะเกิดขึ้นโดยทั่วไปแล้วการใช้ l10n จะช่วยให้คุณสามารถเปลี่ยนสิ่งที่ปรากฏในส่วนต่อประสานผู้ใช้อย่างรวดเร็วโดยไม่ต้องเปลี่ยนคำที่ใช้ในรหัส

เมื่อใช้งานแล้วให้ใช้เงื่อนไขในรหัสของคุณซึ่งเป็นที่เข้าใจอย่างกว้างขวางที่สุด เลือกชื่อจากโดเมนตามที่นักพัฒนาทราบและอาจคาดหวัง

ตามที่คุณอธิบายอย่างเหมาะสมการติดตามการเปลี่ยนแปลงระบบการตั้งชื่อผู้ใช้ปลายทางในทุกส่วนของแหล่งเป็นการลงทุน อย่างไรก็ตามมันก็คุ้มค่าแน่นอนโดยเฉพาะอย่างยิ่งสำหรับผลิตภัณฑ์ที่มีอายุการใช้งานยาวนานซึ่งพัฒนาโดยโครงสร้างพื้นฐานที่สมบูรณ์ (พร้อมสายด่วนผู้ทดสอบ ฯลฯ )

การติดตามการตั้งชื่อผู้ใช้ปลายทางในแหล่งที่มาคือการลงทุนเนื่องจากมีองค์ประกอบหลายประเภทที่ปรากฏและไม่มีการใช้งานร่วมกันบนส่วนประกอบเหล่านี้ทั้งหมด บางทีการพัฒนาไม้เท้าวิเศษซึ่งเป็นส่วนประกอบหลังจากส่วนประกอบเป็นการลงทุนที่น่าสนใจที่คุณสามารถเจือจางตลอดอายุการใช้งานของโครงการ

ฉันทำงานกับ codebase อายุ 30 ปีที่มีการเบี่ยงเบนไประหว่างระบบการตั้งชื่อผู้ใช้ปลายทางและระบบการตั้งชื่อภายในเติบโตขึ้นอย่างมากโดยเฉพาะ ต่อไปนี้เป็นข้อบกพร่องบางประการของสถานการณ์นี้ซึ่งทั้งหมดเพิ่มให้กับงานของทุกคน:

1. ในกรณีที่ไม่มีนโยบายที่เพียงพอการพัฒนาใหม่มีแนวโน้มที่จะใช้ระบบการตั้งชื่อผู้ใช้ปลายทางในปัจจุบัน ดังนั้นแนวคิดเดียวกันอาจมีสองชื่อขึ้นไปในองค์ประกอบที่แตกต่างกัน เนื่องจากส่วนประกอบมีการทำงานร่วมกันผลลัพธ์นี้ทำให้เกิดชื่อพ้องความหมายหลายประการที่มีอยู่ในส่วนต่าง ๆ ของรหัส

2. เมื่อมีการโทรสายด่วน / ฝ่ายช่วยเหลือพวกเขาจะเขียนเรื่องราวของผู้ใช้โดยใช้ระบบการตั้งชื่อผู้ใช้ปลายทาง ผู้พัฒนาที่รับผิดชอบการแก้ไขปัญหาจะต้องแปลระบบการตั้งชื่อผู้ใช้ปลายทางเพื่อให้ตรงกับระบบการตั้งชื่อแหล่งที่มา แน่นอนว่ามันไม่ได้ถูกจัดเก็บถาวรและแน่นอนมันเป็นระเบียบ (ดู 1. )

3. เมื่อโปรแกรมเมอร์ debugs รหัสเธอต้องการตั้งค่าเบรกพอยต์ในฟังก์ชั่นที่เกี่ยวข้อง มันยากที่จะหาฟังก์ชั่นที่เหมาะสมหากระบบการตั้งชื่อผู้ใช้ปลายทางและระบบการตั้งชื่อแหล่งไม่เห็นด้วย อาจเป็นเรื่องยากหรือเป็นไปไม่ได้ที่จะมั่นใจได้ว่ารายชื่อของฟังก์ชั่นที่เกี่ยวข้องนั้นสมบูรณ์ (ดู 1. )

4. ในกรณีที่ไม่มีนโยบายที่เพียงพอการบำรุงรักษาแหล่งที่มาโดยใช้คำศัพท์ที่ล้าสมัยเป็นครั้งคราวจะทำให้ระบบการตั้งชื่อที่ล้าสมัยนี้ต่อหน้าผู้ใช้อีกครั้ง สิ่งนี้สร้างความประทับใจที่ไม่ดีและทำให้เกิดค่าใช้จ่าย

ฉันติดตามไปแล้วสองวันแล้วสถานที่ที่ซึ่งข้อมูลบางส่วนถูกอ่านออกจากฐานข้อมูลและฉีดเข้าไปในส่วนประกอบของ codebase นี้ เพราะไม่ว่าฉันหรือใครก็ตามใน บริษัท ที่ฉันทำงานก็สามารถคิดชื่อที่นำไปสู่สถานที่นี้ได้ในที่สุดฉันก็ถูกไล่ออกและตัดสินใจที่จะหาวิธีแก้ไขปัญหาอื่น

ในขณะที่ต้นทุนมากกว่า [1] สองวันของการบำรุงรักษาโดยไม่ยอมอะไร (ไม่มีความรู้ไม่มีการแก้ไขไม่มีอะไร) อาจจะแย่เท่าที่จะได้รับความแตกต่างระหว่างผู้ใช้ระบบการตั้งชื่อและการตั้งชื่อแหล่งเพิ่มค่าใช้จ่าย ซอฟต์แวร์

สิ่งสำคัญคือต้องทราบว่าต้นทุนค่าใช้จ่ายเพิ่มขึ้นกับ บริษัท ที่ผลิตซอฟต์แวร์ในองค์กรขนาดใหญ่รายงานปัญหาจะไม่มาถึงที่โต๊ะทำงานของคุณก่อนที่จะมีการพิจารณาจากเพื่อนร่วมงานหลายคนและการแก้ไขอาจต้องทำการทดสอบ

[1] เนื่องจากมีนักพัฒนามากกว่าหนึ่งคนเข้าร่วม

ฉันไม่ได้เปลี่ยนชื่อรหัสและข้อมูลทุกครั้งเพราะบางแพ็คเกจมีการใช้งานร่วมกันระหว่างลูกค้า พวกเขาโดยทั่วไปใช้สิ่งเดียวกัน แต่เรียกว่าแตกต่างกัน ตัวอย่างใน CMS ลูกค้าหนึ่งรายเรียกลูกค้าว่า "ลูกค้า" และอีกคนใช้ "ลูกค้า" ดังนั้นเราจึงเปลี่ยนลูกค้าเป็นลูกค้าบนพื้นผิวสำหรับลูกค้ารายหนึ่ง แต่ CMS จะเป็นระบบการจัดการลูกค้าเสมอ

อีกตัวอย่างหนึ่งคือการจัดการผู้ใช้ที่มีเงื่อนไขเช่นสิทธิ์เทียบกับรายการควบคุมการเข้าถึงผู้ดูแลระบบ vs ผู้จัดการ ฯลฯ อาจสร้างความสับสนให้กับผู้มาใหม่ แต่สำหรับองค์ประกอบหลักเช่นนั้นมักจะมีนักพัฒนาหลักที่ตรวจสอบให้แน่ใจว่า ยังง่ายต่อการใช้งานโดยนักพัฒนาอื่น ๆ (เช่นโดยการสร้างป้ายกำกับที่กำหนดค่าได้)

มันอาจช่วยให้คิดว่าถ้าคุณทำการเปลี่ยนแปลงนี้หวังว่าคุณจะไม่จำเป็นต้องทำมันอีกครั้งหากลูกค้าคนอื่นใช้ชิ้นเดียวกันนั้นโดยทั่วไปแล้วการเปลี่ยนมันให้กลายเป็นผลิตภัณฑ์