เมื่อใดที่จะไม่ใช้เฟรมเวิร์ก [ปิด]


38

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

อย่างไรก็ตามฉันคิดว่ามีข้อเสียของกรอบการทำงานใด ๆ ในโปรแกรมเมอร์นั้นในฐานะชุมชนอาจพึ่งพาเฟรมเวิร์กที่เลือกไว้มากจนไม่เข้าใจการทำงานพื้นฐานหรือในกรณีของโปรแกรมเมอร์ใหม่ไม่เคยเรียนรู้การทำงานพื้นฐานเพื่อ เริ่มด้วย. มันง่ายที่จะกลายเป็นผู้เชี่ยวชาญในระดับที่คุณไม่ได้เป็น 'โปรแกรมเมอร์ PHP' (ตัวอย่าง) อีกต่อไป แต่เป็น "โปรแกรมเมอร์ Drupal" เพื่อยกเว้นสิ่งอื่นใด

ใครสนใจล่ะ เรามีกรอบ! เราไม่จำเป็นต้องรู้วิธีการ "ทำด้วยมือ"! ขวา?

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

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

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


เมื่อเป็นเฟรมเวิร์กไม่ใช่ผลิตภัณฑ์ที่เป็นกรรมสิทธิ์ของ Microsoft และคุณต้องเชื่อมต่อกับฐานข้อมูล MSSql
AndrewKS

3
จุดเกี่ยวกับทุกคนที่ได้รับ "พิเศษเกินไป" ค่อนข้างไร้สาระ คุณสามารถเขียนรหัสแอสเซมเบลอร์สำหรับแพลตฟอร์ม x86 ได้หรือไม่? ถ้าคุณสามารถทำอย่างนั้นกับสมมุติว่า 8051? แม้ว่าคุณจะสามารถทำทั้งสองอย่างมีสิ่งอื่นอีกมากมายที่คุณทำไม่ได้ วันนี้คือการทำงานเป็นทีม - คุณต้องรู้ให้มากที่สุดเพื่อให้สามารถทำงานของคุณได้และสามารถร่วมมือกับผู้อื่นได้ แค่นั้นแหละ.
kubal5003

เมื่อกรอบนั้นทำใน Perl เฟรมเวิร์กที่มีการปิด / ปิดนั้นทำให้ฉันโกรธเช่นกัน MsTest เป็นตัวอย่างหนึ่ง
งาน

2
@ kuba5003 - มันเกิดขึ้นฉันสามารถเขียนได้ทั้งสองอย่าง แต่นั่นไม่ใช่ประเด็น :) แม้ว่าฉันจะไม่สามารถเขียนในภาษาเหล่านั้นได้ฉันก็ยังควรมีความคิดเกี่ยวกับภาษาเหล่านั้น - ถ้าฉันจะเขียนไดรเวอร์อุปกรณ์ - แม้ว่าฉันจะทำได้และอาจจะใช้ภาษาระดับสูงกว่านี้มาก เป้าหมาย. ในโลกเว็บผู้เขียนโปรแกรม "Drupal" ควรมีรากฐานใน PHP ข้อโต้แย้งของฉันเกี่ยวกับคะแนนนี้คือมีความเชี่ยวชาญเฉพาะด้านและเมื่อคุณชำนาญในการแยกความรู้พื้นฐานออกไป
Chris

1
อย่าใช้เฟรมเวิร์ก 0- ใช้ไลบรารีแทน Frameworks บอกให้คุณทราบถึงวิธีการเขียนรหัสของคุณเพื่อให้เหมาะกับวิธีการของพวกเขาในขณะที่ห้องสมุดนำความพิเศษของพวกเขามาให้คุณ ดังนั้นด้วยห้องสมุดคุณจะได้รับประโยชน์จากการไม่สร้างล้อใหม่ในขณะที่ยังสามารถเขียนรหัสที่คุณต้องการได้ กรอบงานมีประโยชน์สำหรับการเริ่มต้นหรือโครงการด่วนเท่านั้น
gbjbaanb

คำตอบ:


27

"จะต้องมีการวัดที่ดีในการพิจารณาว่าเมื่อใดที่เหมาะสมที่จะใช้กรอบงาน"

