ในสภาพแวดล้อมที่คล่องตัวผู้รับผิดชอบสถาปัตยกรรมซอฟต์แวร์


19

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

อาจจะเป็นเจ้าของผลิตภัณฑ์อาจารย์ต่อสู้ทีมต่อสู้หรือคนอื่น?

ป้อนคำอธิบายรูปภาพที่นี่


10
นี่ ... ไม่มีเหตุผล ...
Telastyn

3
การปรากฏตัวของผลิตภัณฑ์และ Sprint backlogs ไม่ส่งผลกระทบต่อผู้ที่รับผิดชอบสถาปัตยกรรมซอฟต์แวร์ คำถามที่ดีกว่าอาจ: ใน Agile Environment ใครเป็นผู้รับผิดชอบสถาปัตยกรรมซอฟต์แวร์
ChargerIIC

ฉันพยายามอัปเดตคำถามเพื่อให้สามารถเข้าใจได้อย่างน้อย ไม่แน่ใจ 100% ว่าฉันทำถูกหรือไม่ ...
FrustratedWithFormsDesigner

คำตอบ:


24

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


5
Pure Agile มีแนวโน้มที่จะปฏิเสธบทบาทจากบนลงล่างเช่น "ผู้จัดการโครงการ" และ "สถาปนิกระบบ" แทนที่จะเลือกปรับบทบาทเหล่านั้นใหม่และกระจายความรับผิดชอบแบบดั้งเดิมไปทั่วทั้งทีม
Jonathan Eunice

6
@JonathanEunice: สิ่งนี้จะเป็นจริงได้อย่างไร ไม่ใช่นักพัฒนาทุกคนที่เป็นสถาปนิกที่ดีเช่นกัน
Giorgio

2
@ JonathanEunice: ดังนั้นคำถามที่ถาม DWD นั้นสมเหตุสมผลแล้ว ฉันไม่เข้าใจ downvotes ทั้งหมด
Giorgio

3
@DaveHillier: บางทีโครงการเหล่านี้มีขนาดใหญ่ แต่สถาปัตยกรรมนั้นง่ายพอ: ผู้พัฒนาจำเป็นต้องกรอกข้อมูลลงในสคีมาที่ค่อนข้างง่ายและซ้ำ ๆ (เช่นเขียนแบบฟอร์มที่คล้ายกันหลายร้อยรายการในแอปพลิเคชันบนเว็บด้วยโมเดลโดเมนที่มีอยู่) . ในทางตรงกันข้ามฉันรู้ว่าทันทีที่แอปพลิเคชันมีความซับซ้อนเพียงพอคุณต้องมีคนดูแลสถาปัตยกรรม (มักจะล่วงหน้า) มิฉะนั้นคุณจะต้องจบลงด้วยความยุ่งเหยิงขนาดใหญ่
Giorgio

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

19

แน่นอนสถาปนิก แต่อาจไม่ใช่สถาปนิกประเภทดั้งเดิม

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

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

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

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

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

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

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

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

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

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

ฉันรู้ว่ามันเยอะมาก

อ้างอิง

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

Weinberg, กลายเป็นผู้นำทางเทคนิค หนังสือเล่มนี้ช่วยให้ฉันเรียนรู้วิธีทำงานในส่วนที่ไม่ใช่สถาปนิกของงานสถาปนิกที่มีประสิทธิภาพ

Appelo, บอร์ดคณะผู้แทนและคณะผู้แทนโป๊กเกอร์ อย่าดูถูกว่าการมอบหมายงานยากเพียงใดและเราดูดสิ่งนั้นมากเพียงใด เรียนรู้การทำงานอย่างมีประสิทธิภาพและสะดวกสบายยิ่งขึ้น


1
กุญแจ 'h' ของคุณนั้นหลบหรือไม่ ;)
Dave Hillier

3
ไม่เดฟ ฉันใช้คำสรรพนาม Spivak (เป็นกลางกับเพศ)
JB Rainsberger

เนื่องจากคำถามเช่น @DaveHillier มีการโพสต์ฉันมักจะใช้ "s / เขา" ... (ขอบคุณสำหรับคำตอบที่ยอดเยี่ยมนี้โดยวิธีการทำให้ความเป็นจริงกลับมาใน "ทีมเป็น / ไม่ / มี / เป็นเจ้าของ ... " cliches)
Marjan Venema

1
@ jdl134679 การควบคุมเวอร์ชันสำหรับการช่วยเหลือ: softwareengineering.stackexchange.com/posts/260541/revisions
JB Rainsberger

1
@ Walrat หลังจากคิดเพิ่มเติมฉันตัดสินใจที่จะชี้แจงประเด็นนี้อีกเล็กน้อย คนที่ใส่ใจจะพยายามเรียนรู้สิ่งที่พวกเขาต้องการที่จะเรียนรู้ แต่น่าจะต้องการการสนับสนุนเช่นผู้ให้คำปรึกษา
JB Rainsberger

10

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

- ประกาศเปรียว

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


9
ฉันชอบ Agile แต่นี่เป็นจุดอ่อนที่สำคัญอย่างหนึ่ง - สถาปัตยกรรมมักถูกละเลยหรือปูด้วยกัน
user949300

