วิธีที่ดีที่สุดในการ“ แนะนำ” OOP / OOD กับทีมวิศวกร C ++ ที่มีประสบการณ์


17

ฉันกำลังมองหาวิธีที่มีประสิทธิภาพซึ่งไม่ได้เป็นการดูถูกเพื่อแนะนำแนวคิด OOP ให้กับสมาชิกในทีมที่มีอยู่หรือไม่ เพื่อนร่วมทีมของฉันไม่ใช่คนใหม่สำหรับภาษา OO เราได้ทำ C ++ / C # มาเป็นเวลานานเพื่อให้คุ้นเคยกับเทคโนโลยี

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

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

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

ฉันกำลังคิดที่จะทำการนำเสนอ (หรือชุดข้อมูล) แล้วลองนำ OOP ขึ้นมาอีกครั้งพร้อมกับตัวอย่างของรหัสที่มีอยู่ซึ่งสามารถเขียนได้ดีขึ้นและสามารถนำกลับมาใช้ใหม่ได้ ฉันสามารถใช้โครงการเก่า ๆ ที่ไม่มีใครเป็นเจ้าของอีกต่อไปดังนั้นอย่างน้อยส่วนนั้นไม่ควรเป็นปัญหาที่ละเอียดอ่อน อย่างไรก็ตามมันจะใช้งานได้ไหม อย่างที่ฉันบอกว่าคนส่วนใหญ่ทำ C ++ มานานแล้วดังนั้นฉันเดาว่า a) พวกเขาจะนั่งที่นั่นทำไมฉันบอกพวกเขาถึงสิ่งที่พวกเขารู้แล้วหรือข) พวกเขาอาจจะดูถูกเหยียดหยามเพราะฉัน บอกพวกเขาว่าไม่รู้วิธีทำงานที่พวกเขาทำมานานหลายปีถ้าไม่ใช่ทศวรรษ

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

ฉันไม่ใช่เด็กใหม่จากวิทยาลัยที่มีอุดมการณ์อุดมคติที่ออกแบบมาอย่างสมบูรณ์แบบและฉันไม่คาดหวังจากใครเลย เหตุผลที่ฉันเขียนสิ่งนี้ก็เพราะว่าฉันเพิ่งรีวิวของคนที่มีการออกแบบระดับสูงที่เหมาะสมบนกระดาษ อย่างไรก็ตามถ้าคุณรูปภาพคลาส: A -> B -> C -> D, ในรหัส B, C และ D ทั้งหมดใช้อินเทอร์เฟซสาธารณะที่เหมือนกันเกือบทั้งหมดและ B / C มีฟังก์ชั่นซับเดียวเพื่อให้คลาส A ส่วนใหญ่ทำอย่างแน่นอน ทั้งหมดทำงาน (ลงไปที่การจัดการหน่วยความจำแยกสตริงการเจรจาการติดตั้ง ... ) เป็นหลักใน 4 วิธีการ mongo และสำหรับทุก intents และวัตถุประสงค์โทรเกือบโดยตรงใน D

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


ซ้ำกันเป็นไปได้ - programmers.stackexchange.com/questions/67579
ChrisF

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

หลังจากที่ผมทำโพสต์นี้เกี่ยวข้องเชื่อมโยงโผล่ขึ้นมาว่าเสียงมากเช่นสถานการณ์ของฉัน: programmers.stackexchange.com/questions/43214/... ฉันเป็นห่วงเรื่องเดียวกัน ปัญหาคือทีมของพวกเขามี 2 นักพัฒนาและฉันสามารถจัดการกับการตรวจสอบโค้ดได้อย่างแน่นอน ฉันกำลังมองหาวิธีการที่จะทำงานกับขนาดทีมของเรา (10+) ฉันไม่ได้ติดต่อกับนักพัฒนาทุกคนแบบตัวต่อตัวเท่าที่ฉันต้องการ
DXM

คำตอบ:


5

ทำไมคุณไม่พัฒนาการฝึกอบรมสั้น ๆ ในหลักการของSOLIDและให้การฝึกอบรมนี้แก่พวกเขา? ดูเหมือนว่าจะทำงานได้ค่อนข้างดีสำหรับฉันในองค์กรปัจจุบันของฉันและฉันพบว่าการฝึกอบรมระยะสั้นนั้นสนุกจริง ๆ (สำหรับทุกคนที่เกี่ยวข้อง)

เมื่อฉันให้การฝึกอบรมของฉันฉันใช้เวลาในการค้นหาตัวอย่าง "เลวร้าย" ทางพยาธิวิทยาในรหัสที่มีอยู่ (ของโครงการต่าง ๆ ) และ refactored พวกเขาในงานนำเสนอทีละขั้นตอนโดยใช้หลักการ สิ่งนี้แสดงให้เห็นว่า

  1. ไม่ยากเลยที่จะทำการปรับโครงสร้างเหล่านี้
  2. ใช้เวลาไม่นาน
  3. ผลลัพธ์สุดท้าย (เลือกอย่างระมัดระวัง ;-)) ดีกว่ารหัสต้นฉบับอย่างชัดเจน

