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

ถาม - ตอบสำหรับมืออาชีพนักวิชาการและนักเรียนที่ทำงานในวงจรการพัฒนาระบบ

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

4
การปรับโครงสร้างใหม่ - เหมาะสมหรือไม่ที่จะเขียนรหัสใหม่อีกครั้งตราบใดที่การทดสอบทั้งหมดผ่าน?
ฉันเพิ่งดู"ทุกสิ่งเล็ก ๆ น้อย ๆ "จาก RailsConf 2014 ในระหว่างการพูดคุยนี้ Sandi Metz refactors ฟังก์ชั่นที่รวมถึงคำสั่ง if ซ้อนขนาดใหญ่: def tick if @name != 'Aged Brie' && @name != 'Backstage passes to a TAFKAL80ETC concert' if @quality > 0 if @name != 'Sulfuras, Hand of Ragnaros' @quality -= 1 end end else ... end ... …

3
ทำไมการใช้ตัวดำเนินการที่ได้รับมอบหมายหรือลูปหมดกำลังใจในการเขียนโปรแกรมใช้งานได้?
หากฟังก์ชั่นของฉันมีคุณสมบัติตรงตามข้อกำหนดสองข้อข้างล่างฉันเชื่อว่าฟังก์ชั่นSum จะคืนค่าการสรุปของรายการในรายการที่รายการประเมินเป็นจริงสำหรับเงื่อนไขที่กำหนดมีคุณสมบัติเหมาะสมที่จะเรียกว่าเป็นฟังก์ชันบริสุทธิ์ใช่ไหม 1) สำหรับชุด i / p ที่กำหนดจะส่งคืน o / p เดียวกันโดยไม่คำนึงถึงเวลาที่เรียกใช้ฟังก์ชัน 2) มันไม่มีผลข้างเคียงใด ๆ public int Sum(Func<int,bool> predicate, IEnumerable<int> numbers){ int result = 0; foreach(var item in numbers) if(predicate(item)) result += item; return result; } ตัวอย่าง: Sum(x=>x%2==0, new List<int> {1,2,3,4,5...100}); เหตุผลที่ฉันถามคำถามนี้เพราะฉันเห็นเกือบทุกที่ที่ผู้คนแนะนำให้หลีกเลี่ยงการมอบหมายและลูปเพราะมันเป็นรูปแบบการเขียนโปรแกรมที่จำเป็น ดังนั้นสิ่งที่สามารถไปผิดกับตัวอย่างข้างต้นซึ่งทำให้การใช้ลูปและผู้ประกอบการที่ได้รับมอบหมายในบริบทของการเขียนโปรแกรมฟังก์ชั่น?

2
รูปแบบพื้นที่เก็บข้อมูลกับการสร้างวัตถุ DAL
เท่าที่ผมได้เรียนรู้ที่ควรมีIRepository CRUDจากนั้นเราจะสืบทอดสิ่งนี้IRepositoryในอินเทอร์เฟซอื่นของเราที่ชอบIProductและใช้IProductคลาสที่เป็นรูปธรรมProductRepositoryด้วยวิธีการเช่นGetAllProducts(), Top5Products(). เราสามารถทำเช่นเดียวกันกับสถาปัตยกรรมระดับ n เช่นการสร้างDAL Class Libraryและในนั้นกำหนดชั้นเรียนProductด้วยวิธีการเช่น,GetAllProducts()Top5Products() ทั้งในDAL.ProductและRepo.ProductRepositoryชั้นเรียนที่เราเริ่มต้นDB ContextของEntity Frameworkและสอบถามข้อมูลที่เกี่ยวข้องของเรา การโทรคล้ายกันทั้งในRepo.ProductRepositoryหรือDAL.ProductจากวิธีการBLL ในมุมมองของความคล้ายคลึงกันเหล่านี้คำถามของฉัน Repos มีประโยชน์อย่างไร? ฉันสามารถทำเช่นเดียวกันกับความสะดวกมากโดยใช้สถาปัตยกรรม n ชั้นด้วย ( Controller, BLL Class Library, DAL Class Library)

