วิศวกรรมซอฟต์แวร์

ฉันกำลังตั้งค่าขั้นตอนแรกของฉันในการออกแบบที่ขับเคลื่อนด้วยโดเมนซื้อสมุดสีฟ้าและทั้งหมดและฉันพบว่าตัวเองเห็นวิธีสามวิธีในการนำโซลูชันมาใช้ สำหรับบันทึก: ฉันไม่ได้ใช้ CQRS หรือการจัดหากิจกรรม สมมติว่าคำขอของผู้ใช้มาในเลเยอร์บริการแอพพลิเคชัน ตรรกะทางธุรกิจสำหรับคำขอนั้นคือ (ด้วยเหตุผลใดก็ตาม) ที่แยกออกเป็นวิธีการในเอนทิตีและวิธีการในบริการโดเมน ฉันจะเรียกวิธีการเหล่านั้นได้อย่างไร ตัวเลือกที่ฉันรวบรวมได้มีดังนี้: ให้บริการแอปพลิเคชันโทรทั้งสองวิธี ใช้วิธีการฉีด / ส่งสองครั้งเพื่อฉีดบริการโดเมนลงในเอนทิตีปล่อยให้เอนทิตีทำสิ่งนั้นแล้วปล่อยให้มันเรียกวิธีการบริการโดเมน (หรือวิธีอื่น ๆ ให้บริการโดเมนเรียกวิธีการในนิติบุคคล) เพิ่มเหตุการณ์โดเมนในวิธีเอนทิตีซึ่งเป็นตัวจัดการที่เรียกใช้บริการโดเมน (ประเภทของกิจกรรมโดเมนที่ฉันกำลังพูดถึงคือ: http://www.udidahan.com/2009/06/14/domain-events-salvation/ ) ฉันคิดว่าสิ่งเหล่านี้ใช้ได้จริง แต่ฉันไม่สามารถเลือกระหว่างพวกเขาได้ ฉันเคยคิดเกี่ยวกับเรื่องนี้มานานแล้วและฉันก็มาถึงจุดที่ฉันไม่เห็นความแตกต่างทางความหมายระหว่างทั้งสาม คุณรู้แนวทางบางอย่างเมื่อใช้อะไร

27 c#  patterns-and-practices  domain-driven-design 

อย่าประกาศอินเตอร์เฟสสำหรับวัตถุที่ไม่เปลี่ยนรูป [แก้ไข] เมื่อวัตถุที่เป็นปัญหาแสดงถึง Data Transfer Objects (DTOs) หรือ Plain Old Data (PODs) นั่นเป็นแนวทางที่สมเหตุสมผลหรือไม่? ถึงตอนนี้ฉันมักจะสร้างอินเตอร์เฟสสำหรับคลาสที่ปิดผนึกซึ่งไม่เปลี่ยนรูป (ข้อมูลไม่สามารถเปลี่ยนแปลงได้) ฉันพยายามระวังตัวเองว่าจะไม่ใช้อินเทอร์เฟซที่ใดก็ตามที่ฉันสนใจเกี่ยวกับการไม่เปลี่ยนรูป โชคไม่ดีที่อินเทอร์เฟซเริ่มแพร่หลายรหัส (และไม่ใช่เพียงรหัสของฉันที่ฉันกังวล) คุณเลิกใช้งานอินเทอร์เฟซแล้วต้องการส่งไปยังโค้ดที่ต้องการสมมติว่าสิ่งที่ส่งผ่านไปนั้นไม่สามารถเปลี่ยนแปลงได้ เนื่องจากปัญหานี้ฉันจึงพิจารณาไม่ประกาศส่วนต่อประสานสำหรับวัตถุที่ไม่เปลี่ยนรูป สิ่งนี้อาจมีเครือข่ายที่เกี่ยวข้องกับการทดสอบหน่วย แต่นอกเหนือจากนั้นสิ่งนี้ดูเหมือนจะเป็นแนวทางที่สมเหตุสมผลหรือไม่? หรือมีรูปแบบอื่นที่ฉันควรใช้เพื่อหลีกเลี่ยงปัญหา "อินเตอร์เฟซการแพร่กระจาย" ฉันเห็น? (ฉันใช้วัตถุที่ไม่เปลี่ยนรูปแบบเหล่านี้ด้วยเหตุผลหลายประการ: ส่วนใหญ่เพื่อความปลอดภัยของเธรดเนื่องจากฉันเขียนโค้ดแบบมัลติเธรดจำนวนมาก แต่เพราะมันหมายความว่าฉันสามารถหลีกเลี่ยงการทำสำเนาชุดป้องกันวัตถุที่ส่งผ่านไปยังวิธีต่างๆ หลายกรณีเมื่อคุณรู้ว่าบางสิ่งบางอย่างไม่เปลี่ยนรูป - ซึ่งคุณไม่ได้รับถ้าคุณได้ส่งมอบอินเทอร์เฟซที่จริงแล้วบ่อยครั้งที่คุณไม่สามารถทำสำเนาการป้องกันของวัตถุที่อ้างอิงผ่านทางอินเทอร์เฟซ การดำเนินการโคลนหรือวิธีการทำให้เป็นอนุกรมใด ๆ ... ) [แก้ไข] เพื่อให้บริบทมากขึ้นด้วยเหตุผลของฉันที่ต้องการทำให้วัตถุไม่เปลี่ยนรูปให้ดูโพสต์บล็อกนี้จาก Eric Lippert: http://blogs.msdn.com/b/ericlippert/archive/tags/immutability/ ฉันควรชี้ให้เห็นว่าฉันกำลังทำงานกับแนวคิดระดับล่างบางอย่างที่นี่เช่นรายการที่จัดการ / ส่งต่อในคิวงานแบบมัลติเธรด สิ่งเหล่านี้คือ DTO นอกจากนี้โจชัวโบลชแนะนำให้ใช้วัตถุที่ไม่เปลี่ยนรูปในหนังสือของเขาที่มีประสิทธิภาพชวา ติดตาม ขอบคุณสำหรับความคิดเห็นทั้งหมด ฉันตัดสินใจที่จะไปข้างหน้าและใช้แนวทางนี้สำหรับ DTOs …

27 c#  immutability 

มันเหมาะสมหรือไม่ที่จะใช้ ORM ในการพัฒนา Android หรือเป็นเฟรมเวิร์กที่เหมาะสำหรับการเชื่อมต่อที่แน่นขึ้นระหว่าง UI และเลเยอร์ DB หรือไม่? ความเป็นมา : ฉันเพิ่งเริ่มต้นด้วยการพัฒนา Android และสัญชาตญาณแรกของฉัน (มาจากพื้นหลัง. net) คือการมองหา mapper เชิงสัมพันธ์วัตถุขนาดเล็กและเครื่องมืออื่น ๆ ที่ช่วยลด clode สำเร็จรูป (เช่น POJOs + OrmLite + Lombok ) อย่างไรก็ตามในขณะที่พัฒนาโปรแกรมประยุกต์ของเล่นครั้งแรกของฉันฉัน stumbled เมื่อชั้น UI AlphabetIndexerอย่างชัดเจนว่าต้องใช้เคอร์เซอร์ฐานข้อมูล: นั่นทำให้ฉันสงสัยว่าบางทีห้องสมุด Android อาจไม่เหมาะกับการแยก UI และเลเยอร์ DB อย่างเข้มงวดและฉันจะพลาดคุณสมบัติที่มีประโยชน์และประหยัดเวลามากมายถ้าฉันพยายามใช้ POJO ทุกที่ (แทนที่จะเข้าถึงฐานข้อมูลโดยตรง) ) ชี้แจง : ฉันค่อนข้างตระหนักถึงข้อดีของการใช้ ORM …