5

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

ในหนึ่งโครงการเราทำการออกแบบบทวิจารณ์

15 นาที. ที่กระดานไวท์บอร์ด พูดคุยผ่านการออกแบบก่อนที่จะมีการเข้ารหัส

ส่วนที่สำคัญที่สุดคือการจัดตารางเวลาการตรวจสอบการออกแบบก่อนที่จะดำเนินงานใด ๆ

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

ความคิดเห็นเกี่ยวกับการออกแบบอย่างไม่เป็นทางการ - ก่อนการเข้ารหัส - ไม่มีแรงกดดัน - ไม่มีเอกสารประกอบ - ช่วยให้สามารถอภิปรายได้ดีขึ้นเกี่ยวกับการกำหนดความรับผิดชอบและวิธีการทำงานร่วมกันของวัตถุ


ใช่เราได้ทำการตรวจสอบการออกแบบตามที่คุณอธิบายไว้แล้ว ปัญหาคืองานขนาดกลาง หากงานมีขนาดใหญ่พอฉันมักจะใช้เวลาในการคิดแผนภาพระดับเริ่มต้นซึ่งจะได้รับการปรับปรุงโดยทีม หากงานมีขนาดเล็กการออกแบบระดับสูงที่มีอยู่ก็ดีพออยู่แล้ว อย่างไรก็ตามสำหรับงานขนาดกลางฉันไม่มีความสามารถในการคิดอย่างเพียงพอในการออกแบบดังนั้นกฎพื้นฐานคือ "ใช้วิจารณญาณที่ดีที่สุดและติดตาม OOP" ถ้าฉันจะทำงานเหล่านี้ด้วยตัวเองฉันจะเริ่มต้นด้วยการเขียนโปรแกรมและ intermingle ว่าด้วย refactoring อย่างต่อเนื่องและ ...
DXM

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

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

@Lott: เมื่อไตร่ตรองการตอบสนองของคุณข้อสรุปเดียวของฉันคือว่าคุณพูดถูก ฉันคิดว่าสิ่งที่ฉันควรจะพูดคือฉันได้นำความคิดที่ถูกต้องนี้มาแล้วอย่างน้อย 8 ครั้งและทุกคนเห็นด้วยเสมอ แต่ใช่ถ้าฉันมองย้อนกลับไปตามจังหวะที่เราตัดสินเราไม่ได้ทำอะไรเลย ฉันต้องการจะพูดคุยเกี่ยวกับเรื่องนี้ต่อไป แต่ฉันได้รับการลงโทษทางวินัยจาก mods สำหรับการอภิปรายในเว็บไซต์ถามตอบอย่างเคร่งครัด เราสามารถย้ายเข้าสู่การแชทได้ไหม ฉันต้องการอธิบายสถานการณ์ให้มากขึ้นและอาจหยิบสมองของคุณ (หรือใครก็ตามที่ต้องการเข้าร่วม) สักหน่อย ไม่เคยแชทคุณรู้ไหมว่ามันทำงานยังไง?
DXM

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

4

ฉันสมมติว่าคุณอายุน้อยกว่านักพัฒนาบางคน แต่สูงกว่าในห่วงโซ่อาหาร

ความเสี่ยงที่จะถูกฝังอยู่ในหลุมฝังศพอาจเป็นไปได้ว่า 'วิศวกรที่มีประสบการณ์' กำลังทำสิ่งที่ถูกต้อง - หรือเนื่องจากเป็นผลิตภัณฑ์ที่ครบกำหนดซึ่งอาจมีมานานหลายทศวรรษสิ่งที่ครั้งหนึ่งเคยเป็นสิ่งที่ถูกต้อง

โค้ดที่เก่ากว่ามีแนวโน้มที่จะได้รับการปรับให้ทำงานอย่างรวดเร็วบนฮาร์ดแวร์ของเวลา เหนือสิ่งอื่นใดนี่หมายถึงการลดระดับของการสืบทอดและหลีกเลี่ยงการเรียกใช้ฟังก์ชัน / วิธีการสำหรับการดำเนินการเล็กน้อย

คอมไพเลอร์มีความฉลาดอย่างมากในช่วงหลายปีที่ผ่านมาดังนั้นไม่ใช่ทุกสิ่งที่เคยเป็นจริงในขณะนี้ - ตัวอย่างเช่นคอมไพเลอร์อาจเลือกที่จะอินไลน์ฟังก์ชั่นขนาดเล็ก