6
Dijkstra ตั้งใจที่จะทำโค้ดให้เป็นมาตรฐานหรือไม่เมื่อเขาเขียนเกี่ยวกับการแยกข้อกังวล?
ก่อนอื่นฉันอ่านข้อความที่ตัดตอนมาของ Edsger W. Dijkstra ในปี 1974 "ในบทบาทของความคิดทางวิทยาศาสตร์": ให้ฉันพยายามอธิบายให้คุณฟังว่าอะไรคือรสนิยมของฉันสำหรับการคิดที่ชาญฉลาด มันคือว่าเราเต็มใจที่จะศึกษาในเชิงลึกในแง่มุมของเนื้อหาที่แยกออกมาเพื่อความมั่นคงของตัวเองตลอดเวลาที่รู้ว่าคนนั้นครอบครองตัวเองด้วยแง่มุมใดด้านหนึ่งเท่านั้น เรารู้ว่าโปรแกรมจะต้องถูกต้องและเราสามารถศึกษาได้จากมุมมองนั้นเท่านั้น เรารู้ด้วยว่ามันควรจะมีประสิทธิภาพและเราสามารถศึกษาประสิทธิภาพของมันในอีกวันหนึ่ง ในอีกอารมณ์หนึ่งเราอาจถามตัวเองว่าและถ้าเป็นเช่นนั้น: ทำไมโปรแกรมนี้จึงเป็นที่ต้องการ แต่ไม่มีสิ่งใดได้รับ - ในทางตรงกันข้าม! - โดยจัดการกับแง่มุมต่าง ๆ เหล่านี้พร้อมกัน บางครั้งฉันก็เรียกว่า "การแยกความกังวล" ซึ่งแม้ว่าจะเป็นไปไม่ได้อย่างสมบูรณ์ก็ตาม ยังเป็นเทคนิคเดียวที่มีอยู่สำหรับการจัดลำดับความคิดของคน ๆ หนึ่งที่ฉันรู้ นี่คือสิ่งที่ฉันหมายถึงโดย "การมุ่งความสนใจไปที่บางแง่มุม": มันไม่ได้หมายถึงการเพิกเฉยต่อแง่มุมอื่น ๆ มันแค่ทำความยุติธรรมกับข้อเท็จจริงที่ว่าจากมุมมองของแง่มุมนี้มุมมองอื่น ๆ นั้นไม่เกี่ยวข้อง มันเป็นหนึ่งในใจและหลายแทร็คพร้อมกัน ฉันเห็นการแยกข้อกังวลที่ทันสมัยพูดคุยเกี่ยวกับการทำให้โค้ดของคุณเป็นโมดูล อย่างไรก็ตามการอ่านคำพูดข้างต้นฉันเข้าใจว่านี่คือการมุ่งความคิดของคุณไปที่งานหนึ่งโดยเฉพาะในขณะที่ไม่ได้มุ่งเน้นด้านอื่น ๆ นี่ไม่ได้แปลว่าจำเป็นต้องแบ่งรหัสออกเป็นส่วนย่อย ๆ กล่าวคือมีโค้ดอยู่ข้างหน้าคุณว่าในไฟล์เดียวมีแนวคิดของมุมมองพื้นที่เก็บข้อมูลตัวควบคุมการจัดการเหตุการณ์โรงงาน ฯลฯ ทั้งหมดในไฟล์เดียว สำหรับตัวอย่างสั้น ๆ นี่คือโค้ดบางส่วนที่มีการเข้าถึงข้อมูลและมุมมอง (เอาต์พุต): $sql = "SELECT * …

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