1
@ user949300 "Agile" ดังที่ปรากฏในแถลงการณ์ว่ามีน้อยมากเกี่ยวกับสถาปัตยกรรม คุณใช้วิธีใดในการสรุปข้อสรุปนี้ XP จะแนะนำให้คุณปรับโครงสร้างใหม่อย่างไร้ความปราณี คุณชื่นชอบ BUFD หรือไม่?
Dave Hillier

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

@ user949300 นั่นเป็นเพราะทีมไม่ได้จัดระเบียบตัวเองถ้าพวกเขาเป็นพวกเขาจะสื่อสารบ่อยครั้งกับส่วนที่เหลือของทีมเมื่อใดก็ตามที่การตัดสินใจทางสถาปัตยกรรมจะต้องทำและเอกสาร / โต้แย้ง / อภิปรายความคิดเหล่านั้นอย่างถูกต้อง
Rudolf Olah

3

ฉันรู้สึกว่าคำตอบของ "" ผู้รับผิดชอบการออกแบบสถาปัตยกรรมระดับสูงและการตัดสินใจออกแบบ "ขึ้นอยู่กับขนาดและจำนวนทีม

สำหรับหนึ่งหรือสองทีมที่มี 3-7 ในแต่ละทีมจากนั้นทีมที่จัดการตนเองสามารถนำไปสู่การเป็นผู้นำจากสมาชิกอาวุโส

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


1

มีทรัพยากรที่ยอดเยี่ยมจากทีมScaled Agile Framework (SAFe) บนเว็บไซต์ของพวกเขา

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

แก้ไขเพื่อความชัดเจนในการตอบคำถามเพิ่มเติมโดยตรง:

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

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


2
คำถามนี้ตอบคำถามนี้อย่างไร "ใครเป็นผู้รับผิดชอบในการตัดสินใจสถาปัตยกรรมระดับสูงและการตัดสินใจออกแบบ"
ริ้น

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

1

ฉันคิดว่าคำตอบอื่น ๆ ส่วนใหญ่กำลังคิดถึงสิ่งนี้จากมุมมองของการอยู่ในโครงการ

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

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

ดังนั้นในระดับโครงการ Solution Architect จะสร้างสถาปัตยกรรมโครงการ (อาจเป็นซ้ำ ๆ ) และจะได้รับการลงชื่อออกจาก Enterprise Architect

ตอนนี้เพื่อมุ่งเน้นโครงการเปรียว โครงการเปรียวมีข้อกำหนด พวกเขาไม่ได้อยู่ในรูปแบบ "เอกสารความต้องการ" ขนาดใหญ่ แต่กลับเป็นเรื่องราวและเรื่องราวที่ยิ่งใหญ่ Epics เหล่านี้ยังต้องการการวางแผน คุณไม่ได้ส่งทีมนักพัฒนาซอฟต์แวร์ออกไปเมื่อไม่นานมานี้ คุณรู้ในระดับสูงว่าระบบต้องทำอะไรระบบใดบ้างที่จำเป็นต้องมีการโต้ตอบและข้อ จำกัด ด้านฮาร์ดแวร์ / ระบบปฏิบัติการ / ภาษาที่องค์กรมีและแนวทางและข้อ จำกัด ของตัวเลือกสถาปัตยกรรมที่เปิดให้โซลูชั่นสถาปนิก ตัวอย่างเช่นถ้าคุณมุ่งมั่นที่จะ. NET และเซิร์ฟเวอร์ SQL คุณจะต้องทำอย่างยิ่งกรณีที่น่าสนใจในการติดตั้งเว็บไซต์ e-commerce โดยใช้วีโอไอพีโดยใช้ PHP และ MySQL เนื่องจากค่าใช้จ่ายที่เกี่ยวข้องในการสนับสนุนสองฐานข้อมูล, สองภาษา, สองเว็บเซอร์เวอร์ ฯลฯ หรืออีกทางหนึ่งโครงการหนึ่งสามารถเลือกใช้ห้องสมุดที่แตกต่างกันโดยสิ้นเชิง ความรู้สึกและสิ่งนี้อาจมีผลกระทบต่อโครงการในเที่ยวบินอื่น ๆ ทั้งหมด จำเป็นอย่างยิ่งที่จะต้องมีการกำกับดูแลของ Enterprise Architect เพื่อป้องกัน "หนี้ทางสถาปัตยกรรม" ประเภทนี้ไม่ให้เกิดขึ้น


0

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

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

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

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


0

ฉันคิดว่าคำตอบส่วนใหญ่แล้วเน้นว่าทีมไม่ใช่คนเดียวควรทำการตัดสินใจเหล่านี้

สิ่งที่พวกเขาไม่ได้สัมผัสก็คือหลักการเปรียวอื่น:

ความเรียบง่าย - ศิลปะของการเพิ่มปริมาณงานที่ไม่ได้ทำเป็นสิ่งจำเป็น

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

คิดว่า 'การทำสวน' เหนือ 'งานสถาปัตยกรรม' - สร้างวัฒนธรรมการใช้ชีวิตการออกแบบที่เติบโต

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

อ่านอื่น ๆ :

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.