วิวัฒนาการในมาตรฐานการเข้ารหัสคุณจะจัดการกับมันอย่างไร


12

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

สมมติว่า codebase ของคุณมีโค้ดประมาณ 500,000 บรรทัด คุณยังต้องการเปลี่ยนรหัสที่มีอยู่ทั้งหมดหรือไม่? หรือคุณจะให้รหัสใหม่เป็นไปตามมาตรฐานใหม่เท่านั้น? โดยทั่วไปสูญเสียความมั่นคง?

คุณจะจัดการกับวิวัฒนาการในมาตรฐานการเข้ารหัสในโครงการของคุณได้อย่างไร

คำตอบ:


16

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

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

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


6

สิ่งที่เราทำคือวิวัฒนาการ (ไม่ใช่การปฏิวัติ) สำหรับฐานของรหัสเราจะใช้มาตรฐานที่อัปเดตเมื่อ;

  • รหัสใหม่จะถูกเขียน
  • รหัสถูก refactored
  • ข้อบกพร่องได้รับการแก้ไข
  • ส่วนใหม่จะถูกเพิ่มไปยังคลาสที่มีอยู่

เป็นสิ่งสำคัญที่ codebase ของคุณจะต้องสอดคล้องกันดังนั้นหากการเปลี่ยนแปลงเปิดโอกาสที่จะเกิดความสับสนระหว่างสไตล์โค้ด "เก่า" และ "ใหม่" มันอาจจะเป็นการดีกว่าที่จะจองการอัปเดตมาตรฐานการเข้ารหัสของคุณในโครงการถัดไป


3

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

ที่กล่าวว่ามีสองกรณีที่ต้องพิจารณาสำหรับการเปลี่ยนแปลงมาตรฐานการเข้ารหัส:

  1. การเปลี่ยนแปลงที่ไม่ส่งผลกระทบต่อความสามารถในการอ่านแม้ว่ารหัสเก่าและรหัสใหม่จะผสมกันโดยไม่ต้องอัปเดตรหัสเดิม
    การเปลี่ยนแปลงเหล่านี้สามารถเพิ่มลงในมาตรฐานการเข้ารหัสได้ทันทีและต้องได้รับการพิจารณาว่ามีผลบังคับใช้สำหรับรหัสใหม่และรหัสที่มีการปรับเปลี่ยนทั้งหมด รหัสเก่าควรปรับเพิ่มขึ้นตามเวลาที่อนุญาตและเมื่อมีการเปลี่ยนแปลงในพื้นที่นั้น
    ตัวอย่างของการเปลี่ยนแปลงประเภทนี้ซึ่งฉันพบจริงคือการเปลี่ยนแปลงคำชี้แจงลิขสิทธิ์ที่จุดเริ่มต้นของแต่ละไฟล์
  2. การเปลี่ยนแปลงที่เสื่อมสภาพความสามารถในการอ่านหากมีการผสมรหัสเก่าและใหม่
    การเปลี่ยนแปลงเหล่านี้ควรนำไปใช้กับ codebase ทั้งหมดในครั้งเดียวหรือควรได้รับการพิจารณาใหม่หากจำเป็นจริงๆ
    ตัวอย่างของการเปลี่ยนแปลงประเภทนี้คือการเปลี่ยนการเยื้องหรือการจัดตำแหน่งรั้ง

2

สิ่งนี้ต้องขึ้นอยู่กับประเภทของผลิตภัณฑ์ที่คุณกำลังสร้าง:

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

1
ฉันจะเพิ่มว่ามันขึ้นอยู่กับการครอบคลุมการทดสอบของคุณ ฉันได้ตรวจสอบอีกครั้งว่ามี 10,000+ บรรทัดที่มีขนาดใหญ่และมีความมั่นใจสูงเนื่องจากฟังก์ชั่นการทำงานที่สำคัญนั้นครอบคลุมโดยการทดสอบการรวมและการทดสอบหน่วย
Martijn Verburg

@ Martijn - จุดดีนี่เป็นความจริง
mrwooster

0

โดยส่วนตัวฉันจะเลือกที่จะเก็บรหัสเก่าตามเดิมและปฏิบัติตามมาตรฐานใหม่จากสิ่งที่คุณทำใหม่ โดยเฉพาะอย่างยิ่งฉันจะไม่ใช้สองมาตรฐานใน old.c แต่ถ้าฉันจะสร้าง new.c ก็สามารถใช้ไวยากรณ์ใหม่ที่ปรับปรุงแล้ว :)


คุณสามารถอธิบายเหตุผลที่อยู่เบื้องหลังตัวเลือกนั้นได้หรือไม่?
Ward Bekker

เอ่อ ... คุณสามารถพูดได้มันเป็นสัญชาตญาณครับ จากสิ่งที่ mrwooster ได้กล่าวไว้ข้างต้นหากเป็นแอพเชิงพาณิชย์ฉันจะไม่เสียเวลาเพียงแค่ทำการเปลี่ยนแปลงเครื่องสำอาง (โปรดจำไว้ว่าการทำงานยังคงเหมือนเดิม) ยิ่งกว่านั้นพูดว่าการเปลี่ยนแปลงไม่เพียง แต่ทำให้คุณสร้างอินสแตนซ์ของวัตถุ แต่ยังพูดว่าคุณเข้าถึงวิธีการอย่างไร จากนั้นจะต้องแก้ไขรหัสจำนวนมากโดยมีโอกาสที่จะแนะนำข้อบกพร่อง ดังนั้นขอให้ชายชราอยู่ที่นั่นดีกว่า
บารัน
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.