รูปแบบการเข้ารหัสเมื่อใช้หลายไลบรารีที่แตกต่างกัน

ฉันกำลังทำงานกับรหัส C ++ บางตัวที่ใช้หลายไลบรารีรวมถึงบาง C library ที่ทุกคนมีรูปแบบการเข้ารหัสที่แตกต่างกัน มันจะเปิดแหล่งที่มาเมื่อมันมาถึงขั้นตอนที่ใช้งานได้ ซึ่งจะทำให้เกิดความสับสนน้อยที่สุดสำหรับผู้มีส่วนร่วมระยะสั้นที่ตรวจสอบรหัสเพื่อแก้ไขข้อบกพร่องหนึ่งข้อหรือเพิ่มหนึ่งคุณลักษณะ?

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

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

ฉันคิดว่ามันขึ้นอยู่กับว่าโครงการโดยรวมจะจบลงแค่ไหน

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

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

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

ไม่ว่าจะด้วยวิธีใดการตัดสินใจขั้นสุดท้ายควรอยู่กับทีมที่คุณกำลังทำอยู่

ค่าผิดปกติบางอย่างที่อาจเปลี่ยนเหตุผลของฉันจากด้านบน:

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

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

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

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

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

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

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

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

ดูเหมือนจะมีหลายเลเยอร์ที่ต้องพิจารณาอย่างน้อย:

1. ไลบรารีที่มีอยู่และการแก้ไขใด ๆ
2. รหัสการทดสอบหน่วยใหม่สำหรับไลบรารีเหล่านั้น
3. ชั้นที่เป็นนามธรรม
4. API ที่นำเสนอโดยเลเยอร์นามธรรม
5. ตัวอย่างและรหัสทดสอบโดยใช้เลเยอร์นามธรรม

ฉันจะสมมติว่ามันไม่สมเหตุสมผลเลยที่จะต้องปรับโครงสร้างรหัสทั้งหมดให้เป็นสไตล์ที่อยู่ตรงหน้า - หากคุณไม่ได้ถามคำถาม

รับในแต่ละครั้ง:

1. สำหรับรหัสฐานที่มีอยู่แล้วคุณอาจต้องการยึดสไตล์นั้น
2. รหัสทดสอบหน่วยใหม่สำหรับรหัสที่มีอยู่ในพื้นที่สีเทาโดยเฉพาะอย่างยิ่งขึ้นอยู่กับว่ามันถูกรวมเข้ากับรหัสเก่า แต่ส่วนใหญ่ฉันจะพยายามทำให้เป็น 'สไตล์ที่ต้องการ'
3. รหัสใหม่ในชั้นที่เป็นนามธรรม การทำให้แน่ใจว่านี่เป็นเลเยอร์โค้ดที่แยกจากกันจริงๆไม่ควรมีปัญหาในการใช้สไตล์ที่ต้องการแม้ว่ารหัสนั้นจะมีการเชื่อมต่อกับสไตล์หรือสไตล์ดั้งเดิม รหัสส่วนใหญ่ต้องติดต่อกับสไตล์อื่น ๆ และฉันไม่เคยพบปัญหานี้
4. เห็นได้ชัดว่า API นั้นต้องการความคิดสูงสุดและตอบสนองความต้องการใช้งานสูงสุด
5. ตัวอย่างหรือรหัสทดสอบใด ๆ ควรสามารถเขียนในลักษณะที่ต้องการได้เช่นกัน ทั้งนี้ขึ้นอยู่กับความสมบูรณ์ของสิ่งที่เป็นนามธรรม (เช่นซ่อนชั้นที่ต่ำกว่าทั้งหมด) ซึ่งอาจเป็นเรื่องง่ายหรือยาก แน่นอนทำให้แน่ใจว่ารหัสลูกค้าในอนาคตสามารถอ่านได้จะเป็นหนึ่งในวัตถุประสงค์หลักของคุณ

บางสิ่งที่ฉันได้พบเป็นการส่วนตัวก็คือด้วยรหัสฐานขนาดใหญ่:

• การตั้งค่าสไตล์ที่ต้องการและการบังคับใช้สำหรับการเปลี่ยนรหัสนั้นไม่ได้ส่งผลให้เกิดการย้ายรหัสเก่าทั้งหมดไปสู่รูปแบบใหม่อย่างน่าอัศจรรย์

• วิศวกรส่วนใหญ่มักจะชอบโค้ดในสไตล์ที่มีอยู่ในไลบรารีที่กำหนด (มากกว่าหรือน้อยกว่า) การร้องขอเป็นอย่างอื่นส่งผลให้มีการบังคับใช้จำนวนมาก

• การขอสไตล์ที่ต้องการในไลบรารี่ดั้งเดิมนั้นมักจะส่งผลให้มีสไตล์ไม่สอดคล้องกันในไลบรารี่นั้น ดังนั้นสำหรับมาตรฐานที่มีการนำเสนอล้วนๆเมื่อเทียบกับความทนทานของโค้ดมันก็ยากที่จะเห็นประโยชน์มากมาย

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

ฉันจะเห็นด้วยกับ @MetaFight ที่นี่ในกรณีที่คุณกำลังพัฒนาโครงการขนาดใหญ่ที่มีโมดูลบุคคลที่สามจำนวนมาก

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

แต่ประเด็นของฉันคือการสร้าง wrapper สำหรับไลบรารี่ดังกล่าวตามมาตรฐานการเข้ารหัสในแบบที่คุณใช้ไลบรารี่เหล่านี้ผ่าน wrapper เหล่านี้ที่ยังคงรักษาสไตล์การเขียนโค้ดดั้งเดิมของคุณเอาไว้ข้างใน

+1 สำหรับ MetaFight

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

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