คำถามติดแท็ก design

เรามีชั้นข้อมูลที่ล้อมรอบ Linq กับ SQL ในชุดข้อมูลนี้เรามีวิธีนี้ (แบบง่าย) int InsertReport(Report report) { db.Reports.InsertOnSubmit(report); db.SubmitChanges(); return report.ID; } เมื่อส่งการเปลี่ยนแปลงรหัสรายงานจะได้รับการอัปเดตด้วยค่าในฐานข้อมูลที่เราส่งคืน จากด้านการโทรดูเหมือนว่านี้ (ย่อ) var report = new Report(); DataLayer.InsertReport(report); // Do something with report.ID เมื่อดูที่รหัส ID ได้รับการตั้งค่าภายในฟังก์ชั่น InsertReport ว่าเป็นผลข้างเคียงจากนั้นเราจะเพิกเฉยต่อค่าที่ส่งคืน คำถามของฉันคือฉันควรพึ่งพาผลข้างเคียงและทำสิ่งนี้แทน void InsertReport(Report report) { db.Reports.InsertOnSubmit(report); db.SubmitChanges(); } หรือเราควรป้องกันมัน int InsertReport(Report report) { var newReport = …

17 design  code-quality  code-smell 

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

17 design  uml  mdd 

เพื่อนร่วมงานของฉันแนะนำให้ใช้คลาสโรงงานสำหรับการสร้างวัตถุ viewmodel ในโซลูชัน ASP.NET MVC ของเรา ความคิดที่ว่ามันสามารถช่วยในการออกแบบและการบำรุงรักษาของวิธีการดูรุ่นที่สร้างขึ้นในแอพของเรา ฉันต้องการค้นหาว่ามีใครมีประสบการณ์นี้หรือไม่ ฉันได้ทำวิจัยและพบว่าน้อยมากในการฝึกนี้ ขณะนี้เราสร้างวัตถุ viewmodel ที่ระดับคอนโทรลเลอร์เช่น public ActionResult Index() { return this.View(this.BuildIndexViewModel()); } ดังนั้น this.BuildIndexViewModel () มีหน้าที่สร้างคลาส viewmodel (ชัด ๆ :) แต่เรากำลังพิจารณาความเป็นไปได้ของ: public ActionResult Index() { return this.View(ViewModelFactory.CreateIndexViewModel()); } นี่เป็นความคิดที่น่าสนใจ แต่ฉันไม่มั่นใจ 100% ฉันสนใจความเห็นของคนอื่นในเรื่องนี้

17 design  asp.net-mvc 

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

17 design  project-management 

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

17 design  specifications 

ฉันเข้าใจทฤษฎีของ TDD เป็นส่วนใหญ่ แต่ฉันไม่สามารถหาวิธีเริ่มต้นได้ ฉันนั่งลงเพื่อเขียนการทดสอบหน่วยสำหรับโครงการส่วนบุคคลและตระหนักถึง . . ฉันไม่รู้ว่ากำลังทดสอบอะไรอยู่ วัตถุใดฟังก์ชันการทำงาน ฯลฯ เช่นสมมติว่าฉันต้องการเขียนแอพเพื่อช่วยครอบครัวของเราจัดการงานบ้าน ต่อไปนี้เป็นคำถามบางข้อในใจ: ฉันจะเปลี่ยนจากแนวคิดนี้เป็นแบบทดสอบครั้งแรกได้อย่างไร ควรตัดสินใจเท่าไหร่ก่อนที่จะเริ่มและฉันจะรู้ได้มากแค่ไหนหลังจากเริ่มเขียนข้อสอบ? เมื่อใดที่ฉันต้องตัดสินใจว่าจะเก็บข้อมูลในไฟล์ข้อความหรือฐานข้อมูลหรือไม่ ฉันควรมีการทดสอบการยอมรับของผู้ใช้ก่อนที่จะเริ่ม? ฉันควรจะออกแบบ UI หรือไม่ ฉันควรจะมีสเป็คหรือไม่? (ฉันรู้ว่าอย่างน้อยคำถามตัวอย่างเหล่านี้อาจอยู่ใน "พื้นที่สีเทา") นอกจากคำถามชื่อเรื่องเกี่ยวกับการทดสอบหน่วยแรกคุณสามารถให้ตัวอย่างของการทดสอบหน่วยแรกสำหรับโครงการเช่นโครงการตัวอย่างที่อาจมีลักษณะอย่างไร

17 design  tdd 

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

17 project-management  design  self-improvement  planning  specifications 

