ห้องสมุดทั่วไปเป็นความคิดที่ดีหรือไม่?


16

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

ฉันเพิ่งอ่านบทความ (ไม่สามารถหาได้ตอนนี้) ที่บอกว่านี่เป็นความคิดที่เลวและจริง ๆ แล้วมันบอกว่ามันเป็น "รูปแบบต่อต้าน"

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

ฉันติดอยู่ในร่องสำหรับโครงการใหม่ของฉัน (Golang) การขจัดความซ้ำซ้อนของรหัสได้รับการตอกย้ำเข้ามาในตัวฉันตลอดหลายปีที่ผ่านมา แต่ฉันรู้สึกว่าฉันควรลองในครั้งนี้

ในขณะที่เขียนสิ่งนี้ฉันเริ่มคิดว่าวิธีการ "lib ทั่วไป" นี้เป็นผลมาจากการข้ามสถาปัตยกรรม? บางทีการออกแบบของฉันต้องการความคิดมากกว่านี้ใช่ไหม

สนใจฟังความคิด


2
2 เซ็นต์ของฉัน ... หากคุณต้องทำการเปลี่ยนแปลงกับ api ทั่วไปหากหนึ่งในระบบใช้ต้องการการเปลี่ยนแปลงนั้น API หรือไลบรารีนั้นไม่ใช่ห้องสมุดทั่วไปเลย
Raja Anbazhagan

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

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

2
มีคนเรียก Apache และแก้ไขความบ้าคลั่งนี้ Apache Commons
Laiv

คำตอบ:


21

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

ฉันเห็นสิ่งนี้ในการดำเนินการเมื่อฉันรับผิดชอบพอร์ตแรกของรหัสหน่วยธุรกิจทั้งหมด (ส่วนใหญ่ใหม่สำหรับฉัน) ไปยังระบบ 64 บิตและทำการยกเครื่องที่สมบูรณ์สำหรับการสร้างและบรรจุภัณฑ์ของเรา ด้วยมือและบางครั้งก็ไม่ค่อยดี * เรามักจะสร้างสิ่งที่เราส่งออกมาจากแอปพลิเคชันซึ่งลูกค้าจะพูดว่า "ฉันต้องการระบบที่ใช้ A, B, D และ F รวมถึง M และ N ที่คุณยังไม่ได้ทำและแตกต่างกันเล็กน้อยกาวรวมพวกเขาทั้งหมด " สิ่งที่ทุกคนมีเหมือนกันคือห้องสมุดขยะที่มีมานานกว่าสองทศวรรษที่ผ่านมา ** ได้สะสมทุกสิ่งที่ผู้คนคิดว่าควรจะนำกลับมาใช้ใหม่ได้ เพื่อทำให้เรื่องสั้นสั้นลงเศษส่วนของรหัสในไลบรารีไม่ได้. เราใช้เวลาสร้างเวลาอันมีค่าจำนวนมากและดูแลการอ้างอิงเหล่านั้นเพื่อให้ห้องสมุดทั่วไปติดตั้งไม่ใช่เพราะเราต้องการพวกเขาจริงๆ

คุณธรรมคือห้องสมุดจะต้องได้รับการปฏิบัติเหมือนชั้นเรียนและไม่มากเกินไปกับความรับผิดชอบมากเกินไป อย่าวาง JSON parser ในไลบรารีเดียวกันด้วยฟังก์ชันพีชคณิตเชิงเส้นแม้ว่าทุกโปรแกรมที่คุณใช้จะใช้ทั้งคู่

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

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


* ในกระบวนการนี้ฉันค้นพบไบนารีที่ผ่านไปแล้วและไม่ได้รับการคอมไพล์ใหม่จากศูนย์ในอีกหกปี

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


1
กฎง่ายๆของฉันคือถ้าคุณตั้งใจจะตั้งชื่อห้องสมุดของคุณเช่น "ธรรมดา" คุณกำลังมีปัญหา
Karl Bielefeldt

9

