ทำไมต้องพัฒนาไลบรารีภายในสำหรับแอปพลิเคชันภายใน

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

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

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

เมื่อฉันพูดว่าไฟล์ 'รวม' ในแต่ละโครงการฉันไม่ได้หมายถึงการคัดลอกและวางแต่ละไฟล์ลงในแผนผังแหล่งที่มาของโครงการที่กำลังพัฒนา ฉันหมายถึงการพัฒนาไดเรกทอรี / ไลบรารี (แยกเป็นโครงการใด ๆ ) ที่มีซอร์สโค้ดร่วมที่สามารถรวมอยู่ในไฟล์ของโครงการได้ตามปกติคือ #include

ps ฉันกำลังพูดถึงการพัฒนา c / c ++ ที่นี่สำหรับแอปพลิเคชันเดสก์ท็อปหลาย ๆ ตัว

มีเหตุผลมากมายในการสร้างไลบรารีและไลบรารีที่แชร์(ในไฟล์. dll หรือ. so)แม้จะเป็นการใช้ภายใน:

1. การใช้ซ้ำในโครงการต่างๆนั้นสะอาดกว่ามาก
2. การแยกความรับผิดชอบ - ส่วนหนึ่งของรหัสของคุณอาจเหมาะสมกว่านักพัฒนาหรือทีมอื่น
3. คุณสามารถได้รับประโยชน์จากการปรับปรุงในไลบรารีที่ทีมอื่นทำโดยไม่ต้องค้นหารหัสเฉพาะ
4. เวลาสร้างได้เร็วขึ้นถ้าไลบรารีมีเสถียรภาพไม่จำเป็นต้องสร้างใหม่
5. พื้นที่ดิสก์ - คุณสามารถมีเพียงห้องสมุดและส่วนหัวในโครงการ
6. หากคุณใช้ไลบรารีที่แบ่งใช้คุณสามารถประหยัดหน่วยความจำได้โดยมีเพียงหนึ่งสำเนาที่โหลดลงใน RAM แม้ว่าจะมีหลายโปรแกรมกำลังใช้งานอยู่
7. โดยทั่วไปแล้วคุณจะพบกับเอกสารและการทดสอบห้องสมุดที่ดีขึ้น
8. การออกแบบที่สะอาดและรหัส - ความคิดเกี่ยวกับสิ่งที่เข้ามาในการก่อสร้างห้องสมุดควรจะส่งผลในกลุ่มที่เกี่ยวข้องของการทำงานในแต่ละห้องสมุดและคุณมีแนวโน้มที่จะแยกโค้ดทั่วไปเข้าห้องสมุดจากเฉพาะการประยุกต์ใช้ในการตรวจสอบ
9. หากคุณมีอัลกอริทึมที่เป็นกรรมสิทธิ์ในไลบรารีคุณสามารถ จำกัด การเข้าถึงแหล่งที่มาเช่นไม่อนุญาตให้ผู้รับเหมาหรือทีมที่มาจากแหล่งที่มา
10. รหัสห้องสมุดอาจอยู่ภายใต้ใบอนุญาตที่แตกต่างจากแอพพลิเคชั่นที่เขียนขึ้นเป็นส่วนหนึ่งของบาง บริษัท ยังเป็นที่รู้จักในห้องสมุดโอเพ่นซอร์สที่พวกเขาภูมิใจ - ได้รับความชื่นชมที่สำคัญในชุมชนโอเพ่นซอร์ส กลับ.

บริษัท บางแห่งมีแนวปฏิบัติทางบัญชีที่โครงการที่สร้างห้องสมุดได้รับเงินคืนในการใช้งานซ้ำ

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

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

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

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

• รหัสที่ต้องไม่ปล่อยสู่สภาพแวดล้อมจริง : ตัวอย่างเช่นไลบรารีทดสอบหน่วยหรือไลบรารี 'จำลอง' ที่ใช้สำหรับการทดสอบของนักพัฒนาซอฟต์แวร์เพื่อทดแทนองค์ประกอบระบบจริง (ฮาร์ดแวร์ APIs ระบบระยะไกลฐานข้อมูล ฯลฯ )

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

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

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

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

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

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

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

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

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

ค่าใช้จ่ายตัวอย่าง:

1. เวลา / พลังงานที่ใช้ในการพิจารณากรณีใช้งาน "ทั่วไป"
2. เวลาที่ใช้ในการสร้าง "ห้องสมุด" ที่สามารถแจกจ่ายให้กับ "ลูกค้า" ของคุณ (รหัสของคุณเอง)
3. ความกดดันในอนาคตที่จะใช้ประโยชน์จาก "ห้องสมุด" แม้ว่ามันจะไม่ตรงกับกรณีการใช้งานครั้งต่อไป

กฎทั่วไปของฉันคือ: อย่าสร้างรหัสลงในห้องสมุดเว้นแต่ฉันจะมีอย่างน้อย 2 แห่งแยกต่างหากซึ่งจำเป็นต้องใช้รหัส

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

เพราะถ้าคุณ "เพียงรวมไว้ในแหล่งต้นไม้ของฉัน" คุณจะทำซ้ำรหัส

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

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

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

ฉันต้องการอธิบายรายละเอียดเกี่ยวกับต้นทุนที่โซลูชันของคุณมีในระยะยาว

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

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

จะเกิดอะไรขึ้นถ้า "pseudo-library" ของคุณถูกใช้โดย "pseudo-library" อันอื่นB? คุณต้องเพิ่ม cpp ตัวใหม่ลงในโปรเจ็กต์อื่น ๆ อีกมากมาย และถ้าBเปลี่ยนไปใช้ห้องสมุดอื่น คุณจะต้องลบเท่ากับจากในทุกโครงการที่ขึ้นอยู่เฉพาะในAB

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

แต่เดี๋ยวก่อนมีหลักประกันมากกว่านี้: นักพัฒนาไม่ชอบงานโง่ ๆ ในการตามล่าโครงการทั้งหมดที่ต้องการ cpp ใหม่และจะเพิ่มรหัส / คลาสของเขา / เธอลงในไฟล์ที่มีอยู่แล้วซึ่งไม่ใช่สิ่งที่ดีใน ในระยะยาว

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

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

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

ถ้าห้องสมุดจะถูกใช้โดยการใช้งาน 3,500 แล้วคุณอย่างทำจำเป็นต้องใช้มันเป็นห้องสมุดที่แยกต่างหาก

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

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

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