กรอบทำให้สิ่งที่เป็นนามธรรมมากเกินไป? [ปิด]

ฉันเขียนโปรแกรมมาไม่ถึงปีแล้วและมีประสบการณ์ในการเขียนแอปพลิเคชันระบบเว็บแอพและสคริปต์สำหรับธุรกิจ / องค์กร อย่างไรก็ตามสิ่งหนึ่งที่ฉันไม่เคยทำมาก่อนคือทำงานกับกรอบอย่าง Django, Rails หรือ Zend

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

1. ทำให้โปรแกรมลงวันที่เร็วมากเนื่องจากลักษณะที่เปลี่ยนแปลงตลอดเวลาของโมดูล / กรอบงาน

2. ทำให้โค้ดยากที่จะเข้าใจเนื่องจากมีกรอบและโมดูลที่พร้อมใช้งานและไอเดียของพวกเขาทั้งหมด

3. ทำให้โค้ดน้อยลงยกเว้นว่าคุณอ่านเอกสารทั้งหมด; นั่นคือฉันสามารถอ่านรายการความเข้าใจและตรรกะตามเงื่อนไขและหาว่าโปรแกรมกำลังทำอะไร แต่เมื่อคุณเห็นฟังก์ชั่นที่ต้องการส่งผ่านสตริงและพจนานุกรมตามอำเภอใจ โมดูลที่กำหนด; และ:

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

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

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

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

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

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

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

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

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