ปิด คำถามนี้เป็นคำถามความคิดเห็นตาม ไม่ยอมรับคำตอบในขณะนี้ ต้องการปรับปรุงคำถามนี้หรือไม่ อัปเดตคำถามเพื่อให้สามารถตอบข้อเท็จจริงและการอ้างอิงได้โดยแก้ไขโพสต์นี้ ปิดให้บริการใน5 ปีที่ผ่านมา ดูเหมือนว่าจะเป็น Java orthodoxy ณ จุดนี้ว่าโดยทั่วไปไม่ควรใช้เขตข้อมูลสาธารณะสำหรับสถานะวัตถุ (ฉันไม่เห็นด้วยจำเป็น แต่นั่นไม่เกี่ยวข้องกับคำถามของฉัน) ระบุว่ามันจะถูกต้องหรือไม่ที่จะบอกว่าจากที่เราอยู่ทุกวันนี้เป็นที่ชัดเจนว่าสาขาสาธารณะของ Java เป็นข้อผิดพลาด / ข้อบกพร่องของการออกแบบภาษาหรือไม่ หรือมีการโต้แย้งเหตุผลว่าพวกเขาเป็นส่วนที่มีประโยชน์และมีความสำคัญของภาษาแม้วันนี้? ขอบคุณ! อัปเดต:ฉันรู้เกี่ยวกับวิธีที่หรูหรากว่าเช่นใน C #, Python, Groovy เป็นต้นฉันไม่ได้มองหาตัวอย่างเหล่านั้นโดยตรง ฉันแค่สงสัยจริงๆว่ายังมีใครบางคนอยู่ในหลุมหลบภัยพูดพึมพำว่าเขตข้อมูลสาธารณะที่ยอดเยี่ยมเป็นอย่างไรและฝูงทั้งหมดเป็นเพียงแค่แกะ ฯลฯ อัปเดต 2:เขตข้อมูลสาธารณะสุดท้ายคงที่ชัดเจนเป็นวิธีมาตรฐานในการสร้างค่าคงที่สาธารณะ ฉันอ้างถึงการใช้ฟิลด์สาธารณะสำหรับสถานะวัตถุ (แม้แต่สถานะที่ไม่เปลี่ยนรูปแบบ) ฉันคิดว่ามันดูเหมือนว่ามีข้อบกพร่องในการออกแบบที่ควรใช้ฟิลด์สาธารณะสำหรับค่าคงที่ แต่ไม่ใช่สำหรับรัฐ ... กฎของภาษาควรมีการบังคับใช้โดยธรรมชาติด้วยไวยากรณ์ไม่ใช่ตามแนวทาง

17 java  design  history  api  languages 

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

17 design  architecture 

ขณะนี้ฉันกำลังปรับโครงสร้างระบบย่อยขนาดใหญ่ด้วยสถาปัตยกรรมหลายเลเยอร์และฉันพยายามดิ้นรนเพื่อออกแบบกลยุทธ์การบันทึกข้อผิดพลาด \ การจัดการที่มีประสิทธิภาพ สมมติว่าสถาปัตยกรรมของฉันประกอบด้วยสามชั้นต่อไปนี้: ส่วนต่อประสานสาธารณะ (IE เป็น MVC Controller) เลเยอร์โดเมน ชั้นการเข้าถึงข้อมูล แหล่งที่มาของความสับสนของฉันคือที่ฉันควรใช้การบันทึกข้อผิดพลาด \ การจัดการ: ทางออกที่ง่ายที่สุดคือการใช้การบันทึกที่ระดับบนสุด (IE the Public Interface \ MVC Controller) อย่างไรก็ตามสิ่งนี้รู้สึกผิดเพราะมันหมายถึงการทำให้ข้อยกเว้นผ่านเลเยอร์ที่แตกต่างกันแล้วบันทึกมัน แทนที่จะบันทึกข้อยกเว้นที่แหล่งที่มา การบันทึกข้อยกเว้นที่แหล่งที่มานั้นเป็นทางออกที่ดีที่สุดเพราะฉันมีข้อมูลมากที่สุด ปัญหาของฉันคือว่าฉันไม่สามารถตรวจจับทุกข้อยกเว้นที่แหล่งที่มาโดยไม่มีการยกเว้นข้อยกเว้นทั้งหมดและในเลเยอร์อินเทอร์เฟซของโดเมน / สาธารณะสิ่งนี้จะนำไปสู่การตรวจจับข้อยกเว้นที่ถูกจับบันทึกไว้แล้ว . อีกกลยุทธ์ที่เป็นไปได้คือการผสมผสานของ # 1 และ # 2; โดยที่ฉันตรวจจับข้อยกเว้นเฉพาะที่เลเยอร์พวกเขามักจะถูกโยน (IE Catching, การบันทึกและการโยนอีกครั้งSqlExceptionsใน Data Access Layer) แล้วบันทึกข้อยกเว้นที่ไม่ถูกตรวจจับเพิ่มเติมที่ระดับบนสุด อย่างไรก็ตามสิ่งนี้จะทำให้ฉันต้องจับและเชื่อมต่อใหม่ทุกข้อยกเว้นที่ระดับบนสุดเพราะฉันไม่สามารถแยกแยะความผิดพลาดระหว่างข้อผิดพลาดที่ได้รับการจัดการ \ จัดการกับข้อผิดพลาดที่ไม่มี ตอนนี้เห็นได้ชัดว่านี่เป็นปัญหาในแอปพลิเคชั่นซอฟต์แวร์ส่วนใหญ่ดังนั้นจึงต้องมีวิธีแก้ไขปัญหามาตรฐานที่ทำให้เกิดข้อยกเว้นในการจับแหล่งที่มาและบันทึกครั้งเดียว แต่ฉันไม่สามารถเห็นวิธีการทำสิ่งนี้ด้วยตัวเอง หมายเหตุชื่อของคำถามนี้คล้ายกับ ' …