27 android  orm  layers  android-development 

ฉันไม่คิดว่า Objective C นั้นถูกใช้ตั้งแต่เริ่มต้นการพัฒนาฮาร์ดแวร์ของ Apple นักพัฒนาแอปใช้ภาษาใดสำหรับคอมพิวเตอร์ Apple รุ่นก่อนเช่น Apple II หรือ Mac Classic

27 history  apple 

มีบทความคลาสสิกชื่อตามเกณฑ์ที่จะใช้ในการย่อยสลายระบบเป็นโมดูลที่ฉันเพิ่งอ่านเป็นครั้งแรก มันสมเหตุสมผลดีสำหรับฉันและอาจเป็นหนึ่งในบทความที่ OOP อ้างอิง ข้อสรุปของมัน: เราพยายามสาธิตโดยตัวอย่างเหล่านี้ว่ามันไม่ถูกต้องเสมอไปที่จะเริ่มการสลายตัวของระบบเป็นโมดูลบนพื้นฐานของแผนผังลำดับงาน ... แต่ละโมดูลได้รับการออกแบบมาเพื่อซ่อนการตัดสินใจจากสิ่งอื่น ในความเห็นที่ไม่มีการศึกษาและไม่มีประสบการณ์ของฉันการเขียนโปรแกรมฟังก์ชั่นใช้คำแนะนำตรงข้ามแน่นอนของบทความนี้ ความเข้าใจของฉันคือการเขียนโปรแกรมการทำงานทำให้การไหลของข้อมูลเป็นสำนวน ข้อมูลถูกส่งผ่านจากฟังก์ชั่นหนึ่งไปยังอีกฟังก์ชั่นแต่ละฟังก์ชั่นจะรับรู้ข้อมูลอย่างใกล้ชิดและ"เปลี่ยน"ไปพร้อมกัน และฉันคิดว่าฉันเคยเห็น Rich Hickey คุยกันในที่ที่เขาพูดถึงว่าการซ่อนข้อมูลนั้นเกินจริงหรือไม่จำเป็นหรืออะไร แต่ฉันจำไม่ได้แน่นอน ก่อนอื่นฉันต้องการทราบว่าการประเมินของฉันถูกต้องหรือไม่ กระบวนทัศน์ของ FP และบทความนี้ขัดแย้งกับปรัชญาหรือไม่? สมมติว่าพวกเขาไม่เห็นด้วย FP จะ "ชดเชย" อย่างไรหากไม่มีการซ่อนข้อมูล บางทีพวกเขาอาจเสียสละการซ่อนข้อมูล แต่ได้รับ X, Y และ Z ฉันต้องการทราบเหตุผลว่าทำไม X, Y และ Z จึงถือว่าเป็นประโยชน์มากกว่าการซ่อนข้อมูล หรือสมมติว่าพวกเขาไม่เห็นด้วย FP อาจรู้สึกว่าการซ่อนข้อมูลไม่ดี ถ้าเป็นเช่นนั้นทำไมจึงคิดว่าการซ่อนข้อมูลไม่ดี สมมติว่าพวกเขาเห็นด้วยฉันต้องการทราบว่าการนำ FPs ไปปฏิบัติใช้ของการซ่อนข้อมูลคืออะไร เห็นได้ชัดใน OOP คุณสามารถมีprivateฟิลด์ที่ไม่มีใครนอกชั้นเรียนสามารถเข้าถึงได้ ไม่มีสิ่งใดที่เปรียบเทียบกับฉันใน FP ฉันรู้สึกว่ามีคำถามอื่น …

