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

ฉันพยายามทำตามหลักการของDRYอย่างเคร่งครัดในที่ทำงานเสมอ ทุกครั้งที่ฉันทำซ้ำรหัสจากความเกียจคร้านมันกัดอีกครั้งในภายหลังเมื่อฉันต้องการรักษารหัสนั้นในสองแห่ง

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

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

1. เราจบลงด้วยโครงการเล็ก ๆ นับสิบ / ร้อยคน - แต่ละหลังมีชั้นเรียน / วิธีการเล็ก ๆ น้อย ๆ ซึ่งเราจำเป็นต้องนำมาใช้ซ้ำ มันคุ้มค่าที่จะสร้างรหัสใหม่.DLLเพียงเล็กน้อยหรือไม่?
2. เราจบลงด้วยโครงการเดียวที่รวบรวมวิธีและชั้นเรียนที่ไม่เกี่ยวข้องเพิ่มมากขึ้น วิธีนี้เป็นสิ่งที่ บริษัท ที่ฉันเคยทำงานด้วย พวกเขามีโปรเจ็กต์base.commonที่มีโฟลเดอร์สำหรับสิ่งต่าง ๆ เช่นที่ฉันกล่าวถึงข้างต้น: เครือข่าย, การจัดการสตริง, MVVM ฯลฯ มันมีประโยชน์อย่างเหลือเชื่อ แต่การอ้างอิงมันลากโดยไม่จำเป็นด้วยรหัสที่ไม่เกี่ยวข้องทั้งหมดที่คุณไม่ต้องการ

ดังนั้นคำถามของฉันคือ:

ทีมซอฟต์แวร์ทำงานอย่างไรดีที่สุดเกี่ยวกับการนำรหัสขนาดเล็กไปมาระหว่างโครงการ

ฉันสนใจเป็นพิเศษหากใครก็ตามที่ทำงานใน บริษัท ที่มีนโยบายในด้านนี้หรือที่ได้เจอปัญหานี้เป็นการส่วนตัวตามที่ฉันมี

หมายเหตุ: การใช้คำว่า "Project", "Solution" และ "Reference" ของฉันมาจากพื้นหลังในการพัฒนา. NET ใน Visual Studio แต่ฉันแน่ใจว่าปัญหานี้เป็นภาษาและแพลตฟอร์มที่เป็นอิสระ

หากเป็นวิธี / คลาสที่นำมาใช้ซ้ำได้จริงคุณสามารถเขียนลงในห้องสมุด 'Swiss Army Knife' จำนวนน้อยได้ เราทำสิ่งนี้บ่อยครั้งที่ บริษัท ของฉัน เราเรียกพวกเขาว่าไลบรารีเฟรมเวิร์ก:

• Framework.Data - ยูทิลิตี้สำหรับการทำงานกับการสืบค้นฐานข้อมูล
• Framework.ESB - วิธีการมาตรฐานสำหรับการโต้ตอบกับบัสบริการองค์กรของเรา
• Framework.Logging - ระบบการเข้าสู่ระบบแบบครบวงจร
• Framework.Services - ยูทิลิตี้สำหรับโต้ตอบกับบริการบนเว็บ
• Framework.Strings - ยูทิลิตี้สำหรับการจัดการสตริงขั้นสูง / การค้นหาสตริงฟัซซี่ ฯลฯ
• ...

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

หากพวกเขาเป็นเพียงตัวอย่างจริง ๆ และไม่ใช่วิธี / ชั้นเรียนจริงที่สามารถนำกลับมาใช้ใหม่ได้ง่ายคุณสามารถลองแจกจ่ายเป็นตัวอย่างข้อมูลโค้ดลงใน IDE (เช่นVisual Studio Code Snippets ) ทีมที่ฉันเคยทำงานด้วยในอดีตมีห้องสมุดตัวอย่างทั่วไปซึ่งทำให้ทุกคนสามารถปฏิบัติตามมาตรฐานการเข้ารหัสด้วยรหัสภายในได้ง่ายขึ้น