1
ชื่อของเทคนิคสำหรับอาร์กิวเมนต์ประเภทอนุมานของพารามิเตอร์ชนิดหรือไม่
ตั้งค่า:สมมติว่าเรามีประเภทที่เรียกว่าIteratorซึ่งมีพารามิเตอร์ประเภทElement: interface Iterator<Element> {} แล้วเรามีอินเตอร์เฟซที่มีวิธีการหนึ่งที่จะกลับIterableIterator // T has an upper bound of Iterator interface Iterable<T: Iterator> { getIterator(): T } ปัญหาของIteratorการเป็นแบบทั่วไปคือเราต้องระบุอาร์กิวเมนต์ประเภท แนวคิดหนึ่งในการแก้ไขปัญหานี้คือ "อนุมาน" ประเภทของตัววนซ้ำ หลอกรหัสต่อไปนี้เป็นการแสดงออกถึงความคิดที่ว่ามีตัวแปรประเภทElementซึ่งอนุมานว่าจะเป็นอาร์กิวเมนต์ประเภทไปที่Iterator: interface <Element> Iterable<T: Iterator<Element>> { getIterator(): T } จากนั้นเราก็ใช้มันในที่นี้: class Vec<Element> implements Iterable<VecIterator<Element>> {/*...*/} คำจำกัดความของคำIterableว่าไม่ใช้Elementที่อื่นในคำจำกัดความของมัน แต่กรณีใช้งานจริงของฉัน ฟังก์ชั่นบางอย่างที่ใช้Iterableยังจำเป็นต้องสามารถ จำกัด พารามิเตอร์ของตนเพื่อยอมรับIterables ซึ่งคืนค่าตัววนซ้ำบางชนิดเช่นตัววนซ้ำสองทิศทาง คำถาม: มีชื่อที่กำหนดขึ้นสำหรับตัวแปรประเภทอนุมานเหล่านี้หรือไม่ เทคนิคโดยรวมเป็นอย่างไร การไม่รู้ระบบการตั้งชื่อเฉพาะทำให้การค้นหาตัวอย่างของสิ่งนี้เป็นเรื่องยากหรือเรียนรู้เกี่ยวกับคุณลักษณะเฉพาะทางภาษา ไม่ใช่ทุกภาษาที่มีชื่อสามัญมีเทคนิคนี้ …

