คุณคิดว่ารหัสเป็นเอกสารด้วยตนเองหรือไม่? [ปิด]

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

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

จากมุมมองของฉันเองฉันสามารถอ่าน Java, Python, Delphi และอื่น ๆ แต่ถ้าผู้จัดการของฉันมาหาฉันและถามฉันว่าฉันไปไกลแค่ไหนในโครงการฉันและฉันพูดว่า "รหัสนั้นสมบูรณ์ 80%" (และก่อน คุณเริ่มยิงฉันลงฉันได้ยินเรื่องนี้ในสำนักงานสองสามแห่งโดยนักพัฒนา) การบันทึกเอกสารด้วยตนเองเป็นอย่างไร ขอโทษถ้าคำถามนี้ดูเหมือนแปลก แต่ฉันอยากจะถามและรับความคิดเห็นบางอย่างเพื่อให้ได้ความเข้าใจที่ดีขึ้นว่าเหตุใดจึงต้องส่งคนไปสัมภาษณ์

เพียงบางส่วน

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

เปรียบเทียบ:

a->b;
# what is b doing? what is the a object?

carEngine->startIgnition;
# much more clear what objects are involved

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

ไม่รหัสในตัวเองไม่ใช่การจัดทำเอกสารด้วยตนเอง

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

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

รหัสที่เหมาะสมจะบอกคุณว่า " อย่างไร " ความคิดเห็นที่เหมาะสมบอกคุณ " ทำไม "

ดังนั้นรหัสอาจบันทึกเอกสารด้วยตัวเองถึงวิธีที่สิ่งต่าง ๆ ได้รับ แต่คุณไม่สามารถสรุปได้ว่ามันคือเหตุผลว่าทำไม

หากพวกเขายืนยันในคำตอบสีดำและสีขาวโดยไม่อนุญาตพื้นกลางคำตอบคือไม่

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

อะไรก็ได้นอกจากโค้ดที่เล็กน้อยที่สุดจะได้รับประโยชน์จากเอกสารนอกอย่างน้อยบางส่วน

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

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

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

สำหรับการสนทนาที่น่าสนใจเกี่ยวกับข้อดีและข้อเสียของการแสดงความคิดเห็นโปรดดูhttp://www.perlmonks.org/index.pl?node_id=65153สำหรับบทสนทนาเก่า ๆ ที่ฉันเป็นส่วนหนึ่งของ (หมายเหตุในขณะเดียวกันเราก็มีการสนทนานั้นมีการแชทส่วนตัวที่เป็นมิตรกว่าฉันมักจะเสียใจเสมอว่าการสนทนาในเชิงลบมากกว่าครึ่งหนึ่งนั้นเปิดเผยต่อสาธารณชน) ความคิดเห็นของฉันไม่ตรงกับสิ่งที่ฉันคิดอีกแล้ว แต่ฉันก็ยังคิดว่าบทสนทนามีคุณค่ากับอาหารสำหรับความคิด

ฉันพบว่าคำถามนี้เกิดขึ้นมากมายและมักมีความกระตือรือร้นในเรื่องศาสนา นี่คือสิ่งที่ฉันใช้กับมัน ...

ในโลกอุดมคติคำพูดต่อไปนี้สามารถทำได้:

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

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

1. โปรแกรมเมอร์มักจะไม่ใช่ผู้เชี่ยวชาญในอุตสาหกรรมที่พวกเขากำลังเขียนโปรแกรมต่อต้าน ง่ายพอที่จะเข้าใจฟังก์ชั่นเช่นstartEngine(Car car)(ส่วนใหญ่) ทุกคนสามารถเข้าใจสิ่งที่ถูกถามที่นี่ แต่ย้ายไปสู่โลกแห่งความเป็นจริงและสิ่งต่าง ๆ จะเลือนลางเล็กน้อย ตัวอย่างเช่นฟังก์ชั่นgetSess(String tid, String aid)จะเข้าใจได้อย่างสมบูรณ์แบบสำหรับวิศวกรขนส่งที่เข้าใจระบบ DWDM แต่มันสามารถนำเสนอความท้าทายให้โปรแกรมเมอร์ใหม่ที่เพิ่งวางโครงการ ความคิดเห็นที่ถูกวางไว้อย่างดีสามารถช่วยลดการเปลี่ยนภาพเพื่อทำความเข้าใจโค้ดในเวลาที่เหมาะสม

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

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

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

รหัส "การจัดทำเอกสารด้วยตนเอง" ที่เขียนไว้อย่างดีเป็นความสุขที่พบ เขียนอย่าง "ตนเอง documenting" รหัสที่มีวางไว้อย่างดี, ความเห็นข้อมูลเป็นสวรรค์และหายากมาก

เพียงเพื่อให้ข้อโต้แย้งในแต่ละด้านของคำถามเริ่มต้น:

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

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

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

เห็นได้ชัดว่าเขาเป็นโปรแกรมเมอร์ที่มีความรู้ในสไตล์ของ Knuth สำหรับสาวก LP รหัสจะต้องมีการจัดทำเอกสารด้วยตนเองเพื่อให้ถูกต้อง ดังนั้นคำตอบเดียวที่เป็นไปได้คือ "ใช่"

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

ฉันคิดว่าผู้สัมภาษณ์อาจมองหาอะไร: "คุณจะเขียนรหัสเอกสารด้วยตนเองได้อย่างไร" ด้วยนัยว่า "ทัศนคติของคุณที่มีต่อเอกสารประกอบคืออะไร"

ฉันไปบรรยายที่สร้างแรงบันดาลใจจากคนที่ชื่อ Robert C Martin ครั้งหนึ่งที่เขาพูดถึงบท 'วิธีการเขียน' ของ Clean Code ของหนังสือของเขา

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

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

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

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

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

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

ดังนั้นใช่รหัสคือเอกสารด้วยตนเอง มันเป็นเอกสารที่ดีเพียงใดคำถามอื่นทั้งหมด

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

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

ฉันรู้คำตอบที่คนส่วนใหญ่คาดหวังว่าคำถามนั้นจะเป็น "ไม่" แต่ฉันจะตอบว่าใช่ ถ้าฉันถูกถามในการสัมภาษณ์งานฉันจะยังคงตอบว่าใช่

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

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

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

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

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

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

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

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

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