ไลบรารี่ / เฟรมเวิร์กใดที่คุณคิดว่าซับซ้อนเกินไปสำหรับปัญหาที่แก้ได้? [ปิด]

... และเขียนรหัสฟังก์ชัน "ด้วยตนเอง" หรือไม่

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

เป็นกรณีที่มีข้อสงสัยมากกว่านี้ขึ้นอยู่กับสถานการณ์ที่ฉันอาจชักจูง jQuery (ตัวอย่างเช่นเมื่อฉันไม่ต้องการสนับสนุนเบราว์เซอร์ยุคหิน): มันลดความซับซ้อนของบางสิ่ง แต่เพิ่มความซับซ้อนอีกชั้นหนึ่ง และการใช้ jQuery ที่มากเกินไปนำไปสู่ปัญหาที่ไร้สาระเช่นที่พบเมื่อเร็ว ๆ นี้บน SO: ฉันจะกำหนด href ว่างให้aกับแท็กด้วย jQuery ได้อย่างไร ปรากฎว่าเป็นคำถาม HTML ไม่ใช่แม้แต่ JavaScript

อีกกรณีที่ไร้สาระและยังไม่ชัดเจนสำหรับหลาย ๆ คนคือการใช้เครื่องมือเทมเพลต / ภาษาที่สร้างขึ้นบนระบบเทมเพลตอื่น: PHP ระดับที่สามของการสร้างแรงบันดาลใจให้ใคร

และอีกอันหนึ่ง: บางครั้งแค่แยก XML ด้วย (เปรียบเปรย) printfจะทำได้ง่ายกว่าการทำด้วยเอ็นจิน XML ที่น่ากลัว

กรณีอื่น ๆ จากประสบการณ์ของคุณ?

ห้องสมุดองค์กร MS ส่วนใหญ่และการควบคุมบุคคลที่สามส่วนใหญ่สำหรับ. net ทำให้ฉันรู้สึกแบบนี้หลังจากใช้งานไปเล็กน้อย

ไมล์สะสมของคุณอาจแตกต่างกันไป

Windows Communication Foundation

ความจริงที่ว่ามันมีรูปของมีดสวิสกองทัพในหน้าแรกของผลรวมมันทั้งหมดสำหรับฉัน ลองนึกภาพการกำหนดค่า XML มีความยาวประมาณสี่เท่าของรหัสจริงที่คุณเขียนและยังคงยากมากที่จะเขียนบริการ SOAP ที่ทำงานร่วมกันได้ระหว่าง C #, Java, PHP, Python และภาษาอื่น ๆ ทั้งหมดที่มัน "ควรจะ" ทำงานร่วมกับ ...

ในโครงการในอนาคตทั้งหมดฉันจะไปกับ REST

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

ตัวอย่างง่าย ๆ : อาจใช้งาน printf เพื่อปล่อย XML ได้ง่ายกว่าการใช้ไลบรารี 10 เท่า:

printf("<xml>%s</xml>", str);

แต่คุณอย่าลืมที่จะหลบหนีอักขระพิเศษในstr? ตัวอย่างเช่น ' <' และ ' &'? บางคนอาจพูดว่า "ไม่ฉันไม่ได้ทำ" และเขียนข้อความต่อไปนี้:

printf("<xml><![CDATA[%s]]></xml>", str);

แต่จะยังคงปล่อย XML ที่เสียหายหากstrมีสตริงย่อย " ]]>" ที่ใดก็ได้ในนั้น กรณีขอบ - แน่นอน แต่ยังคงเป็นสถานการณ์ที่ถูกต้องซึ่งอาจนำไปสู่ปัญหาที่ไม่คาดคิดที่มีผลกระทบร้ายแรง

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

Log4Net

ห้องสมุดดี แต่เอกสารน่ากลัว มันเกินความจริงสำหรับสิ่งที่ฉันต้องการจะทำ

ฉันใช้Traceแทน

SharePoint

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

ASP.NET WebForms - แม้ว่าในฐานะนักพัฒนาเว็บ. NET มันเป็นเรื่องของขนมปังและเนยมาเป็นเวลานานแล้วตั้งแต่ฉันเริ่มใช้เฟรมเวิร์ก MVC (และมาจากสภาพแวดล้อม PHP / Smarty Template) - คุณรู้ว่าบางครั้งมันก็ดีขึ้น วิธีที่จะทำการพัฒนาเว็บและนามธรรมที่จะใช้เป็น overkill และรั่ว

ในเกือบทุกกรณีที่ฉันทำสิ่งนี้ฉันได้รู้สึกเสียใจ:

• การใช้ฟังก์ชั่น PHP oci_ * แทนที่จะเป็นไลบรารีแรปเปอร์กลายเป็นการเคลื่อนไหวที่ไม่ดีเนื่องจากการบำรุงรักษาโค้ด การย้ายรหัสทั้งหมดไปที่ Zend_Db ทำให้การพัฒนารักษารหัสฐานข้อมูลง่ายขึ้นมาก
• การกลิ้งส่วนประกอบกริด ajax ของตัวเองซึ่งใช้เวลานานเกินไปในการพัฒนาเพิ่มเติมเนื่องจากความรวดเร็วของส่วนประกอบกริดอื่น ๆ ที่พัฒนาขึ้น ขณะนี้ฉันกำลังย้ายไปยังกริด Ext JS ทั้งหมดเนื่องจากมีฟังก์ชันการทำงานของบุคคลที่สามจำนวนมาก
• การหลีกเลี่ยงไลบรารีอย่างต้นแบบและ jquery นำไปสู่การเกิดปัญหาข้ามเบราว์เซอร์ซ้ำบ่อยครั้งยากที่จะติดตาม พอร์ต Ext JS แก้ปัญหาข้ามเบราว์เซอร์ของฉันได้ มันเป็นเวทย์มนตร์แม้ว่าจะเป็นกรอบที่กว้างใหญ่ที่ใช้เวลาหลายสัปดาห์ในการทำความเข้าใจ

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