6
วิธีการใช้กระบวนการพัฒนากับนักศึกษา
ที่งานแรกของฉันในฐานะนักพัฒนาซอฟต์แวร์ทีมของฉันใช้เปรียว / ต่อสู้ในการจัดการเวิร์กโฟลว์โครงการของเราและทำงานได้ค่อนข้างดี ฉันมีที่ปรึกษาที่มีประสบการณ์บางคนที่กำหนดฉันให้ถูกทาง - ฉันเป็นหนี้พวกเขาด้วยความกตัญญู ฉันทำงานที่นั่นสองสามปีจากนั้นย้ายไปยังโอกาสใหม่เมื่อสองสามเดือนที่ผ่านมา กรอไปข้างหน้าสู่งานปัจจุบันของฉัน ฉันทำงานที่มหาวิทยาลัยภายใต้การดูแลของอาจารย์ เนื่องจากฉันอยู่ในมหาวิทยาลัยโปรแกรมเมอร์เกือบทุกคนเป็นนักเรียน (พวกเขาถูกและอุดมสมบูรณ์!) เจ้านายของฉันมีประสบการณ์ด้านการจัดการ แต่ไม่ใช่กับการพัฒนาซอฟต์แวร์และทีมซอฟต์แวร์ไม่ได้อยู่แถวหน้าในใจของเจ้านายของฉันเสมอไป . เงื่อนไขเหล่านี้ได้สร้างสภาพแวดล้อมที่สมบูรณ์แบบสำหรับการสร้างบางมากซอฟแวร์ที่มีคุณภาพดี โครงการซอฟต์แวร์ดูเหมือนจะโกงเล็กน้อยไม่มีความคิดที่จะออกแบบและใช้วิธีปฏิบัติที่น่ากลัวอย่างแท้จริง ฉันรู้ว่าสิ่งต่าง ๆ น่าจะดีกว่า ฉันต้องการใช้กระบวนการพัฒนาเพื่อช่วยให้ทุกคนได้รับการติดตามเพิ่มคุณภาพของรหัสและปรับใช้ซอฟต์แวร์ที่มีเสถียรภาพมากขึ้น ฉันไม่แน่ใจว่าจะเริ่มจากตรงไหน ฉันไม่ได้มองหาคำตอบเช่น "Use Scrum", "Set a kanban board" หรือ "ลองดูเปรียว!" (แม้ว่าความคิดจะชื่นชม) โดยเฉพาะอย่างยิ่งผมหวังว่าจะได้ข้อมูลเชิงลึกกำไรเป็นวิธีการที่จะดำเนินการตามกระบวนการในการพัฒนาสำหรับการนี้สภาพแวดล้อมการทำงาน โดยปกติแล้วพนักงานจะทำงานระหว่าง 1 ถึง 2 ปีก่อนที่จะย้ายมาทำงานโดยทั่วไปไม่มีประสบการณ์และการประชุมยอดเยี่ยมประจำวันที่รวมทุกคนเข้าใกล้ไม่ได้ หนึ่งจะส่งเสริมคุณภาพประสิทธิภาพและการสื่อสารในสถานที่ทำงานได้อย่างไร อัปเดต:หลังจากอ่านคำตอบและความคิดเห็นบางอย่างแล้วฉันคิดว่าฉันจะให้พื้นฐานเพิ่มเติม ฉันจะไม่พิจารณาตัวเองต้นแบบศิลปะของการพัฒนาซอฟต์แวร์ แต่ฉันกำลังมีประสบการณ์มากพอที่จะรับรู้การเขียนโปรแกรมไม่ดีเมื่อฉันเห็นมัน ฉันสามารถตรวจสอบว่านักพัฒนามีความสามารถหรือไม่หลังจากใช้เวลาเพียงหนึ่งหรือสองนาทีในการทำงานกับพวกเขา ฉันพอใจกับความสามารถของตัวเองในการหาวิธีการแก้ปัญหาอย่างชาญฉลาดอย่างไรก็ตามพื้นที่ที่ฉันขาดประสบการณ์อย่างแท้จริงคือการจัดการโครงการที่นักพัฒนารายอื่นมีส่วนเกี่ยวข้อง คำแนะนำ) ฉันทำให้เสียงเหมือนนักเรียนทุกคนที่เข้ามาในสำนักงานนี้เป็นสลัวที่สมบูรณ์ มีไข่ที่ไม่ดีอยู่ที่นี่ แต่นักเรียนส่วนใหญ่ที่ฉันเคยรู้จักมีความฉลาดต้องการเรียนรู้และหลงใหลในงาน บางคนเพิ่งเริ่มต้นและพวกเขาไม่รู้ว่าพวกเขาไม่รู้อะไร และก็ไม่เป็นไร เมื่อฉันเริ่มเขียนโปรแกรมครั้งแรกฉันก็ไม่ได้ดีไปกว่านี้แล้ว!

2
ความละเอียดของข้อยกเว้น
ฉันใช้การถกเถียงระหว่างเพื่อนสองสามคนกับฉันพวกเขาชอบข้อยกเว้นทั่วไปเช่นClientErrorExceptionและServerErrorExceptionมีรายละเอียดเป็นฟิลด์ของข้อยกเว้นในขณะที่ฉันชอบทำสิ่งที่เฉพาะเจาะจงมากขึ้น ตัวอย่างเช่นฉันอาจมีข้อยกเว้นจำนวนหนึ่งเช่น: BadRequestException AuthenticationFailureException ProductNotFoundException แต่ละรายการเหล่านี้สร้างขึ้นตามรหัสข้อผิดพลาดที่ส่งคืนจาก API การติดตามข้อดีของข้อยกเว้นนี้ดูเหมือนว่าเป็นไปไม่ได้สำหรับ Java อย่างไรก็ตามความคิดเห็นของเพื่อนฉันไม่ใช่เรื่องแปลก มีวิธีที่ต้องการในแง่ของความสามารถในการอ่านโค้ดและการใช้งาน API หรือว่ามันเป็นเรื่องที่ชอบ?