ไม่ได้จริงๆ หากมีตัวชี้วัดที่ดีสำหรับการพิจารณาการใช้เทคโนโลยีที่เหมาะสมคุณจะไม่เห็นภาษาบรรณาธิการและระเบียบวิธีสงครามศักดิ์สิทธิ์

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


ส่วนที่สิบเอ็ด? oO
Michel Ayres


2
เขาไม่ได้พูดว่า "ร้อยละ" เขา? ; o)
heltonbiker

14

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

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

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


6

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

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


6

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

ฉันจะใช้คำว่า "framework" เหมือนกันกับ "library"


ก่อนที่จะใช้เฟรมเวิร์กต้องพิจารณาบางสิ่งนี่เป็นตัวอย่างทั่วไปบางประการ

# 1 กรอบจะประหยัดเวลาและความพยายามหรือไม่

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

กรอบการทำงานถูกสร้างขึ้นเพื่อa)เพิ่มอินเตอร์เฟสที่เป็นมิตรกับโปรแกรมเมอร์ให้กับองค์ประกอบที่ซับซ้อนหรือb)เพิ่ม abstraction ให้กับองค์ประกอบที่รู้จักกันดี (หรือเป็นที่ยอมรับ)

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

สิ่งนี้อาจทำให้กระบวนการพัฒนาของคุณช้าลงซึ่งอาจมีค่าใช้จ่ายสูง

# 2 ขนาดของใบสมัครของคุณ

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

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

ในทางกลับกันถ้าเฟรมเวิร์กมีงานสกปรกจำนวนมากอยู่ภายใน (เช่นเฟรมเวิร์กฐานข้อมูล) ดังนั้นมันอาจใช้งานได้แม้ว่าคุณจะเป็นเพียงบางส่วน "" โดยใช้เฟรมเวิร์ก เกร็ดเล็กเกร็ดน้อยที่ดีคือการไม่พยายามสร้าง ADO.NET หรือ MongoDB-driver ของคุณเองเพียงเพราะคุณไม่จำเป็นต้องใช้ไลบรารีทั้งหมด

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

ท้ายที่สุดนี้จะเชื่อมโยงกับคำถาม # 1 และ # 3

# 3 ผลกระทบ

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

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

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

กรอบบางคนก็อาจจะมีมากทรัพยากรหนัก

หลักสูตรนี้เชื่อมโยงกลับไปยังจุดที่ 1 และ # 2


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

Corbin March สรุปได้เป็นอย่างดี:

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

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

เฟรมเวิร์กทั้งหมดมีกรณีการใช้งานมันเป็นเพียงเรื่องของการใช้มันเพื่อวัตถุประสงค์ที่ถูกต้อง


4

นักพัฒนารายอื่นรู้กรอบหรือไม่

หากนักพัฒนาทุกคนรู้กรอบ X แล้วให้เหตุผลอื่น ๆ ทั้งหมดสำหรับการใช้กรอบทำงานได้ไปได้เลย! สำหรับฉันแล้วมันไม่สมเหตุสมผลเลยที่จะบังคับใช้การเรียนรู้กรอบที่เฉพาะเจาะจงเมื่อเวลาส่วนใหญ่ของการพัฒนาจะถูกใช้ไปกับการเรียนรู้ความซับซ้อนของกรอบ

เกี่ยวกับคำแถลงของคุณเกี่ยวกับโปรแกรมเมอร์รุ่นใหม่ที่ไม่รู้พื้นฐานคุณมีความเห็นอกเห็นใจมากกว่าฉัน! ใช่มันเป็นความอัปยศ แต่ฉันจะใช้เวลาของฉันกังวลเกี่ยวกับความโง่เขลาของคนอื่นหรือไม่? nup (ตามสมมติฐานที่ว่าสมาชิกใหม่ของชุมชนเหล่านี้ไม่ได้ทำงานร่วมกับคุณทันที)


4

ฉันจะใช้กรอบถ้า (และถ้าเท่านั้น) เงื่อนไขต่อไปนี้ถือเป็นจริง:

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

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

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


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