คุณควรใช้ห้องสมุดเมื่อคุณสามารถทำงานได้โดยไม่ต้องหรือไม่ [ปิด]


33

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

คุณควรเลือกใช้ห้องสมุดในสถานการณ์นี้ (เช่นเพื่อประโยชน์ของรหัสที่มีคุณภาพดีกว่าหรือไม่)


3
คุณวัด "คุณภาพ" อย่างไร ตามจำนวนบรรทัดของรหัส? เรียน? ความซับซ้อน? การบำรุงรักษา? การกลับคืนสู่ปกติ?
Laiv

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

4
ไม่ใช่คำตอบที่ตรงกับคำถามของคุณ แต่ความคิดที่ว่า "หมายเลขนี้" ย่อมรับประกัน "คุณภาพที่ดีขึ้น" อย่างหลีกเลี่ยงไม่ได้เมื่อต้องเผชิญกับการยอมรับความยากลำบากในการเพิ่มคุณภาพของรหัส ไม่มีการแก้ไขด่วนเพื่อรับประกันคุณภาพ หากมีปัญหาจะไม่เกิดขึ้น ใครก็ตามที่อ้างว่าวิธีการที่เรียบง่ายบางอย่างนั้นเป็นวิธีการแก้ปัญหาแบบไม่สิ้นสุด (end-all-end-all) เป็นแบบมากเกินไป
Flater

3
อะไรทำให้คุณคิดว่าการใช้ห้องสมุดจะช่วยเพิ่มคุณภาพของรหัส?
หยุดทำร้ายโมนิก้า

1
โหวตให้ปิดเพราะคำถามดูเหมือนจะถูกกำหนดขึ้นใหม่อย่างมีนัยสำคัญและคำตอบบนตอบคำถามรุ่นเก่า ... ดีกว่าโพสต์คำถามอีกครั้งเนื่องจากมันตั้งอยู่ในตัวของมันเอง (บวกเพิ่มรายละเอียดเพื่อหลีกเลี่ยง "บอร์ดเกินไป "โหวต) ...
AnoE

คำตอบ:


54

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

หากคุณเชื่อว่าการเพิ่มองค์ประกอบบุคคลที่สามจะช่วยประหยัดค่าใช้จ่ายในระยะยาวคุณควรใช้งาน ถ้าคุณทำไม่ได้คุณไม่ควรทำ ตรวจสอบให้แน่ใจว่าคุณพิจารณาค่าใช้จ่ายในการบำรุงรักษาอย่างต่อเนื่อง (ตัวอย่างเช่นเมื่อมีการเผยแพร่ O / S รุ่นใหม่หรือพบข้อบกพร่องด้านความปลอดภัยหรือข้อกำหนด W3C ใหม่บางตัวออกมา)

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

มีเป้าหมายอื่นที่ต้องพิจารณาด้วย (เช่นความเสี่ยง) แต่ TCO ก็เป็นเป้าหมายที่ยิ่งใหญ่


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

6
@DetlevCM คำตอบก็บอกว่ามันสามารถไปทางอื่นได้อย่างง่ายดาย ห้องสมุดที่ไม่เกี่ยวกับการเรียนรู้จะมีค่าใช้จ่ายในการบำรุงรักษาที่แนบมากับคุณซึ่งคุณในฐานะผู้ใช้ห้องสมุดไม่ต้องจ่ายและอาจจะไม่สามารถชำระเงินได้ถ้าคุณต้อง (เช่นถ้าคุณเป็นเจ้าของห้องสมุด)
ลูกบาศก์

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

36

Bill Gates เคยกล่าวไว้ว่า:

"การวัดความคืบหน้าการเขียนโปรแกรมด้วยบรรทัดของรหัสเป็นเหมือนการวัดความคืบหน้าการสร้างเครื่องบินด้วยน้ำหนัก"

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

  1. ไม่มีวิธีอื่นในการทำให้สำเร็จ การทำโดยที่ไม่ทำจะไม่คุ้มค่าทางเศรษฐกิจในการผลิตสินค้าตรงเวลาและตามงบประมาณ
  2. มันจะช่วยฉันประหยัดเวลาได้มากเนื่องจากฉันต้องการคุณลักษณะหลายอย่างของห้องสมุดดังกล่าว
  3. ห้องสมุดใช้งานได้ดีและปัญหาที่อาจเป็นไปได้ที่ฉันอาจได้รับการบันทึกไว้เป็นอย่างดี

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

โชคดี!


