คุณควรสร้างคลาสไดอะแกรมก่อนหรือหลังการใช้งานหรือไม่?

วิธีที่ฉันเห็นหากคุณสร้างขึ้นมาก่อนที่คุณจะได้รับประโยชน์:

• วางแผนล่วงหน้า
• ภาพรวมของโครงการ

แต่คุณจะสูญเสีย:

• เวลา (ทำงานคุณอาจสิ้นสุดซ้ำเมื่อเขียนรหัส)

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

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

หากคุณสร้างก่อนหน้านี้พวกเขาจะเป็นส่วนหนึ่งของขั้นตอนการออกแบบ

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

อย่างไรก็ตามคุณไม่เสียเวลาในการออกแบบ! ส่วนการเข้ารหัสจะเร็วขึ้น และดีกว่า

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

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

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

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

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

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

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

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

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

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

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

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

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

ในการตัดสินใจครั้งสุดท้ายของฉันมีการเปลี่ยนแปลงข้อกำหนดของฉันมากกว่า 50 ครั้งในปีที่แล้ว มันเจ็บปวดจริงๆและ UML ช่วยให้ฉันสามารถติดตามการเปลี่ยนแปลงได้และทำไม UML ควรอนุญาตให้ใช้โมเดลและการรวมโค้ดได้ตลอดเวลาในลักษณะวนซ้ำ (เช่นจากโค้ดไปยังโมเดลจากโมเดลหนึ่งไปอีกโค้ดจากทั้งสองจากรหัสหลังจากทำการปรับโครงสร้างเป็นต้น) ฉันใช้ Omondo EclipseUML สำหรับ Helios และฉันมีความสุขจริงๆ เครื่องมือนี้ คุณสมบัติที่ฉันชอบคือการผสานโมเดลซึ่งทำให้ฉันสามารถอัปเดตโมเดลของฉันได้ตลอดเวลาโดยไม่สูญเสียข้อมูลโมเดล ฉันยังชอบเอนทิตีที่สร้างแบบจำลองโดยตรงในคลาสไดอะแกรมและสร้างฐานข้อมูลโดยใช้กฎตายตัวและไฮเบอร์เนต ทรงพลังและสมบูรณ์แบบจากวัตถุไปยังฐานข้อมูล !!

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

หลัง : มันถูกสร้างขึ้นโดยอัตโนมัติจากรหัสซึ่งเป็นส่วนหนึ่งของกระบวนการสร้างอย่างชัดเจน (หวังว่าคุณจะไม่ยึดติดกับ uml มากเกินไป)

ทั้งสองมีประโยชน์ แต่สิ่งก่อนหน้านี้จะถูกโยนทิ้งทันทีที่นำไปใช้ ... มันล้าสมัยไปแล้ว ณ จุดนี้

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

ฉันจะลงคะแนนให้คำตอบ (C) ไม่ต้องกังวล

พวกมันไม่จำเป็นเลย ส่วนตัวฉันไม่เคยสนใจที่จะดูพวกเขาเมื่อพวกเขามีให้

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

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

แน่นอนคำตอบนี้ฟังดูหยิ่งและดื้อดึงจริงๆ โอ้ดี

ด้วยไอเฟลและเครื่องมือที่เกี่ยวข้องนี่เป็นเพียงความแตกต่างของมุมมองทั้งหมดที่ชี้ไปยังไฟล์ต้นแบบเดียวกัน