27 design  object-oriented  functional-programming  object-oriented-design 

ฉันค่อนข้างใหม่สำหรับวิธีการ TDD และการทดลองครั้งแรกของฉันบอกว่าการเขียนโค้ดฟังก์ชัน 1 บรรทัดหมายถึงการเขียนโค้ดทดสอบประมาณ 2-3 บรรทัด ดังนั้นในกรณีที่ฉันจะเขียน 1,000 LOC, codebase ทั้งหมดรวมถึงการทดสอบจะเป็นอะไรที่เหมือน ~ 3500 LOC นี่ถือว่าเป็นเรื่องปกติหรือไม่ อัตราส่วนในโค้ดที่คุณเขียนคือเท่าใด

27 testing  unit-testing  tdd  metrics 

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

27 object-oriented  object-oriented-design  solid  design-principles  liskov-substitution 

ฉันเป็นนักพัฒนาที่มีระดับ CS และมีประสบการณ์การทำงานในการพัฒนาในหลายภาษาเป็นเวลาเกือบ 3 ปี วันนี้ฉันได้สัมภาษณ์โดยรวมแล้วมันค่อนข้างดีฉันเตรียมตัวสำหรับคำถามส่วนใหญ่และรู้สึกพร้อมสำหรับทุกสิ่ง ในตอนท้ายของการสัมภาษณ์พวกเขาให้คำถามหนึ่งคำถามกับฉัน ... ปัญหาเช่น FizzBuzz (โดยไม่ต้องพิมพ์หมายเลข) ฉันเชื่อว่าฉันทำผิดพลาดมากเกินไปและทำให้ "ล้มเหลว" ความหวังทั้งหมดสูญเสียสำหรับฉันหรือเปล่า นี่คือรหัสของฉัน: void FizzBuzz() { for(int i = 0; i <= 100; i++) { bool isThree = i % 3; bool isFive = i % 5; if (isThree) { print "Fizz\n"; } else if(isFive) { print "Buzz\n"; …

27 interview 

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

27 programming-practices  naming 

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

27 programming-languages  regular-expressions 

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

27 project-management  unit-testing  code-quality  integration-testing 

Cloud computing เป็นรูปแบบการเช่าทรัพยากร - เซิร์ฟเวอร์และการจัดเก็บข้อมูล ทั้งเซิร์ฟเวอร์และที่เก็บข้อมูลนั้นมีมานานกว่าทศวรรษแล้ว แต่ข้อเสนอคลาวด์คอมพิวติ้งก็ปรากฏตัวเมื่อหลายปีก่อน ข้อตกลงที่นี่คืออะไร? อะไรคือการเปลี่ยนแปลงที่สำคัญที่ก่อให้เกิดการยอมรับอย่างมากและการตลาดขนาดใหญ่ของคลาวด์คอมพิวติ้ง

27 history  cloud-computing  technology 

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

27 legal  copyright  appstore 

การแสดงที่มา: สิ่งนี้เกิดจากคำถาม P.SEที่เกี่ยวข้อง พื้นหลังของฉันอยู่ใน C / C ++ แต่ฉันได้ทำงานในจำนวนที่เป็นธรรมใน Java และฉันกำลังเข้ารหัส C # เนื่องจากพื้นหลัง C ของฉันการตรวจสอบพอยน์เตอร์ที่ผ่านและส่งคืนนั้นเป็นของมือสอง แต่ฉันยอมรับว่ามันมีอคติต่อมุมมองของฉัน ฉันเพิ่งเห็นการกล่าวถึงรูปแบบวัตถุ Nullซึ่งแนวคิดก็คือวัตถุจะถูกส่งคืนเสมอ กรณีปกติส่งคืนวัตถุที่คาดหวังที่มีประชากรและกรณีข้อผิดพลาดส่งคืนวัตถุว่างเปล่าแทนตัวชี้โมฆะ สถานที่ตั้งเป็นฟังก์ชั่นการโทรจะมีวัตถุบางอย่างให้เข้าถึงและหลีกเลี่ยงการละเมิดการเข้าถึงหน่วยความจำที่เป็นโมฆะ ดังนั้นข้อดี / ข้อเสียของการตรวจสอบค่า null เมื่อเปรียบเทียบกับการใช้รูปแบบวัตถุ Null คืออะไร ฉันสามารถเห็นรหัสการโทรที่สะอาดขึ้นด้วย NOP แต่ฉันยังสามารถดูได้ว่ามันจะสร้างความล้มเหลวที่ซ่อนอยู่ที่ไม่ได้รับการยก ฉันต้องการให้แอปพลิเคชันของฉันล้มเหลวอย่างหนัก (หรือเป็นข้อยกเว้น) ในขณะที่ฉันกำลังพัฒนามันมากกว่าที่จะมีข้อผิดพลาดเงียบ ๆ หลบเข้าไปในป่า รูปแบบวัตถุ Null ไม่สามารถมีปัญหาที่คล้ายกันกับที่ไม่ทำการตรวจสอบเป็นโมฆะ? วัตถุหลายอย่างที่ฉันได้ทำงานกับวัตถุหรือภาชนะบรรจุของตัวเอง ดูเหมือนว่าฉันจะต้องมีกรณีพิเศษเพื่อรับประกันว่าภาชนะบรรจุวัตถุหลักทั้งหมดมีวัตถุเปล่าของตัวเอง ดูเหมือนว่าสิ่งนี้จะน่าเกลียดด้วยการซ้อนกันหลายชั้น

27 error-handling  null 

ฉันพบว่าตัวเองเขียนโค้ดจำนวนมากเช่นนี้: int myFunction(Person* person) { int personIsValid = !(person==NULL); if (personIsValid) { // do some stuff; might be lengthy int myresult = whatever; return myResult; } else { return -1; } } มันอาจดูยุ่งเหยิงโดยเฉพาะถ้ามีการตรวจสอบหลายครั้ง ในกรณีเช่นนี้ฉันได้ทดลองใช้รูปแบบอื่นเช่นนี้: int netWorth(Person* person) { if (Person==NULL) { return -1; } if (!(person->isAlive)) { return -1; } …

27 coding-style  language-agnostic