17 design  error-handling 

ฉัน 100% ในคณะกรรมการที่มีกรณีที่หนึ่งควร แน่นอนใช้ทั้งฝั่งไคลเอ็นต์และเซิร์ฟเวอร์ด้านการตรวจสอบข้อมูล อย่างไรก็ตามในกรอบงานและสภาพแวดล้อมที่ฉันได้ทำงานวิธีที่ฉันเห็นไม่เคยแห้ง เวลาส่วนใหญ่ไม่มีแผนหรือรูปแบบ - การตรวจสอบความถูกต้องถูกเขียนในสเป็คโมเดลและการตรวจสอบความถูกต้องจะถูกเขียนในแบบฟอร์มในมุมมอง (หมายเหตุ: ประสบการณ์มือแรกของฉันส่วนใหญ่คือ Rails, Sinatra และ PHP w / jQuery) ดูเหมือนว่ามันจะไม่ยากที่จะสร้างเครื่องกำเนิดไฟฟ้าซึ่งได้รับชุดการตรวจสอบความถูกต้อง (เช่นชื่อรุ่นเขตข้อมูลสภาพ) สามารถผลิตวัสดุทั้งฝั่งไคลเอ็นต์และฝั่งเซิร์ฟเวอร์ที่จำเป็น อีกทางหนึ่งเครื่องมือดังกล่าวสามารถทำการตรวจสอบความถูกต้องฝั่งเซิร์ฟเวอร์ (เช่นvalidatesรหัสในรูปแบบ ActiveRecord) และสร้างการตรวจสอบความถูกต้องฝั่งไคลเอ็นต์ (เช่นปลั๊กอิน jQuery ซึ่งจะถูกนำไปใช้กับแบบฟอร์ม เห็นได้ชัดว่าข้างต้นเป็นเพียง "เฮ้ฉันมีความคิดนี้" รำพึงและไม่ใช่ข้อเสนออย่างเป็นทางการ สิ่งนี้เป็นเรื่องยากกว่าที่คิดเมื่อฉันคิด นั่นนำมาสู่คำถาม: คุณจะออกแบบเทคนิค "การเขียนครั้งเดียวทำงานบนเซิร์ฟเวอร์และไคลเอนต์" ได้อย่างไรเพื่อการตรวจสอบข้อมูล หัวข้อย่อยที่เกี่ยวข้อง: เครื่องมือเช่นนี้มีอยู่สำหรับเฟรมเวิร์กเฉพาะหรือเทคโนโลยีไคลเอ็นต์เซิร์ฟเวอร์หรือไม่? gotchas หรือความท้าทายที่สำคัญด้วยการพยายามรักษาชุดตรวจสอบเพียงชุดเดียวคืออะไร

17 design  validation  dry  client-server 

หลักการความรับผิดชอบเดี่ยวระบุว่า "คลาสควรมีเหตุผลประการเดียวคือการเปลี่ยนแปลง" ในรูปแบบ MVC งานของผู้ควบคุมจะเป็นสื่อกลางระหว่างมุมมองและรูปแบบ มันมีอินเทอร์เฟซสำหรับมุมมองเพื่อรายงานการกระทำของผู้ใช้บน GUI (เช่นการอนุญาตให้ดูการโทรcontroller.specificButtonPressed()) และสามารถเรียกวิธีการที่เหมาะสมในตัวแบบเพื่อจัดการข้อมูลหรือเรียกใช้การดำเนินการ (เช่นmodel.doSomething()) . ซึ่งหมายความว่า: คอนโทรลเลอร์จำเป็นต้องรู้เกี่ยวกับ GUI เพื่อเสนอมุมมองอินเทอร์เฟซที่เหมาะสมเพื่อรายงานการกระทำของผู้ใช้ นอกจากนี้ยังจำเป็นต้องรู้เกี่ยวกับตรรกะในรูปแบบเพื่อที่จะสามารถเรียกใช้วิธีการที่เหมาะสมในรูปแบบ นั่นหมายความว่ามีสองเหตุผลในการเปลี่ยนแปลง : การเปลี่ยนแปลงใน GUI และการเปลี่ยนแปลงในตรรกะธุรกิจ หากมีการเปลี่ยนแปลง GUI เช่นมีการเพิ่มปุ่มใหม่ตัวควบคุมอาจต้องเพิ่มวิธีการใหม่เพื่อให้มุมมองรายงานผู้ใช้กดปุ่มนี้ และหากตรรกะทางธุรกิจในรูปแบบการเปลี่ยนแปลงผู้ควบคุมอาจต้องเปลี่ยนเพื่อที่จะเรียกใช้วิธีการที่ถูกต้องในรูปแบบ ดังนั้นการควบคุมมีสองเหตุผลที่เป็นไปได้ที่จะมีการเปลี่ยนแปลง มันทำลาย SRP หรือไม่

16 design  object-oriented  mvc  single-responsibility 

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

16 java  design  design-patterns  object-oriented-design  static-access 

สำหรับคนไอทีจำนวนมากรวมถึงตัวผมเองเมื่อไม่กี่ปีที่ผ่านมากระบวนการพัฒนาซอฟต์แวร์ที่เหมาะสมจะเกี่ยวข้องกับการสร้างเอกสารการออกแบบอย่างละเอียดพร้อมไดอะแกรม UML จำนวนมากก่อนที่จะมีการเขียนบรรทัดโค้ด (ดูเหมือนว่าคำอธิบายของโมเดลน้ำตก แต่จะเหมือนกันกับว่องไวยกเว้นว่าการทำซ้ำจะเล็กกว่า) ในช่วงสองหรือสามปีที่ผ่านมาฉันเปลี่ยนใจโดยสิ้นเชิง ฉันยังคิดว่าข้อกำหนดรายละเอียดความต้องการพร้อมกรณีทดสอบที่เกี่ยวข้องนั้นเป็นสิ่งจำเป็นอย่างยิ่ง สำหรับโครงการขนาดใหญ่ฉันก็ต้องการโครงร่างของสถาปัตยกรรมโดยรวมก่อนที่จะเริ่มโค้ด แต่ส่วนที่เหลือทั้งหมดควรทำในรหัสมากที่สุด ในกรณีที่เหมาะสมไม่ควรมีคำอธิบายของการออกแบบซอฟต์แวร์ยกเว้นรหัสเอง ฉันมาถึงข้อสรุปนี้ได้อย่างไร นี่คือข้อโต้แย้งบางอย่าง: ผลตอบรับ เครื่องมือสำหรับการเขียนเอกสารหรือสร้างไดอะแกรมนั้นให้ผลป้อนกลับเล็กน้อย ใช่มีเครื่องมือสร้างแบบจำลองที่ทำการตรวจสอบความสอดคล้องบนไดอะแกรม UML แต่มีข้อ จำกัด และมาพร้อมกับค่าใช้จ่ายจำนวนมาก หากไม่มีข้อเสนอแนะมันเป็นการยากที่จะรับรู้และแก้ไขข้อผิดพลาด ทันทีที่คุณเขียนรหัสคุณจะได้รับข้อเสนอแนะมากมายเช่น: ข้อผิดพลาดและคำเตือนจากคอมไพเลอร์ ผลการวิเคราะห์รหัสคงที่ การทดสอบหน่วย สามารถจดจำและแก้ไขข้อผิดพลาดได้อย่างรวดเร็ว ความมั่นคง เพื่อให้แน่ใจว่ารหัสสอดคล้องกับเอกสารของคุณคุณต้องตรวจสอบอีกครั้งและอีกครั้ง หากมีการเปลี่ยนแปลงบ่อยครั้งจะเป็นการยากที่จะทำให้รหัสและเอกสารตรงกัน refactoring มีเครื่องมือและเทคนิคที่มีประสิทธิภาพสำหรับการ refactoring code ในขณะที่การ refactoring textual description หรือไดอะแกรมมักจะยากและเกิดข้อผิดพลาดได้ง่าย มีเงื่อนไขหนึ่งที่จะทำให้งานนี้: รหัสจะต้องง่ายพอที่จะอ่านและทำความเข้าใจ สิ่งนี้อาจไม่สามารถทำได้ด้วย Assembler, Basic หรือ Fortran แต่ภาษาสมัยใหม่ (และห้องสมุด) มีความหมายมากกว่า ดังนั้นหากข้อโต้แย้งของฉันถูกต้องควรมีแนวโน้มไปสู่ข้อกำหนดและเอกสารการออกแบบซอฟต์แวร์ที่มีน้ำหนักเบาหรือน้อย มีหลักฐานเชิงประจักษ์สำหรับแนวโน้มนี้หรือไม่?

16 design  programming-languages  development-process  modeling 

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

16 design  go