มีแนวปฏิบัติที่ดีที่สุดเกี่ยวกับการส่งมอบจากสถาปัตยกรรมเพื่อการพัฒนาหรือไม่?

10

เรากำลังมองหาการปรับปรุงกระบวนการในการส่งมอบงานจากสถาปัตยกรรมเพื่อการพัฒนา

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

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

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

architecture

— Shiraz Bhaiji
แหล่งที่มา

14

ฉันอ่านความคิดเห็นที่นี่บางแห่งที่กล่าวว่าสถาปัตยกรรมเป็นกีฬาของทีม หากคุณส่งมอบจากสถาปนิกไปยังทีมพัฒนาคุณอาจทำผิด

— Ant

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

— S.Robins

1

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

— David Thornley

2

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

— maple_shaft

ในร้านค้าขนาดใหญ่ (และตามมาตรฐาน TOGAF) มีสาขาวิชาสถาปัตยกรรมที่แตกต่างหลากหลาย: องค์กร, ความปลอดภัย, โครงสร้างพื้นฐาน, โซลูชั่น ฯลฯ ฯลฯ การใช้คำว่าสถาปนิกหรือสถาปัตยกรรมด้วยตัวเองนั้นไม่มีความหมาย คำถามดูเหมือนจะเกี่ยวกับ "สถาปัตยกรรมโซลูชัน" และคำตอบคือสถาปนิกโซลูชันควรเป็นสมาชิกสำคัญของทีมพัฒนา

— James Anderson

16

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

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

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

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

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

การออกแบบซอฟต์แวร์ที่แท้จริงและแท้จริงจะเป็นกระบวนการของชุมชนที่เกี่ยวข้องกับนักพัฒนาซอฟต์แวร์ทั้งหมดโดยมีทิศทางระดับสูงมากของกลุ่มสถาปัตยกรรม

— maple_shaft
แหล่งที่มา

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

— S.Robins

5

@ S.Robins ด้วยความเคารพอย่างเต็มที่คำถามของ OP คือวิธีการแก้ปัญหา (คำถามทั้งหมดในเว็บไซต์นี้เกี่ยวกับวิธีการแก้ปัญหา) การเปลี่ยนโครงสร้างทีมเป็นวิธีเดียวที่แท้จริงในการแก้ปัญหา คำแนะนำอื่น ๆ นั้นยอดเยี่ยม แต่พวกเขาเป็นเพียงเครื่องช่วยฟัง พวกเขาไม่ได้ช่วยในระยะยาว

— maple_shaft

2

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

— วินไคลน์

2

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

ขนาดของซอฟต์แวร์
ความซับซ้อน
วัฒนธรรมในองค์กรของคุณ
ความเชื่อ

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

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

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

หวังว่านี่จะช่วยได้

— KeesDijk
แหล่งที่มา

2

ฉันรู้ว่านี่จะไม่ได้รับความนิยมมาก แต่ความคิดเห็นที่คุณทำ

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

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

— Jere
แหล่งที่มา

3

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

— maple_shaft

1

นี่เป็นเรื่องจริง เคล็ดลับคือการหาสมดุลที่เหมาะสม

— Michael

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

— Bill Gribble

1

ฉันไม่เห็นด้วยกับคำตอบของเมเปิ้ลทั้งหมด แต่ไม่มีที่ว่างพอในการแสดงความคิดเห็นเพื่อพูดบิตทั้งหมดของฉัน! ;-)

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

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

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

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

— S.Robins
แหล่งที่มา

+1 และอีก 1,000 ถ้าฉันทำได้! คุณอธิบายเพิ่มเติมเกี่ยวกับคำตอบของฉันอย่างละเอียด architects should first and foremost be facilitators & communicators, and designers secondโดยเฉพาะอย่างยิ่งผมรักคำพูดนี้ นี่คือสิ่งที่ฉันพูดในคำตอบของฉัน ความจริงที่ว่าสถาปนิกกำลังส่งมอบรายละเอียดการออกแบบให้กับนักพัฒนานั้นผิดพลาดอย่างลึกซึ้งและไม่สอดคล้องกับวิธีที่สถาปนิกนำคุณค่ามาสู่องค์กร นี่คือเหตุผลที่ฉันได้รับคำสั่งที่ค่อนข้างรุนแรงในคำตอบของฉันว่าการปรับโครงสร้างองค์กรเป็นคำตอบเดียว

— maple_shaft

1

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

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

— Theo Lenndorff
แหล่งที่มา

0

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

นอกจากนี้ยังมีที่ว่างสำหรับทีมใหม่ที่สร้างสมมติฐานที่ไม่ถูกต้อง

โดยทั่วไปควรมีเอกสารเกี่ยวกับโครงการ, ข้อกำหนดทางเทคนิค, กรณีทดสอบหน่วยและไดอะแกรมลำดับ / คลาส

— Vinoth Kumar CM
แหล่งที่มา

-1

ฉันจะบอกว่ามุมมองคลาสไดอะแกรมการสร้างแบบจำลองเช่นเดียวกับรหัสเป็นวิธีแก้ปัญหา แผนภาพคลาสแสดงมุมมองแบบคงที่ของสถาปัตยกรรมโครงการของคุณ ฉันหมายความว่าคุณมีแพ็คเกจ> คลาส, อินเทอร์เฟซ, enum> คุณสมบัติ, mehtods ฯลฯ ... > ฯลฯ ถ้าคุณดูดี Metamodel UML2 มีโครงสร้างเหมือนกับโครงการ java หรือ dotnet

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

มันใช้งานได้ดีและไม่จำเป็นต้องรู้ UML เพราะคลาสไดอะแกรมนั้นง่ายมากและวิศวกรรมย้อนกลับจะทำงานและสร้างมุมมองกราฟิกของโค้ด การนำทางที่ง่ายมุมมองขั้นสูงและรายละเอียดที่สามารถเพิ่มข้อคิดเห็นได้มากมายด้วยไดอะแกรมเป็นรุ่นล่าสุดเสมอและมองเห็นได้บน CVS โดยตรงในโครงการ แผนภาพคลาส UML ของฉันคือ Magic :-)

— UML_GURU
แหล่งที่มา