System.Text.RegularExpressions

Regex ซับซ้อนและช้ามาก ฉันจะใช้ Regex น้อยมากและมักจะเขียนการแยกและจับคู่ข้อความของฉันเอง

บางครั้งฉันจะพบว่า Regex มีประโยชน์สำหรับการจับคู่ที่ซับซ้อนจริงๆ

ไม่ใช่ Delphi4PHP ที่ต้องการการกดที่ไม่ดี แต่ฉันลองมัน (เวอร์ชั่น 2.0) และมันก็ยากมากที่จะโค้งงอตามความประสงค์ของฉัน ฉันต้องการใช้มันเพื่อสร้างเว็บแอปสไตล์ youtube ให้ลูกค้าดูวิดีโอการฝึกอบรม แต่มันยุ่งยากเกินไปและเมื่อฉันพยายามรวมกรอบ PHP (VCL4PHP, Zend, Smarty และ Recess) ฉันวิ่งเข้าไปในสิ่งที่หลีกเลี่ยงไม่ได้ ทุกอย่างเพราะไม่มีเนมสเปซในปัญหา PHP 5

ที่ถูกกล่าวว่าฉันไม่ได้ม้วนตัวเองในที่สุด ฉันเพิ่งเรียนรู้จากความผิดพลาดของฉันและตัดสินใจที่จะทำให้มันง่ายมากและใช้ CodeIgniter และ FlowPlayer (กับ JQuery)

ฉันมีความทะเยอทะยานว่าสิ่งใดที่เฟรมเวิร์กสร้างขึ้นจาก PHP 5 ที่ยังมีชีวิตอยู่ PHP 6 จะมีเฟรมเวิร์กที่ยอดเยี่ยมซึ่งอาจเล่นได้ดีด้วยกัน

Weka

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

1. มันม้วนอาร์เรย์ที่ปรับขนาดได้ของตัวเองซึ่งไม่มีอะไรใช้รับประกันการแปลงยุ่งไปมา

2. การมีเพศสัมพันธ์ตามลำดับจำนวนมากที่วิธีการจะต้องมีการเรียกในลำดับที่เฉพาะเจาะจงและถ้าคุณไม่ RTFM อย่างระมัดระวังจริงๆคุณจะไม่ได้ตระหนักถึงมัน

3. ทุกอินสแตนซ์จะต้องเป็นวัตถุอินสแตนซ์และฉันต้องประกาศอย่างชัดเจนด้วยแอตทริบิวต์ของวัตถุไม่ว่าจะเป็นชื่อหรือตัวเลข สิ่งนี้นำไปสู่งานยุ่งมากมายที่แปลงข้อมูลให้เป็นรูปแบบ Weka ที่ต้องการ สิ่งนี้น่ารำคาญเป็นพิเศษเนื่องจาก Weka API มีข้อยกเว้นมากมายที่การรวบรวมรหัสไม่ได้หมายความว่ามันน่าจะทำงานได้ ถ้าฉันออกแบบ API ฉันก็จะมีอิสระในสิ่งที่ฉันยอมรับ (อาจเป็นเพียงแค่อาเรย์ของ Object) และเพียงแค่ไตร่ตรองข้อมูลเพื่อหาว่าฉันได้อะไรมาและสิ่งที่ถูกต้องคืออะไร

ในโครงการเฉพาะฉันทิ้ง EJB3 มันทำให้ฉันพึ่งพาการฉีดและการจัดการการทำธุรกรรมภาชนะจัดการ แต่แนะนำการอ้างอิงขนาดใหญ่ (เช่น JBoss) และทำให้ระบบยากที่จะเขียนการทดสอบอัตโนมัติสำหรับ ตอนนี้ฉันได้แยกมันออกเป็น JPA + Constructor injection

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

ฉันยังปฏิเสธในห้องสมุดสำหรับอีก: เราใช้ไลบรารี XML ที่มีขนาดใหญ่และซับซ้อนในเนื้อหาส่วนใหญ่ของเรา หลังจากใช้เวลา 4 ชั่วโมงต่อวันในการพยายามทำให้มันทำงานในแอพใหม่ฉันแค่พูดว่า 'bag it' และดึงลงใน TinyXML มันไม่ได้อยู่ใกล้ที่ทรงพลัง แต่ใช้ความพยายามน้อยกว่ามากในการทำสิ่งที่ง่าย

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

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

และส่วนประกอบฐานข้อมูลของ Delphi ฉันเกลียดฉัน มีเสมอ. ดังนั้นฉันจึงสร้างอินเทอร์เฟซฐานข้อมูลของตัวเองที่ทำงานในแบบที่ฉันต้องการให้มันใช้งานได้

โดยทั่วไปเมื่อมีตัวเลือกฉันมักจะสร้างห้องสมุดของตัวเอง

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