ฉันไม่เห็นด้วยกับคำตอบที่ยอมรับได้ด้วยเหตุผลหลายประการ

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

บางครั้งการละเมิด DRY อาจเป็นการประนีประนอมตามสมควร แต่จะดีกว่าการมีเพศสัมพันธ์อย่างแน่นหนา การใช้ซ้ำเป็นข้อกังวลรองเมื่อเทียบกับการออกแบบเชิงวัตถุที่ดี เล็กน้อย (ฉันหมายถึงจำนวนเล็กน้อยใช้กฎของสาม ) การทำซ้ำง่ายต่อการเข้าใจกว่าฐานรหัสปาเก็ตตี้

วิธีการของไลบรารีวัตถุประสงค์ทั่วไปจำนวนมากเป็นตัวอย่างที่ไม่ดี มันนำไปสู่การละเอียดของการประกอบและการประกอบมากเกินไปไม่ดี เมื่อเร็ว ๆ นี้ฉันได้ทำการลดขนาดห้องสมุดจาก 24 แห่งเหลือ 6 ห้องสมุด มันปรับปรุงการรวบรวมเวลาจากหลายนาทีเป็น ~ 20 วินาที Visual studio นั้นช้ากว่าในการโหลดและตอบสนองน้อยลงด้วยแอสเซมบลีที่มากขึ้น การมีห้องสมุดมากเกินไปก็ทำให้เกิดความสับสนว่าโค้ดควรอยู่ที่ใด ชอบกฎที่น้อยกว่าและเรียบง่ายกว่า

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

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

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

คำแนะนำของฉัน:

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

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

ขั้นแรกมันง่ายกว่าที่จะมีโค้ดที่มีประโยชน์โดยเฉพาะอย่างยิ่งเมื่อสร้างและแก้ไขข้อบกพร่อง

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

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

ทางออกที่สองที่คุณอธิบายนั้นไม่เลว ใน. NET คุณอ้างอิงแอสเซมบลีจาก GAC แม้ว่าคุณจะใช้คลาสเดียวเท่านั้น 'การลากรหัสที่ไม่เกี่ยวข้องออก' ไม่ใช่ปัญหาอย่างที่คุณคิด ในกรณีนี้มันเป็นสิ่งสำคัญอย่างน้อยให้วิธีการที่เกี่ยวข้องและการเรียนการจัดระเบียบอย่างหมดจดในเนมสเปซที่แตกต่างกัน นอกจากนี้ควรใช้แนวทางปฏิบัติที่ดีสำหรับการออกแบบ API เพื่อป้องกันไม่ให้โซลูชันนี้เกิดความยุ่งเหยิง

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

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

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

หากโครงการมีความละเอียดและเหมาะสมกับเนมสเปซแล้วฉันก็จะเห็นว่านี่เป็นวิธีที่ได้รับความนิยมในสถานที่

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

GitHub มีเครื่องมือที่มีประโยชน์มากสำหรับการบันทึกข้อมูลโค้ดhttps://gist.github.com/

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

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

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

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

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

ฉันพบปัญหามากและโซลูชันที่ฉันต้องการคือการโพสต์รหัสในที่เก็บเว็บที่เปิดใช้งาน github / pubic มันแก้ปัญหาได้มากมาย -