น่าอายที่ฉันแนะนำห้องสมุด "ทั่วไป" ชื่อเช่นนี้ในสภาพแวดล้อมของทีมสองสามทศวรรษหลัง ฉันไม่เข้าใจพลวัตของสิ่งที่อาจเกิดขึ้นในทีมที่มีการประสานงานอย่างหลวม ๆ ในเวลาไม่กี่เดือน

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

และมันเริ่มต้นได้ดีพอ เราเริ่มต้นด้วยห้องสมุดคณิตศาสตร์ ( common/math*) ของกิจวัตรที่เราใช้ในชีวิตประจำวันเนื่องจากเราทำงานในคอมพิวเตอร์กราฟิกซึ่งมักจะหนักในพีชคณิตเชิงเส้น และเนื่องจากเรามักจะสอดแทรกด้วยรหัส C เราจึงเห็นด้วยกับฟังก์ชั่นยูทิลิตี้ที่มีประโยชน์บางอย่างfind_indexซึ่งแตกต่างจากstd::findใน C ++ จะส่งคืนดัชนีไปยังองค์ประกอบที่พบในลำดับแทนที่จะเป็นตัววนซ้ำซึ่งเลียนแบบการทำงานของฟังก์ชัน C ของเรา - สิ่งต่าง ๆ เช่นนี้ - ผสมผสานกันเล็กน้อย แต่เรียบง่ายและใช้กันอย่างแพร่หลายพอที่จะคุ้นเคยและเป็นประโยชน์กับทุกคน และความคุ้นเคยแบบทันทีเป็นเกณฑ์ที่สำคัญอย่างยิ่งเมื่อฉันเห็นมันในการพยายามทำสิ่งที่ "ธรรมดา" หรือ "มาตรฐาน" เพราะถ้ามันเป็น "สามัญ" จริง ๆ ก็ควรมีคุณภาพที่คุ้นเคยเกี่ยวกับเรื่องนี้เนื่องจากความกว้าง การยอมรับและการใช้งานรายวัน

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

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

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

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

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

การขจัดความซ้ำซ้อนของรหัสได้รับการตอกย้ำเข้ามาในตัวฉันตลอดหลายปีที่ผ่านมา แต่ฉันรู้สึกว่าฉันควรลองในครั้งนี้

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

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

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

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


3

มีฟังก์ชั่นที่แตกต่างกันสามประเภทที่คุณอาจพิจารณานำไปใช้กับไลบรารี:

  1. สิ่งที่ควรนำกลับมาใช้ใหม่สำหรับทุกคน
  2. สิ่งที่ควรนำกลับมาใช้ใหม่สำหรับองค์กรของคุณเท่านั้น
  3. สิ่งที่ไม่คุ้มค่าที่จะใช้ซ้ำ

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

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

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


1

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

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


these libraries just replicate functionality from standard librariesนี่ไม่ใช่สิ่งที่เลวร้ายเลยในจาวาสคริปต์คุณได้เพิ่ม
ไลบรารี่

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

0

ห้องสมุดส่วนใหญ่ที่ใช้ร่วมกันระหว่างทีมทำให้เกิดปัญหามากกว่าที่พวกเขาแก้ไข "ถนนสู่นรกปูด้วยเจตนาดี"

ข้อยกเว้นคือห้องสมุดที่ตอบสนองความต้องการส่วนใหญ่ด้านล่าง:

  • มีเงินทุนรักษาระยะยาวที่ปลอดภัย
  • มีทีมงาน / ชุมชนสนับสนุนเฉพาะ
  • มีเครื่องมือติดตามบั๊ก
  • ครอบคลุมการทดสอบอย่างครอบคลุม
  • มีวัตถุประสงค์เดียวที่กำหนดชัดเจน
  • ไม่มีการพึ่งพาตนเอง (ทั้งที่บิลด์และรันไทม์) นอกเหนือจากไลบรารีมาตรฐานหรือเสมือนมาตรฐาน
  • มีความแตกต่างที่ชัดเจนระหว่าง API สาธารณะและภายใน
  • มีช่องทางการสื่อสารและกระบวนการสำหรับผู้ใช้ทั้งหมด / หลายคนที่จะเห็นด้วยกับคุณสมบัติใหม่และการเปิดตัว

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

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