คำอธิบายสถาปัตยกรรมเป็นเอกสารที่ละเมิดหลักการ DRY หรือไม่

11

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

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

— ไมเคิล
แหล่งที่มา

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

— luis.espinal

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

— Michael

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

— luis.espinal

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

— luis.espinal

1

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

— Michael

11

การทำซ้ำความคิดของคุณเป็นรหัสเป็นการละเมิดหลักการ DRY หรือไม่

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

— P Shved
แหล่งที่มา

7

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

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

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

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

— Mike Dunlavey
แหล่งที่มา

4

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

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

1

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

— luis.espinal

2

คำอธิบายสถาปัตยกรรมไม่ละเมิดหลักการ DRY

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

เอกสารสถาปัตยกรรมของคุณควรเป็นเหมือนย่อหน้าแรกของรายงานข่าว: เป็นโครงร่าง, สรุป, แผนงานของโครงการ

— Frank Shearar
แหล่งที่มา

1

หากคุณลงวันที่เอกสารมันจะอธิบายสถาปัตยกรรมในขณะที่เขียน

ในขณะที่รหัสแสดงถึงสถาปัตยกรรมในขณะนี้

สองสิ่งแยกกัน - ไม่ใช่ความรู้เดียวกัน

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

— ไม่มีใคร
แหล่งที่มา

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

— luis.espinal