1. เข้าถึงได้ง่ายและแบ่งปันได้ง่าย cvs / svn / enterprise-repos หมายถึงการตรวจสอบโครงการในหลายพื้นที่ทำงานของ IDE และบางครั้งต้องเปลี่ยนพื้นที่ทำงานหรือคอมพิวเตอร์เพียงเพื่ออ้างอิงถึงข้อมูลโค้ดขนาดเล็ก
2. สมมติว่าตัวอย่างโค้ดเหล่านี้ไม่ใช่รหัสที่เป็นกรรมสิทธิ์ / เป็นความลับและเป็นรูปแบบของความรู้ที่เปิดเผยต่อสาธารณะโพสต์ใน repo สาธารณะเช่น github หมายความว่าคนอื่นจะมองมันและอาจมีส่วนร่วม
3. การโพสต์บางอย่างในโดเมนสาธารณะภายใต้ชื่อของคุณมีแรงกดดันด้านชื่อเสียงเพิ่มขึ้น คุณจะตรวจสอบและอัปเดตสิ่งต่าง ๆ อีกครั้งเนื่องจากมันสะท้อนให้เห็นถึงความสามารถของคุณในฐานะโปรแกรมเมอร์
4. การปรับปรุง สิ่งที่เกี่ยวกับการบำรุงรักษาโค้ดใน repo คือถ้าไม่ได้ใช้ snippet ในระยะเวลานานมันอาจจะเก่า (มี apis / libs ล้าสมัย) ตัวอย่าง - โค้ดจาวาโค้ดเพื่ออ่านไฟล์ คุณอาจจะค้นพบวิธีที่ดีที่สุดในการทำเช่นนี้ในปี 2009 แต่ในปี 2014 ไฟล์ API ใหม่ออกมาซึ่งเปลี่ยนแปลงทุกอย่าง ตัวอย่างของคุณ? ยังคงติดอยู่ในปี 2009 ใน repo สาธารณะสิ่งต่าง ๆ จะได้รับการอัปเดตไม่ว่าจะเป็นโดยคุณ (เนื่องจากสัญลักษณ์แสดงหัวข้อย่อย 3) เพื่อนร่วมทีมของคุณหรือสมาชิกบางส่วนของประชากรโปรแกรมเมอร์ทั่วไปและในกระบวนการคุณอาจได้รับคำแนะนำ คุณอาจทำผิดมาเป็นเวลานาน

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

เรามี "ยูทิลิตี้" โครงการแยกต่างหากที่เราเก็บวิธีการเล็ก ๆ เหล่านี้พร้อมกับการทดสอบ

เมื่อโครงการต้องการยูทิลิตี้บางอย่างเพียงแค่เพิ่มไฟล์ต้นฉบับด้วยวิธีการที่จำเป็นด้วย "เพิ่มลิงค์"

ซึ่งหมายความว่าจะไม่มีการเพิ่มการอ้างอิงเวลาทำงาน (เว้นแต่ไฟล์ที่รวมจะต้องมีหนึ่ง)

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

ความซับซ้อนอย่างหนึ่งของโครงการสาธารณูปโภคคือการตัดสินใจระดับการมองเห็นรายการ กฎง่ายๆคือวิธีการที่ควรเป็นโครงสร้างภายในและข้อมูลสาธารณะ

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

เห็นได้ชัดว่าวิธีนี้ใช้ได้กับแอปอินเทอร์เน็ตเท่านั้น (และใช้งานได้เพียงมิลลิวินาทีเท่านั้นเมื่ออยู่ในเครือข่ายท้องถิ่นเดียวกัน) แต่มันมีข้อดีที่ดีมาก ๆ

ฉันเพิ่งมากับบริการนี้: Snip2Code ( http://www.snip2code.com )

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

ยิ่งไปกว่านั้นมีหลายสถานการณ์ที่การใช้ห้องสมุดทั่วไปไม่สามารถใช้ได้: ลองพิจารณาตัวอย่างเช่นรูปแบบการออกแบบบางอย่างเช่น Singleton, Strategy หรือ Observer คุณสามารถสร้างห้องสมุดเพื่อสนับสนุนรูปแบบดังกล่าว แต่ยังไม่มีความครอบคลุม 100%

ความต้องการที่แท้จริงคือการมีเครื่องมือในการแบ่งปันแนวปฏิบัติทั่วไประหว่างทีม ฉันพยายามใช้ส่วนสำคัญของ Github แต่ฉันติดอยู่กับการค้นหาของพวกเขา (แย่มาก) และด้วยความจริงที่ว่าฉันไม่สามารถแบ่งปันให้กับทีมของฉันและไม่ได้อยู่กับคนอื่น ...

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