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

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

4
แทนที่เงื่อนไขด้วยความหลากหลายในวิธีที่เหมาะสม?
พิจารณาสองคลาสDogและCatทั้งสองสอดคล้องกับAnimalโปรโตคอล (ในแง่ของภาษาการเขียนโปรแกรม Swift นั่นคืออินเทอร์เฟซใน Java / C #) เรามีหน้าจอที่แสดงรายการสุนัขและแมวที่หลากหลาย มีInteractorคลาสที่จัดการตรรกะเบื้องหลัง ตอนนี้เราต้องการที่จะนำเสนอการแจ้งเตือนการยืนยันให้กับผู้ใช้เมื่อเขาต้องการที่จะลบแมว อย่างไรก็ตามสุนัขจะต้องถูกลบทันทีโดยไม่มีการแจ้งเตือนใด ๆ วิธีที่มีเงื่อนไขจะมีลักษณะเช่นนี้: func tryToDeleteModel(model: Animal) { if let model = model as? Cat { tellSceneToShowConfirmationAlert() } else if let model = model as? Dog { deleteModel(model: model) } } รหัสนี้จะถูก refactored ได้อย่างไร? เห็นได้ชัดว่ามันมีกลิ่น

2
สถาปัตยกรรมระบบแจ้งเตือน
ฉันต้องการสร้างระบบที่จัดการข้อความแจ้งเตือนจากโปรแกรมต่าง ๆ และสามารถประมวลผลการแจ้งเตือนเหล่านั้นไปยังผู้บริโภคที่ไม่ต้องการทางอีเมล ทั้งหมดนี้จะถูกเก็บไว้ในเครือข่ายภายในหนึ่งเครือข่าย ฉันคิดว่าฉันต้องการสถาปัตยกรรมพื้นฐานที่มีลักษณะเช่นนี้: ข้อกังวลหลักที่ฉันมีอยู่ในปัจจุบันคือบิต "ตัวจัดการข้อความ" ซึ่งเป็นสิ่งที่จะเป็น "sort-of-API" ของฉัน ฉันต้องการส่วนประกอบทั้งหมดของระบบนี้เพื่อส่งข้อมูลไปยัง API ซึ่งจัดการการเขียนทั้งหมดไปยังฐานข้อมูล ฉันคิดว่าวิธีนี้ง่ายกว่าเพราะมันช่วยลดความปลอดภัยและช่วยให้ฉันมีการสืบค้น DB ที่ซับซ้อนมากขึ้นในโปรแกรมเดียว ข้อกังวลคือฉันต้องการให้สิ่งนี้เป็นผู้ไม่เชื่อเรื่องภาษา - หมายความว่ารหัสใด ๆ ควรจะสามารถส่งข้อความไปยังตัวจัดการของฉัน - ซึ่งจะตีความพวกเขา ฉันหวังว่าจะทำสิ่งนี้ผ่านไฟล์แบน JSON - หรือผ่านการเรียกใช้ REST ไปยังโปรแกรม (ให้ความยืดหยุ่นกับแอพพลิเคชั่นดาวน์สตรีม) คำถามของฉันคือ - ฉันควรรบกวนตัวจัดการข้อความหรือไม่หรือจะเพิ่มความเรียบง่ายให้อนุญาตการเข้าถึงฐานข้อมูลโดยตรงไปยังแอพพลิเคชั่นดาวน์สตรีมรวมถึงส่วนประกอบอื่น ๆ สองตัว (Management Console และ Alert Manager) ด้วยวิธีนี้พวกเขาสามารถแทรกการแจ้งเตือนใดก็ได้ที่พวกเขาต้องการ - ตราบใดที่ INSERT ในตาราง DB / s นั้นถูกต้อง ฉันไม่ได้เป็นนักออกแบบซอฟต์แวร์โดยการค้าขอตัวฉัน …

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

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

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

2
เหตุใดโปรแกรมเมอร์กำหนดรูปแบบการเขียนโปรแกรมเพื่อแทนที่ C / POSIX สำหรับการขนาน
ผู้ให้บริการสถาปัตยกรรมคอมพิวเตอร์ใหม่พยายามแนะนำรูปแบบการเขียนโปรแกรมใหม่อย่างสม่ำเสมอเช่นเมื่อเร็ว ๆ นี้ CUDA / OpenCL สำหรับ GPGPU และแทนที่ C / POSIX เป็นอินเทอร์เฟซการควบคุมไปยังแพลตฟอร์มแบบคู่ขนาน (Poss & Koening, AM3: สู่ตัวเร่งความเร็ว Unix สำหรับหลายคอร์, 2015) ทำไมนักออกแบบสถาปัตยกรรมจึงพยายามออกแบบโมเดลการเขียนโปรแกรมใหม่เพื่อแทนที่ C / POSIX สำหรับการคำนวณแบบขนาน C / POSIX ไม่เหมาะกับมัลติโปรเซสเซอร์หรือผู้เขียนต้นฉบับของ C / POSIX ไม่จำเป็นต้องใช้การคำนวณแบบขนานในการออกแบบ C / POSIX หรือไม่? หรือเป็นกรณีที่โปรแกรมเมอร์ต้องการความสามารถมากกว่า C / POSIX ที่สามารถส่งมอบได้ดังนั้นจึงหันไปใช้การออกแบบใหม่เช่น CUDA / OpenCL เป็นต้น

5
มุมมองควรไม่ทำการตรวจสอบ
ฉันกำลังอ่าน " ในรูปแบบ MVC ควรจัดการกับการตรวจสอบหรือไม่ " เพราะฉันอยากรู้ว่าตรรกะการตรวจสอบควรอยู่ที่ใดในเว็บไซต์ MVC หนึ่งบรรทัดในคำตอบยอดนิยมจะเป็นดังนี้: "ตัวควบคุมควรจัดการกับการตรวจสอบความถูกต้องโมเดลควรจัดการกับการตรวจสอบความถูกต้อง" ฉันชอบที่ แต่มันทำให้ฉันสงสัยว่าทำไมเราจะไม่ตรวจสอบข้อมูลในมุมมองด้วยเหตุผลหลายประการ: มุมมองมักมีการสนับสนุนการตรวจสอบที่มีประสิทธิภาพ (ไลบรารี JS, แท็ก HTML5) มุมมองสามารถตรวจสอบภายในเครื่องลด IO เครือข่าย UI ได้รับการออกแบบโดยคำนึงถึงประเภทข้อมูลเป็นหลัก (ปฏิทินสำหรับวันที่, ตัวหมุนสำหรับตัวเลข) ทำให้เป็นขั้นตอนเดียวจากการตรวจสอบความถูกต้อง การยืนยันในที่มากกว่าหนึ่งแห่งนั้นตรงกันข้ามกับแนวคิดของ MVC ในการแยกความรับผิดชอบดังนั้น "การทำทั้งสองอย่าง" ดูเหมือนไม่เหมาะสม การตรวจสอบความถูกต้องของข้อมูลในคอนโทรลเลอร์เป็นวิธีการที่โดดเด่นอย่างแท้จริงหรือไม่?
10 architecture  mvc 

2
วัตถุคำขอ HTTP / ตอบสนองควรจะไม่เปลี่ยนรูป?
ฉันคิดว่ามันปลอดภัยที่จะบอกว่าเว็บแอปพลิเคชั่นส่วนใหญ่มีพื้นฐานมาจากกระบวนทัศน์คำขอ / การตอบสนอง PHP ไม่เคยมีสิ่งที่เป็นนามธรรมของวัตถุเหล่านี้ กลุ่มหนึ่งพยายามแก้ไขสิ่งนี้: https://github.com/php-fig/fig-standards/blob/master/proposed/http-message.md อย่างไรก็ตามพวกเขาได้รับการติดตามด้านการเปลี่ยนแปลงไม่ได้ ในอีกด้านหนึ่งวัตถุขอ / ตอบสนองโดยทั่วไปต้องการการเปลี่ยนแปลงเพียงเล็กน้อยระหว่างวงจรชีวิตของพวกเขา ในทางกลับกันวัตถุตอบสนองโดยเฉพาะอย่างยิ่งมักจะต้องการส่วนหัว HTTP ที่จะเพิ่ม นอกจากนี้ความไม่สามารถเปลี่ยนแปลงได้นั้นไม่เคยเกิดขึ้นในดินแดนของ PHP ผู้คนเห็นประโยชน์อะไรในการใช้ออบเจ็กต์คำขอ / การตอบสนองที่ไม่เปลี่ยนแปลง สมมติว่าคุณส่งคืนวัตถุ json $response = new JsonResponse($item); ดีและเรียบง่าย แต่ปรากฎว่าการร้องขอนั้นเป็นการร้องขอ Cross-Origin Resource Sharing (CORS) รหัสที่สร้างการตอบสนองไม่ควรสนใจ แต่บางแห่งดาวน์สตรีมเป็นกระบวนการที่จะเพิ่มส่วนหัวควบคุมการเข้าถึงที่จำเป็น มีข้อได้เปรียบใด ๆ ในการรักษาการตอบกลับดั้งเดิมและสร้างขึ้นใหม่ด้วยส่วนหัวเพิ่มเติมหรือไม่ หรือเป็นคำถามเกี่ยวกับสไตล์การเขียนโปรแกรมอย่างเคร่งครัด วัตถุคำขอมีความน่าสนใจขึ้นอีกเล็กน้อย มันเริ่มต้นเหมือนกัน: $request = new Request('incoming request information including uri and headers'); ไม่จำเป็นต้องเปลี่ยนข้อมูลเริ่มต้น …

2
ใช้แพ็คเกจ (อัญมณีไข่ ฯลฯ ) เพื่อสร้างสถาปัตยกรรมที่แยกออก
ประเด็นหลัก เห็นการสนับสนุนที่ดีมากที่สุดแพลตฟอร์มการเขียนโปรแกรมที่ทันสมัยมีการบริหารจัดการแพคเกจ (คิดว่าgem, npm, pipฯลฯ ) ไม่ได้ทำให้ความรู้สึกในการออกแบบโปรแกรมหรือระบบจะประกอบด้วยแพคเกจการพัฒนาภายในเพื่อส่งเสริมและสร้างสถาปัตยกรรมคู่หลวม? ตัวอย่าง ตัวอย่างนี้จะสร้างแพคเกจสำหรับการเข้าถึงฐานข้อมูลรวมถึงการตรวจสอบและส่วนประกอบอื่น ๆ ของระบบ แน่นอนว่าใช้แพ็คเกจภายนอกด้วย จากนั้นระบบของคุณจะนำเข้าและใช้แพ็คเกจเหล่านี้แทนที่จะรวมรหัสไว้ในฐานรหัสของตนเอง การพิจารณา สำหรับฉันดูเหมือนว่าสิ่งนี้จะส่งเสริมการแยกรหัสและช่วยให้สามารถบำรุงรักษาได้เกือบจะเป็นแอพพลิเคชั่นบนเว็บเทียบกับเดสก์ท็อป (มีการใช้งานการอัปเดตเกือบอัตโนมัติโดยใช้ฐานรหัสเดียวสำหรับการใช้งานเดียว ดูเหมือนว่าแนวคิดการออกแบบที่สมเหตุสมผลและมีเหตุผลหรือไม่ สิ่งนี้ใช้จริง ๆ แล้วเป็นวิธีมาตรฐานในการสร้างแอพพลิเคชั่นในปัจจุบันหรือไม่?

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

2
จะตรวจสอบกฎโมเดลโดเมนที่ขึ้นกับเนื้อหาของฐานข้อมูลได้ที่ไหน
ฉันกำลังทำงานกับระบบที่อนุญาตให้ผู้ดูแลระบบกำหนดฟอร์มที่มีฟิลด์ แบบฟอร์มที่กำหนดจะถูกใช้เพื่อป้อนข้อมูลไปยังระบบ บางครั้งแบบฟอร์มจะถูกกรอกโดยมนุษย์ผ่าน GUI บางครั้งแบบฟอร์มจะถูกกรอกตามค่าที่รายงานโดยระบบอื่น สำหรับแต่ละฟิลด์ผู้ดูแลระบบสามารถกำหนดกฎการตรวจสอบที่ จำกัด ค่าที่อนุญาตสำหรับฟิลด์ กฎการตรวจสอบสามารถเป็นอะไรก็ได้จาก "ค่าที่ป้อนในฟิลด์ต้องเป็นจริงหรือเท็จ" ถึง "ค่าที่ป้อนในฟิลด์ต้องมีอยู่ในคอลัมน์ A ของตาราง B ในฐานข้อมูล" ผู้ดูแลระบบสามารถเปลี่ยนแปลงกฎการตรวจสอบสำหรับฟิลด์ได้ตลอดเวลา ในสถานการณ์นี้ความคิดเห็นของคุณเป็นสถานที่ที่เหมาะสมที่สุดสำหรับการตรวจสอบว่าแต่ละเขตข้อมูลถูกกรอกอย่างถูกต้องหรือไม่ ฉันมีสองวิธีหลักในใจ: ตัวเลือก # 1: ตรวจสอบความถูกต้องในรูปแบบโดเมน แต่ละวัตถุฟิลด์จะมีกฎการตรวจสอบที่ระบุโดยผู้ดูแลระบบ วัตถุฟิลด์จะมีการอ้างอิงถึง IValidator เมื่อมีความพยายามในการตั้งค่าของฟิลด์ฟิลด์จะผ่านค่าที่กำหนดและกฎการตรวจสอบไปยัง IValidator หากค่าที่ระบุไม่ถูกต้องจะมีการโยน ValidationException และจัดการอย่างเหมาะสมใน GUI / อินเตอร์เฟสไปยังระบบอื่น ข้อดี: การป้องกันที่แข็งแกร่งสำหรับฟิลด์ที่ถูกกำหนดค่าโดยไม่ตั้งใจซึ่งละเมิดกฎการตรวจสอบ จุดด้อย: Data Access Layer ต้องสามารถผ่านการตรวจสอบและสร้างเขตข้อมูลที่ละเมิดกฎการตรวจสอบปัจจุบัน แม้ผู้ดูแลระบบจะเปลี่ยนกฎการตรวจสอบสำหรับเขตข้อมูล แต่เรายังจำเป็นต้องสร้างวัตถุเขตข้อมูลตามข้อมูลเก่าเช่นเมื่อแสดงแบบฟอร์มที่กรอกข้อมูลเมื่อหลายปีก่อน สิ่งนี้อาจแก้ไขได้โดยการเก็บกฎการตรวจสอบปัจจุบันเมื่อใดก็ตามที่เราเก็บฟิลด์ ในการออกแบบนี้โมเดลฟิลด์มีลิงก์ทางอ้อมไปยัง Data Access Layer / Repository …

2
ฉันจะออกแบบเกมการ์ดได้อย่างไร
ฉันไม่สามารถสร้างสถาปัตยกรรมที่ดีสำหรับเกมไพ่ของฉันได้ ฉันต้องการความช่วยเหลือในการทำความเข้าใจว่าเกมได้รับการออกแบบมาอย่างไร ก่อนอื่นฉันจะอธิบายกฎของเกม กฎของเกม ติดตั้ง มีผู้เล่นสี่คนผู้เล่นสองคนรวมกันเป็นทีม ผู้เล่นแต่ละคนจะได้รับไพ่สับ 12 ใบ มีไพ่ตาบอด 4 ใบบนโต๊ะ (ริมแม่น้ำ) คำสั่งของผู้เล่นเป็นเช่นนี้ การพนัน ผู้เล่นแต่ละคนสามารถผ่านหรือเลือกตัวเลขที่มากกว่าเดิมพันปัจจุบันระหว่าง 100 ถึง 160 การเดิมพันเริ่มต้นจากผู้เล่นคนแรกและแวดวงจนกว่าทีมจะผ่าน เมื่อผู้เล่นผ่านพวกเขาไม่สามารถเดิมพันได้อีกต่อไป ทีมที่ชนะในรอบการเดิมพันควรมีคะแนนอย่างน้อยเท่ากับการเดิมพันเพื่อที่จะชนะเกม ทีมที่แพ้ในรอบการเดิมพันไม่ควรอนุญาตให้ทีมของพวกเขาบรรลุเป้าหมาย หากทีมที่ชนะการเดิมพันรอบได้คะแนนทั้งหมดทีมอื่น ๆ จะได้รับคะแนนลบเท่ากับการเดิมพันของพวกเขา หากทีมที่แพ้ในรอบการเดิมพันรวบรวมคะแนนทั้งหมดทีมอื่นจะได้รับคะแนนติดลบสองเท่า การไหลของเกมและคะแนนสะสม ผู้เล่นที่ชนะการเดิมพันรอบ ( ราชา ) จะได้รับไพ่ที่เหลือสี่ใบบนโต๊ะ จากนั้นเธอ / เขาสามารถบันทึกไพ่สี่ใบในธนาคารการ์ดของทีมโดยไม่ต้องเล่น กษัตริย์จะเลือกชุดสูทเป็นชุดไม้บรรทัดและให้คนอื่นรู้ว่า King เริ่มเกมโดยวางไพ่จากมือของเขา / เธอวางบนโต๊ะ ผู้เล่นแต่ละคนควรเล่นตามลำดับนี้ หากพวกเขามีไพ่ชุดเดียวกันในมือพวกเขาจะต้องเล่นไพ่ใบใดใบหนึ่ง หากพวกเขาไม่มีมันพวกเขาสามารถเล่นชุดอื่น ๆ หลังจากผู้เล่นคนอื่น ๆ เล่นด้วยมือผู้ชนะในรอบจะเป็น: ผู้ที่มีไพ่สูงสุดถ้าไพ่ทั้งหมดเหมือนกัน ผู้ที่มีไพ่ …

3
เราสามารถเพิ่มการไหลของข้อมูลระหว่างส่วนต่าง ๆ ของรหัสฐานขนาดใหญ่ได้ง่ายขึ้นหรือไม่
เมื่อทำการเปลี่ยนแปลงกับระบบขนาดใหญ่ฉันมักประสบปัญหาว่าบางส่วนของฟังก์ชั่นจำเป็นต้องได้รับข้อมูลบางอย่างจากอีกส่วนหนึ่ง แต่พวกมันอยู่ในส่วนต่าง ๆ ของทรีเรียกที่ลึกและแตกแขนงซึ่งอาจไหลผ่านผู้ฟังเหตุการณ์ เป็นต้นด้วยวิธีนี้การเปลี่ยนแปลงอย่างง่ายสามารถทำให้บอลลูนได้อย่างรวดเร็ว ข้อความอ้างอิงจาก Yossi Kreinin บล็อกโพสต์ที่http://www.yosefk.com/blog/i-want-a-struct-linker.html : คุณมีโครงสร้างข้อมูลบางอย่างที่คุณผ่านไปมาก ในไม่ช้าสิ่งที่มีค่าที่สุดเกี่ยวกับโครงสร้างไม่ใช่ข้อมูลที่เก็บไว้ แต่ความจริงที่ว่ามันมีอยู่ตลอดทางผ่านการควบคุมที่ไหลลื่น ตัวแปรทั่วโลกเป็นวิธีคลาสสิกวิธีหนึ่งในการปล่อยให้รหัส "ตะโกนออก" ไปยังรหัสที่อยู่ไกล แต่พวกเขารู้ว่าเป็นปัญหา ตัวแปรที่กำหนดขอบเขตแบบไดนามิกเป็นวิธีที่ จำกัด มากขึ้น แต่ก็มีปัญหาเช่นกัน มีการวิจัยภาษาโปรแกรมเพื่อแก้ไขปัญหานี้หรือไม่? เราสามารถเพิ่มการไหลของข้อมูลที่ไม่คาดคิดลงในฐานข้อมูลขนาดใหญ่ได้ง่ายขึ้นหรือไม่ในขณะที่ยังคงมีการตรวจสอบแบบคงที่การทดสอบหน่วยง่ายและสารพัดอื่น ๆ

5
วิธีการลดการเชื่อมต่อแน่นระหว่างแหล่งข้อมูลสองแห่ง
ฉันมีปัญหาในการหาวิธีแก้ไขปัญหาสถาปัตยกรรมที่เหมาะสมต่อไปนี้ ในการตั้งค่าของเรา (ร่างด้านล่าง)เรามี 2 แหล่งข้อมูลโดยที่แหล่งข้อมูล A เป็นแหล่งข้อมูลหลักสำหรับรายการประเภท Foo แหล่งข้อมูลรองมีอยู่ซึ่งสามารถใช้เพื่อดึงข้อมูลเพิ่มเติมใน Foo; อย่างไรก็ตามข้อมูลนี้ไม่ได้มีอยู่เสมอ นอกจากนี้แหล่งข้อมูล A สามารถใช้เพื่อดึงรายการประเภทบาร์ อย่างไรก็ตามแต่ละบาร์อ้างถึง Foo ความยากของที่นี่คือแต่ละแถบควรอ้างถึง Foo ซึ่งถ้ามีจะมีข้อมูลที่เพิ่มขึ้นโดยแหล่งข้อมูล B คำถามของฉันคือวิธีลบข้อต่อแน่นระหว่าง SubsystemA.1 และ DataSourceB

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

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