นอกจากนี้คุณควรแยกแยะระหว่างทางเทคนิคแนวคิดและกฎ "ธุรกิจ"นามธรรม การเขียนโปรแกรมในภาษาระดับที่สูงขึ้นเป็นสิ่งที่เป็นนามธรรมที่คุณไม่ควรพลาด (Python, PHP, C # vs. C เทียบกับ Assembler; น้อยกว่ากับ CSS) ในขณะที่ "abstractions กฎธุรกิจ" อาจเป็นเรื่องยากหากพวกเขาไม่ ตอบสนองความต้องการของคุณ (การตรวจสอบด้วยคลิกเดียวกับคุกกี้เข้ารหัสด้วยมือ)

นั่นเป็นเพราะ abstractions ทางเทคนิคไม่ค่อย "รั่ว" นั่นคือคุณแทบจะไม่ต้องดีบักรหัสเครื่องเมื่อเขียนแอปพลิเคชันใน Python abstractions กฏทางธุรกิจทำงานในระดับเทคนิคเดียวกันแม้ว่าและเป็นเพียง "การรวมกลุ่มรหัส" จริงๆ คุณอาจจะต้องตรวจแก้จุดบกพร่องคุกกี้ที่ตั้งค่าไว้หรือแฮชรหัสผ่านที่สร้างขึ้นในบางจุดซึ่งหมายความว่าคุณจะต้องดำน้ำผ่านรหัสบุคคลที่สามจำนวนมาก

สำหรับฉันแล้วคุณเข้าใจผิดว่า abstractions และการใช้รหัสซ้ำ

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

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

คุณได้สิ่งนั้นมาจากการใช้ PHP หรือ Ruby ในตอนแรกคุณมี abstractions จำนวนมากใช่ไหม? สิ่งที่ชัดเจนที่สุด:

1. ระบบปฏิบัติการภาษาการเขียนโปรแกรมและคอมไพเลอร์ให้สิ่งที่เป็นนามธรรมอย่างยิ่งเหนือ Assembler และฮาร์ดแวร์

2. เว็บเซิร์ฟเวอร์ให้บริการซ็อกเก็ตนามธรรม failover โปรโตคอล HTTP ฯลฯ

3. SQL มอบสิ่งที่เป็นนามธรรมเกี่ยวกับวิธีการจัดเก็บข้อมูลบนหน่วยเก็บถาวรแบบถาวรและเก็บไว้ในหน่วยความจำเพื่อการเข้าถึงที่รวดเร็วยิ่งขึ้นตรวจสอบให้แน่ใจว่ามีกรด, มิเรอร์และอื่น ๆ

คุณอาจลองสร้างเว็บแอปโดยไม่ต้องใช้ระบบปฏิบัติการหรือเว็บเซิร์ฟเวอร์ฐานข้อมูลหรือภาษาการเขียนโปรแกรมระดับสูง คุณได้อย่างรวดเร็วจะพบว่าคุณใช้เวลาหลายปี reinventing ล้อคือการสร้างของการเขียนโปรแกรมภาษาของคุณเว็บเซิร์ฟเวอร์และของฐานข้อมูลที่ได้รับว่าคุณภาพของพวกเขาจะห่างไกลจากคุณภาพของผลิตภัณฑ์ของเราจริงการใช้งาน

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

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

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

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

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

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

• หากคุณมีรถเข็นของคุณเองเพื่อนร่วมงานของคุณจะต้องรักษารหัสที่กำหนดเองบางอย่างอาจไม่ได้จัดทำเป็นเอกสารโดยไม่สามารถรับความช่วยเหลือได้ทุกที่

โดยการใช้เฟรมเวิร์กคุณต้องพึ่งพาโค้ดซึ่งก็คือ:

• เขียนโดยนักพัฒนาที่มีประสบการณ์

• มักตรวจทานคู่

• หน่วยทดสอบ

• จัดทำเอกสารอย่างกว้างขวาง

• ใช้มานานหลายปีโดยนักพัฒนาหลายพันคน

• บ่อยครั้งที่ได้รับการสนับสนุนดังนั้นคุณสามารถรายงานข้อผิดพลาดและดูว่าได้รับการแก้ไขแล้วจริงหรือ

• เป็นที่รู้จักโดยนักพัฒนาซอฟต์แวร์หลายคนที่ทราบข้อควรระวังและปัญหาที่เป็นไปได้และสามารถช่วยในไซต์เช่น Stack Overflow

• มีให้สำหรับคุณตอนนี้ฟรี

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

อืมมแง่มุมหนึ่งของ LedgerSMB ที่เราทำงานเป็นจำนวนมากคือแนวทางของเราในการวางกรอบ มีปัญหาพื้นฐานสองประการที่มาพร้อมกับแนวคิดแบบนี้ เหล่านี้คือ:

1. ระเบิดพึ่งพาและ

2. ผิดนามธรรม

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

ลองดูที่ ORMs เช่น ฉันหลีกเลี่ยงการใช้ ORM เพราะมันมักจะเป็นกรณีที่ db จบลงด้วยการออกแบบให้กับโมเดลวัตถุของแอพพลิเคชั่น กรณีนี้ไม่จำเป็น ฉันได้พบกับนักพัฒนาที่จัดการเพื่อรักษาการออกแบบฐานข้อมูลที่ดีและแอพที่ดีในขณะที่ใช้ ORMs แต่พวกเขาหันไปใช้สิ่งต่างๆมากมายที่ orm hype กล่าวว่าไม่จำเป็นต้องใช้เช่น encapsulating API เชิงสัมพันธ์ของฐานข้อมูล

ปัญหาที่สำคัญของหลักสูตรคือยิ่งรหัสอัตโนมัติสูงขึ้นโดยเฉพาะอย่างยิ่งเมื่อมันเป็นทึบแสงยิ่งยากที่จะเห็นสิ่งที่ผิดพลาด นี่คือประเด็นเกี่ยวกับ ORM ที่ @jhewlett ทำขึ้นมา (ดู/software//a/190807/63722 )

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

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

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

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

พวกเขาจะป่อง overkill? แน่ใจ ทั้งหมดนี้ขึ้นอยู่กับสิ่งที่คุณต้องการและสิ่งที่กรอบนำมาสู่ตาราง หากคุณมีแอพพลิเคชั่นบนเว็บแบบง่ายบางที Rails อาจขายหน้าคุณมากเกินไปและคุณควรดูสิ่งที่ง่ายกว่าเช่น Sinatra เป็นวิธีแก้ปัญหา

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

แต่คุณบอกว่าฉันจะคัดลอกรหัสของฉันจากโครงการเก่าและฉันสามารถใช้มันเป็นจุดเริ่มต้นสำหรับโครงการใหม่ของฉัน! ฉันจะเปลี่ยนสิ่งที่แตกต่างและอาจทำให้บางส่วนของวัตถุ / ฟังก์ชั่นทั่วไปมากขึ้นและคิดหาวิธีที่ดีกว่าในการแก้โค้ดที่ยุ่งยากเล็กน้อย! ขอแสดงความยินดีคุณเพิ่งสร้างกรอบงาน ทำสิ่งนี้อีกสองสามพันครั้งและคุณมีอะไรบางอย่างเช่น Django, Rails หรือ Zend

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

พิจารณา Mappers เชิงวัตถุ (ORMs) พวกเขายอดเยี่ยมในการที่พวกเขาดูแลรหัสการทำแผนที่ที่น่าเบื่อมากมายสำหรับคุณ พวกเขาอาจสร้างวัตถุของคุณให้คุณ อย่างไรก็ตามในการสรุป SQL ออกไปมันเป็นเรื่องยากมากที่จะให้เหตุผลเกี่ยวกับประสิทธิภาพและเพิ่มประสิทธิภาพคอขวดของคุณ

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

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

สำหรับฉันประเด็นสำคัญคือฉันต้องได้รับทรัพยากรมากขึ้นกว่าที่ฉันต้องลงทุน หรือจากอีกมุมหนึ่งฉันจะบอกว่าทันทีที่ความต้องการของกรอบการทำงานมากกว่าผลตอบแทนที่มีอยู่ความได้เปรียบทั้งหมดก็จะหายไป ดังนั้นมัน 'ใช่! โปรด! และขอบคุณ!' สำหรับทุกคนที่สร้างสินทรัพย์ที่จะวางตรงและทำงานตามที่ต้องการภายใน html / CSS / PHP และ SQL ของฉัน

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

บางคนบอกว่านี่เป็นหลักการของกรอบฮอลลีวูด : "อย่าโทรหาเราเราจะโทรหาคุณ" ในทางตรงกันข้ามเมื่อใดก็ตามที่คุณใช้ไลบรารีรหัสของคุณจะเรียกใช้ไลบรารีไม่ใช่วิธีอื่น

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

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

ในมุมมองของฉันไม่ว่าคุณจะต้องการใช้เฟรมเวิร์กหรือไลบรารีบอกอะไรเกี่ยวกับนักพัฒนาของคุณหรือไม่และไม่ว่าหนึ่งในสองวิธีนั้นเหนือกว่าและในที่สุดก็จะเหนือกว่า

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

ฉันไม่คิดว่ามันจะเป็นการฉลาดที่จะตัดสินใจว่ามันดีกว่าที่จะเป็นเหมือนอดีตหรืออันหลัง

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

...

และยิ่งไปกว่านั้นโดยเฉพาะถ้าคุณไม่ชอบเฟรมเวิร์กอย่าง Django ลองค้นหา "microframeworks" อย่าง Flask :)