บางทีเส้นทางข้างหน้าอาจจะใช้แนวทางที่แตกต่าง - ขอให้ผู้พัฒนาอธิบายว่า / ทำไมวิธีการของพวกเขาดีกว่าทฤษฎีที่คุณสอน - และจริงใจเกี่ยวกับมัน


0

จะผลักดันสำหรับการทดสอบหน่วยที่มีสาขาครอบคลุม 100% ของวิธีการใหม่ / การเปลี่ยนแปลงแต่ละวิธีไม่นำไปสู่การลดการแต่งงานระหว่างวิธี


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

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

0

คุณอาจต้องการหยิบหนังสือ "ลวดลายการออกแบบ" จาก Gang of Four มันไม่เฉพาะเจาะจงสำหรับ C ++ ดังนั้นคุณจึงไม่ได้วิพากษ์วิจารณ์ความรู้ C ++ ของเพื่อนร่วมงานเมื่อคุณอ้างถึง แต่ในขณะเดียวกันก็สามารถจัดการกับหัวข้อที่คุณพิจารณาว่าเกี่ยวข้อง นอกจากนี้หนังสือเล่มนี้ได้รับการยอมรับอย่างกว้างขวางว่ามีความเกี่ยวข้องดังนั้นพวกเขาจึงไม่สามารถปฏิเสธได้ง่าย ๆ ว่าเป็นทฤษฎีหรือไม่สามารถทำได้

ในทางกลับกันให้พิจารณาว่า C ++ ไม่ใช่ภาษา OO บริสุทธิ์ไม่ได้อยู่ในการออกแบบหรือในทางปฏิบัติ เสียงคอนสตรัคเตอร์ / บันทึกความจำทั้งหมดคุณควรแนะนำ RAII ซึ่งไม่ใช่เทคนิค OO เลย แต่เฉพาะกับ C ++ (น่าเสียดาย - IDispose ของ. Net แสดงให้เห็นว่าเกิดอะไรขึ้นเมื่อ RAII เป็นภายหลัง หนังสือที่เกี่ยวข้องที่นี่คือ (มากกว่า) มีผลบังคับใช้ C ++ และ (มากกว่า) เป็นพิเศษ C ++


2
แต่ผู้เขียนระบุไว้อย่างชัดเจนว่ารูปแบบการออกแบบไม่ได้เป็นการแนะนำ OOP / OOD โดยทั่วไป! ผู้ชมควรทำความคุ้นเคยกับเทคนิคของ OOP ก่อนที่จะลงไปในแคตตาล็อกของรูปแบบการออกแบบฮาร์ดโค้ด! "รูปแบบการออกแบบหัวแรก" จะทำให้การแนะนำที่ดี
Falcon

2
ปรากฏขึ้นจากคำอธิบาย OP ที่พวกเขารู้ว่า OOP / OOD พวกเขาไม่ได้ใช้มัน (อาจมาจากความกลัวว่ามันซับซ้อนเกินไป) ในกรณีนี้หนังสือที่อธิบายว่าทำไมมันมีประโยชน์อาจกระตุ้นให้ดีกว่าตัวอย่างโค้ด
wildpeaks

@wildpeaks: OP sais ตรงกันข้าม พวกเขาไม่รู้จัก OOP / OOD พวกเขากำลังเขียนโปรแกรม OOP อย่างเป็นขั้นตอน พวกเขาต้องการสิ่งที่จะแนะนำเทคนิคการออกแบบและหนังสือ GoF ไม่เหมาะกับสถานการณ์นี้
Falcon

ฉันหมายถึงประโยคBut every time I bring up OOP, everyone always nods and makes it seem like they know exactly what I'm talking aboutและMy teammates are not new to OO languagesแต่ฉันสามารถดูว่ามันค่อนข้างคลุมเครือจริง ๆ เพราะพวกเขาอาจโกหกเกี่ยวกับการรู้จัก OOP เมื่อ OP พูดกับพวกเขาเกี่ยวกับเรื่องนี้
wildpeaks

1
@MSalters - คำนำของรูปแบบการออกแบบ: "หนังสือเล่มนี้ไม่ได้มีความรู้เบื้องต้นเกี่ยวกับเทคโนโลยีเชิงวัตถุหรือการออกแบบหนังสือหลายเล่มทำงานได้ดีอยู่แล้วหนังสือเล่มนี้ถือว่าคุณมีความเชี่ยวชาญในภาษาโปรแกรมเชิงวัตถุอย่างน้อยหนึ่งภาษาและคุณ ควรมีประสบการณ์ในการออกแบบเชิงวัตถุด้วย " หนังสือเล่มนี้ไม่ตรงกับความต้องการ พวกเขาควรอ่านข้อมูล OOD ระดับเริ่มต้น
Falcon
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.