4
@BillalBegueradj อ้างที่มีความหมายใช่ ไม่เพียงพอ เราไม่ได้พูดถึงความคืบหน้าเรากำลังพูดถึงคุณภาพของซอฟต์แวร์และบรรทัดของรหัสมีความสัมพันธ์อย่างมากกับจำนวนข้อบกพร่องที่พบ ดูกระดาษผลกระทบที่ขัดแย้งกันของขนาดคลาสที่มีต่อความถูกต้องของตัวชี้วัดเชิงวัตถุซึ่งแสดงให้เห็นว่าตัวชี้วัดอื่น ๆ ทั้งหมดไม่มีอำนาจในการทำนายข้อบกพร่องที่พบหลังจากปรับโดย LOC ซึ่งหมายความว่า LOC เป็นตัวทำนายที่ดีที่สุดสำหรับข้อบกพร่อง 2001) และโดยวิธีการที่กระดาษทางวิทยาศาสตร์เต้นคำพูดที่มีชื่อเสียง
Theraot

5
@Theraot คุณกำลังแนะนำว่าเนื่องจากจำนวนบรรทัดกำหนดจำนวนของข้อบกพร่องที่โปรแกรมขนาดใหญ่มีคุณภาพของรหัสแย่กว่าโปรแกรมขนาดเล็ก? ฉันไม่เห็นด้วยกับการวัดของคุณขอโทษ นอกจากนี้หากข้อความอ้างถึงรบกวนคุณจริงๆคุณสามารถเพิกเฉยได้
Neil

3
@ ต้องชัดเจนจำนวนบรรทัดไม่ได้กำหนดจำนวนของข้อบกพร่องมันมีความสัมพันธ์ที่แข็งแกร่งกับจำนวนข้อบกพร่องที่พบ สิ่งนี้ง่ายต่อการเข้าใจ: ยิ่งรหัสมีขนาดใหญ่ขึ้นโอกาสที่จะแนะนำข้อบกพร่องมากขึ้น แน่นอนจำนวนข้อบกพร่องจะลดลงหลังจากที่พวกเขาพบและแก้ไข นี่เป็นเพียงความสัมพันธ์หลังจากทั้งหมด ภาคผนวก: LOC เป็นตัวชี้วัดที่พบบ่อยมากดูกระดาษสำหรับรายละเอียด
Theraot

5
@heraot ข้อโต้แย้งของฉันไม่ได้มีความสัมพันธ์กับข้อบกพร่องกับจำนวนบรรทัด ข้อโต้แย้งของฉันคือจำนวนข้อบกพร่องที่เทียบเท่ากับคุณภาพของรหัสที่ไม่ดี Chrome มีส่วนแบ่งข้อบกพร่องในช่วงหลายปีที่ผ่านมา แต่ฉันจะโต้แย้งความถูกต้องของข้อเรียกร้องใด ๆ ที่แนะนำว่ามันเขียนแย่กว่าปลั๊กอิน jQuery 10 บรรทัดที่เขียนไม่ดีบน github
Neil

3
@Theraot "กระดาษวิทยาศาสตร์ชนะคำพูดที่มีชื่อเสียง" - มันเสียงเหมือนกระดาษของคุณจริงสนับสนุนคำพูดมากกว่าการเต้นมัน ...
npostavs

14

(หมายเหตุ: คำถามเดิมคือ: จำนวนไลบรารีปรับปรุงคุณภาพโค้ดหรือไม่)

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

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

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


4

ในขณะที่ใช้ไลบรารีที่ถูกต้องจะช่วยให้คุณประหยัดงานได้มาก แต่ก็มีค่าใช้จ่ายแอบแฝงอยู่มากมาย:

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

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


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

1

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

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


0

หากมีคนทำงานให้คุณแล้วแน่นอนคุณควรใช้มัน

ข้อยกเว้นสำหรับกฎคือ javascript พวกเขาจะนำเข้าห้องสมุดอื่น ๆ โหล (รุ่นล้าสมัย) เพื่อเพิ่มฟีเจอร์ภาษาที่พวกเขาต้องการใช้แล้วทำงานให้คุณ

เลือกกรอบของคุณและอยู่ภายใน หากไลบรารีทำงานร่วมกับกรอบงานของคุณหรือ js ธรรมดาได้ แต่ถ้าต้องการกรอบงานที่แตกต่างกันให้มองหาตัวเลือกอื่น


4
แฟน ๆ จาวาสคริปต์มากมายที่นี่
58

0

ห้องสมุดและเวลาที่จะใช้พวกเขาคือการตัดสินใจที่ซับซ้อน

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

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

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

การดีบักเล็กน้อยไม่ใช่ปัญหาสำคัญ แต่ ณ จุดนั้นรหัสไลบรารีเริ่มนับกับขนาดรหัสของฉันจากมุมมองการบำรุงรักษา (เพิ่มเติมดังนั้นหากการแก้ไขของฉันไม่สามารถผลักไปอัปสตรีมด้วยเหตุผลบางอย่าง)

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

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

การตัดสินใจการตัดสินใจ ....

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