3
สำหรับถ้า antipattern
ฉันอ่านโพสต์บล็อกนี้เกี่ยวกับรูปแบบการต่อต้านถ้าและฉันค่อนข้างแน่ใจว่าฉันเข้าใจว่าทำไมมันเป็นรูปแบบการต่อต้าน foreach (string filename in Directory.GetFiles(".")) { if (filename.Equals("desktop.ini", StringComparison.OrdinalIgnoreCase)) { return new StreamReader(filename); } } คำถามที่ 1: เป็นเพราะreturn new StreamReader(filename);ภายในfor loop? หรือความจริงที่ว่าคุณไม่จำเป็นต้องforวนซ้ำในกรณีนี้ ในฐานะผู้เขียนบล็อกชี้ให้เห็นว่ารุ่นที่บ้าน้อยกว่านี้คือ: if (File.Exists("desktop.ini")) { return new StreamReader("desktop.ini"); } ทั้งประสบจากสภาพการแข่งขันเพราะถ้าไฟล์ถูกลบออกก่อนที่จะสร้างของคุณจะได้รับStreamReaderFile­Not­Found­Exception คำถามที่ 2: ในการแก้ไขตัวอย่างที่สองคุณจะเขียนใหม่โดยไม่มีคำสั่ง if และล้อมรอบStreamReaderด้วยบล็อก try-catch แทนและถ้ามันโยนFile­Not­Found­Exceptionคุณจัดการมันในcatchบล็อกตามนั้นหรือไม่

6
มีอะไรผิดพลาดในบริบทของการเขียนโปรแกรมการทำงานถ้าวัตถุของฉันไม่แน่นอน?
ฉันสามารถเห็นประโยชน์ของวัตถุที่เปลี่ยนแปลงไม่ได้กับวัตถุที่เปลี่ยนแปลงไม่ได้เช่นวัตถุที่ไม่เปลี่ยนรูปทำให้ยากต่อการแก้ไขปัญหาในการเขียนโปรแกรมแบบมัลติเธรดเนื่องจากสถานะที่ใช้ร่วมกันและเขียนได้ ในทางตรงกันข้ามวัตถุที่ไม่แน่นอนช่วยในการจัดการกับตัวตนของวัตถุมากกว่าการสร้างสำเนาใหม่ทุกครั้งและยังปรับปรุงประสิทธิภาพและการใช้หน่วยความจำโดยเฉพาะอย่างยิ่งสำหรับวัตถุขนาดใหญ่ สิ่งหนึ่งที่ฉันพยายามเข้าใจคือสิ่งที่ผิดพลาดในการมีวัตถุที่ไม่แน่นอนในบริบทของการเขียนโปรแกรมการทำงาน อย่างหนึ่งในจุดที่บอกกับฉันคือผลลัพธ์ของการเรียกฟังก์ชั่นในลำดับที่แตกต่างกันนั้นไม่ได้กำหนดขึ้น ฉันกำลังมองหาตัวอย่างที่เป็นรูปธรรมที่ชัดเจนว่าอะไรผิดพลาดได้โดยใช้วัตถุที่ไม่แน่นอนในการเขียนโปรแกรมฟังก์ชั่น โดยทั่วไปถ้ามันไม่ดีก็ไม่ดีโดยไม่คำนึงถึง OO หรือกระบวนทัศน์การเขียนโปรแกรมการทำงานใช่ไหม ฉันเชื่อว่าข้อความของฉันตอบคำถามนี้เอง แต่ฉันก็ยังต้องการตัวอย่างเพื่อที่ฉันจะได้รู้สึกเป็นธรรมชาติมากขึ้น OO ช่วยในการจัดการการพึ่งพาและเขียนโปรแกรมที่ง่ายขึ้นและบำรุงรักษาด้วยความช่วยเหลือของเครื่องมือเช่น encapsulation, polymorphism เป็นต้น ฟังก์ชั่นการเขียนโปรแกรมยังมีแรงจูงใจเดียวกันในการส่งเสริมรหัสที่สามารถบำรุงรักษาได้ แต่โดยการใช้สไตล์ซึ่งไม่จำเป็นต้องใช้เครื่องมือและเทคนิค OO - หนึ่งในสิ่งที่ฉันเชื่อคือการลดผลข้างเคียงฟังก์ชั่นบริสุทธิ์ ฯลฯ

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

