ซอฟต์แวร์ที่มีความเห็นคืออะไร?

ฉันมักจะเห็นคนพูดว่าซอฟต์แวร์บางอย่าง "มีความเห็นมาก" หรือว่า Microsoft มีแนวโน้มที่จะเขียนกรอบงานที่ "ไม่แสดงความคิดเห็น" สิ่งนี้หมายความว่าอย่างไร

หากกรอบความคิดเห็นนั้นล็อคหรือแนะนำคุณในการทำสิ่งต่าง ๆ

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

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

Apple มีความคิดเห็นที่ดีเมื่อออกแบบผลิตภัณฑ์

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

ฉันจะวาง Microsoft ไว้ในคอลัมน์ที่ไม่แสดงความคิดเห็น ตัวอย่างที่ดีของกรอบไมโครซอฟท์ซึ่งเป็นยกเลิก .NETopininated: โดยการเปิด CLR และสเป็คมันจะเปิดให้กับทุกประเภทของภาษาและรูปแบบของการใช้งาน

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

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

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

เป็นซอฟต์แวร์ที่ทำงานตามที่ผู้เขียนคิดว่าควรใช้งานได้แทนที่จะพยายามทำให้ทุกคนพอใจ นั่นหมายความว่าผู้คนจำนวนมากจะไม่ชอบ แต่คนที่ทำจะรักมัน

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

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

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

อย่างไรก็ตามนี่ไม่ได้แปลว่าล็อคอิน หมายความว่าอาจต้องใช้ความพยายามพิเศษในการทำสิ่งต่าง ๆ

กรอบความคิดเห็นที่น้อยลงนั้นมีตัวเลือกที่แตกต่างกันจำนวนหนึ่งและปล่อยให้คุณตัดสินใจ

กรอบความเห็นมักจะลบภาระจากนักพัฒนาเพื่อบูรณาการล้อหรือคิดใหม่ปัญหาเดียวกันซ้ำแล้วซ้ำอีกและจึงช่วยมุ่งเน้นไปที่ปัญหาที่แท้จริงในมือ

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

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

ในทางตรงกันข้ามซอฟต์แวร์ที่ไม่มีการกำหนดสมมติฐานจะทำเพียงเล็กน้อย และด้วยเหตุนี้เฟรมเวิร์กการพัฒนาซอฟต์แวร์ / ซอฟท์แวร์ที่ไม่ได้ถูกกำหนดมักจะมีตัวเลือกการกำหนดค่ามากมาย ผู้พัฒนามักจะต้องทำการตัดสินใจมากมายเกี่ยวกับแง่มุมต่าง ๆ ของซอฟต์แวร์ บ่อยครั้งที่มีการพัฒนาเครื่องมือต่าง ๆ เพื่อให้การจัดการกับตัวเลือกมหาศาลเหล่านี้ง่ายขึ้น เช่น Visual Studio .NET สำหรับ. NET, Eclipse IDE สำหรับ Java เป็นต้นโดยทั่วไปซอฟต์แวร์ที่ไม่ได้ใช้งานจะใช้เวลานานกว่าผู้เชี่ยวชาญในการแสดงความคิดเห็น

tl; dr :

• ความเห็น : เช่นRuby on Rails มีวิธีที่ต้องการโดยเฉพาะอย่างยิ่งในการทำสิ่งต่าง ๆ และคุณได้รับการสนับสนุนจำนวนมากในการทำสิ่งต่าง ๆ การทำสิ่งต่าง ๆ ทำได้ยากหรือสำหรับบางระบบเป็นไปไม่ได้ (Cassandra อยู่ในใจ)
• ยกเลิกการดื้อดึง : เช่นPerl 5 คุณสามารถทำอะไรก็ได้ที่คุณชอบไม่ว่าจะในรูปแบบใด สไตล์ทั้งหมดเปิดกว้างถูกต้องและรองรับ

ผู้คนจำนวนมากกำลังอ้างถึง ASP.NET MVC เป็นกรอบงานที่ "ไม่ได้กำหนด" และฉันแค่ต้องการชั่งน้ำหนักด้วยความคิดสองสามข้อเกี่ยวกับเรื่องนั้น

เป็นความจริงที่ ASP.NET MVC ไม่ได้มีอำนาจมากเกินไป คุณสามารถใช้วิธีการคงอยู่ใด ๆ ก็ตามที่คุณต้องการไม่ว่าจะเป็น Linq-to-SQL, หน่วยงาน ADO.NET, NHibernate ฯลฯ

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

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

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

มันคือปริมาณของอนุสัญญาที่ดำเนินการในกรอบและจำนวนการตัดสินใจที่ได้รับ

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

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

ตัวอย่างที่คุณจะเห็นมากในขณะนี้คือกรอบงาน ASP.NET MVC มันสามารถขยายได้อย่างน่าอัศจรรย์ แต่นั่นก็เป็นความหายนะในบางประการไม่มีเนื้อสัตว์เลย ต้องการเข้าถึงข้อมูลหรือไม่ คุณจะต้องเขียนด้วยตัวเอง ต้องการ AJAX ไหม เหมือนกัน

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

นี่หมายความว่าถ้าคุณต้องการแยกจากความเห็นมักจะมีงานให้ทำมากกว่าถ้าคุณทำงานกับรุ่นวานิลลา นี่เป็นสถานการณ์ 80/20 หากคุณเลือกกรอบการแสดงความคิดเห็นอย่างถูกต้องคุณจะต้องแยกออกจากความคิดเห็น 20% ของเวลาและคุณจะได้ผลดีมากอีก 80% ของเวลา