5
Microservices: หินใหญ่ก้อนแรก?
ฉันค้นคว้าสถาปัตยกรรมไมโครเซอร์วิสที่พยายามรับภาพรวมในระดับสูงถึงข้อดีและข้อเสียทั้งหมดและข้อมูล ฯลฯ ข้อมูลมากมายที่ฉันอ่าน / ดูมาจาก ThoughtWorks (Martin Fowler, Neal Ford, et อัล) งานส่วนใหญ่ของมาร์ตินฟาวเลอร์ในเรื่องนี้มีอายุเพียงไม่กี่ปีเมื่อ Microservices (เป็นชื่อครัวเรือนในการเขียนโปรแกรมหากไม่ใช่ในทางปฏิบัติทั่วไป) ยังเด็กอยู่ดังนั้นฉันจึงใช้เกลือเม็ดเล็ก ๆ สิ่งหนึ่งที่พิเศษคือ: เมื่อฉันได้ยินเรื่องราวเกี่ยวกับทีมที่ใช้สถาปัตยกรรมไมโครไซต์ฉันสังเกตเห็นรูปแบบทั่วไป เรื่องราวของบริการไมโครสโคปที่ประสบความสำเร็จเกือบทั้งหมดเริ่มต้นด้วยก้อนหินขนาดใหญ่ที่ใหญ่เกินไปและพังทลาย เกือบทุกกรณีที่ฉันได้ยินเกี่ยวกับระบบที่สร้างขึ้นเป็นระบบไมโครบริการตั้งแต่เริ่มต้นมันก็จบลงด้วยปัญหาร้ายแรง รูปแบบนี้ทำให้เพื่อนร่วมงานของฉันหลายคนโต้แย้งว่าคุณไม่ควรเริ่มโครงการใหม่ด้วยบริการไมโครเซสชั่นแม้ว่าคุณจะแน่ใจว่าใบสมัครของคุณจะใหญ่พอที่จะทำให้คุ้มค่า . (อ้างอิง: https://martinfowler.com/bliki/MonolithFirst.html - เน้นพวกเขา) ตอนนี้ 3 ปีต่อมาและด้วย microservices คำที่แพร่หลายมากขึ้นมันเป็นที่ยอมรับกันโดยทั่วไปว่าระบบใหม่มักจะให้บริการที่ดีขึ้นโดยมีบริการที่ใหญ่กว่า (-than-microservice มันละเอียดยิ่งขึ้นซึ่งเป็นส่วนหนึ่งของมาตรการวิวัฒนาการใช่หรือไม่ หรือมีบรรทัดฐานในการเริ่มต้นโครงการตั้งแต่เริ่มต้นด้วยสถาปัตยกรรมไมโครบริการแบบตรงข้ามกับข้อความข้างต้นหรือไม่? ดูเหมือนว่าวิธีการทั่วไปมีเหตุผล แต่อยากรู้อยากเห็นความคิดของชุมชน

5
การปรับเปลี่ยนวิธีการแบบยาว: ออกตามที่เป็นเทียบกับการแยกออกเป็นวิธีการเปรียบเทียบกับการใช้ฟังก์ชันในเครื่อง
สมมติว่าฉันมีวิธียาวเช่นนี้ public void SomeLongMethod() { // Some task #1 ... // Some task #2 ... } วิธีนี้ไม่มีชิ้นส่วนซ้ำ ๆ ที่ควรเคลื่อนย้ายไปยังวิธีอื่นหรือฟังก์ชั่นในเครื่อง มีหลายคน (รวมถึงฉัน) ที่คิดว่าวิธีการที่ยาวนานนั้นเป็นกลิ่นรหัส นอกจากนี้ผมไม่ชอบความคิดของการใช้#region(s) ที่นี่มีคำตอบที่เป็นที่นิยมมากอธิบายว่าทำไมนี้ไม่ดี แต่ถ้าฉันแยกรหัสนี้เป็นวิธีการ public void SomeLongMethod() { Task1(); Task2(); } private void Task1() { // Some task #1 ... } private void Task2() { // Some task #1 …

3
ฉันจะออกแบบวิธี TryParse ซึ่งให้ข้อมูลโดยละเอียดในกรณีที่เกิดข้อผิดพลาดในการวิเคราะห์คำได้อย่างไร
เมื่อแยกวิเคราะห์อินพุตของผู้ใช้นั้นโดยทั่วไปจะแนะนำให้ไม่โยนและจับข้อยกเว้น แต่แทนที่จะใช้วิธีการตรวจสอบ ใน. NET BCL สิ่งนี้จะเป็นความแตกต่างระหว่าง (เช่นint.Parseการยกเว้นข้อมูลที่ไม่ถูกต้อง) และint.TryParse(ผลตอบแทนfalseจากข้อมูลที่ไม่ถูกต้อง) ฉันกำลังออกแบบของตัวเอง Foo.TryParse(string s, out Foo result) วิธีการและฉันไม่แน่ใจเกี่ยวกับค่าตอบแทน ฉันสามารถใช้boolเหมือนตัวเอง .NET ของTryParseวิธีการ แต่ที่จะให้ข้อบ่งชี้เกี่ยวกับการไม่มีชนิดของข้อผิดพลาดเกี่ยวกับเหตุผลที่แน่นอนว่าทำไม ไม่สามารถแยกวิเคราะห์เป็นs Foo(ตัวอย่างเช่นsอาจมีวงเล็บที่ไม่ตรงกันหรือจำนวนอักขระที่Barไม่ตรงกันหรือ a โดยไม่ต้องสอดคล้องกันBazฯลฯ ) ในฐานะผู้ใช้ API ฉันไม่ชอบวิธีการที่เพิ่งกลับมาประสบความสำเร็จ / ล้มเหลวบูลีนโดยไม่บอกฉันว่าทำไมการดำเนินการล้มเหลว สิ่งนี้ทำให้การดีบั๊กเป็นเกมที่คาดเดาและฉันไม่ต้องการให้ลูกค้าของห้องสมุดของฉันทำเช่นนั้น ฉันสามารถคิดถึงวิธีแก้ปัญหามากมายสำหรับปัญหานี้ (รหัสสถานะส่งคืนส่งคืนสตริงข้อผิดพลาดเพิ่มสตริงข้อผิดพลาดเป็นพารามิเตอร์ออก) แต่พวกเขาทั้งหมดมีข้อเสียตามลำดับและฉันต้องการให้สอดคล้องกับอนุสัญญาของ Framework ของ ดังนั้นคำถามของฉันมีดังนี้ มีวิธีใดใน. NET Framework ที่ (a) แยกวิเคราะห์อินพุตโดยไม่ส่งข้อยกเว้นและ (b) ยังคงส่งกลับข้อมูลรายละเอียดข้อผิดพลาดมากกว่าบูลีนจริง / เท็จง่าย ๆ หรือไม่?
9 c#  .net  api-design 

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