วิธีจัดการกับความกลัวในการพึ่งพา

54

ทีมของฉันในการสร้างส่วนประกอบที่พันธมิตรของ บริษัท สามารถใช้เพื่อรวมเข้ากับแพลตฟอร์มของเรา

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

ตัวอย่างบางส่วน:

เราถูกบังคับให้อยู่ในระดับ API ต่ำสุดของกรอบงาน (. NET Standard) เหตุผลเบื้องหลังสิ่งนี้คือว่าแพลตฟอร์มใหม่อาจมาถึงวันหนึ่งที่รองรับเฉพาะระดับ API ที่ต่ำมากเท่านั้น
เราได้ดำเนินการส่วนประกอบของเราเองสำหรับ (de) การทำให้เป็นอันดับ JSON และอยู่ในกระบวนการของการทำเช่นเดียวกันสำหรับ JWT สิ่งนี้มีอยู่ในเฟรมเวิร์ก API ที่สูงขึ้น
เราได้นำ wrapper ไปใช้กับเฟรมเวิร์ก HTTP ของไลบรารี่มาตรฐานเพราะเราไม่ต้องการพึ่งพาการใช้ HTTP ของไลบรารี่มาตรฐาน
รหัสทั้งหมดสำหรับการจับคู่กับ / จาก XML ถูกเขียน "ด้วยมือ" อีกครั้งด้วยเหตุผลเดียวกัน

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

— Bertus
แหล่งที่มา

20

มีเหตุผลสำหรับเรื่องนี้ (เช่นข้อกำหนดภายนอก) หรือมันถูกทำออกมาจากความไม่รู้?

— Blrfl

6

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

— Filip Milovanović

73

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

— UKMonkey

8

ที่กล่าวว่ามีทางเลือกอื่นหลังเช่นไม่เคยจบโครงการ แต่มันจะส่งเสริมการใช้งานซอฟต์แวร์และการจ้างงาน :)

— marshal craft

5

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

— Eric Lippert

94

... เราถูกบังคับให้อยู่ในระดับ API ต่ำสุดของกรอบงาน (. NET Standard) ...

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

.NET Standard ไม่ได้และจะไม่ " ระดับ API ต่ำสุดของกรอบงาน " ชุด API ที่ จำกัด มากที่สุดสำหรับ. NET นั้นทำได้โดยการสร้างไลบรารี่แบบพกพาที่มีเป้าหมายเป็น Windows Phone และ Silverlight

คุณสามารถลงเอยด้วยชุด API ที่สมบูรณ์ซึ่งเข้ากันได้กับ. NET Framework ,. NET Core , MonoและXamarinขึ้นอยู่กับเวอร์ชันของ. NET Standard ที่คุณกำหนดเป้าหมายไว้ และมีไลบรารีของบุคคลที่สามมากมายที่เข้ากันได้กับ. NET Standard ซึ่งจะทำงานบนแพลตฟอร์มเหล่านี้ทั้งหมด

จากนั้นจะมี. NET Standard 2.1 ซึ่งมีแนวโน้มที่จะวางจำหน่ายในฤดูใบไม้ร่วงปี 2019 ซึ่งจะรองรับโดย. NET Core, Mono และ Xamarin จะไม่ได้รับการสนับสนุนโดย. NET Framework เวอร์ชันใด ๆ ก็ตามอย่างน้อยในอนาคตอันใกล้และมีแนวโน้มที่จะเกิดขึ้นเสมอ ดังนั้นในอนาคตอันใกล้ไกลจากการเป็น " ระดับ API ต่ำสุดของกรอบงาน " มาตรฐาน. NET จะเข้ามาแทนที่เฟรมเวิร์กและมี API ที่ไม่ได้รับการสนับสนุนจากหลัง

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

จากนั้นมีปัญหาของห้องสมุดบุคคลที่สาม ตัวอย่างเช่น JSON.NET เข้ากันได้กับ. NET Standard ไลบรารีใด ๆ ที่เข้ากันได้กับ. NET Standard จะรับประกัน - API-wise - เพื่อทำงานกับการใช้งาน. NET ทั้งหมดที่เข้ากันได้กับ. NET Standard เวอร์ชันนั้น ดังนั้นคุณจะไม่สามารถใช้งานร่วมกันได้โดยไม่ใช้มันและสร้างไลบรารี JSON ของคุณ คุณเพียงแค่สร้างงานให้ตัวเองมากขึ้นและเสียค่าใช้จ่ายที่ไม่จำเป็นสำหรับ บริษัท ของคุณ

ใช่คุณเห็นด้วยกับสิ่งนี้มากเกินไป

— เดวิดอาร์โน
แหล่งที่มา

16

"คุณเพียงแค่สร้างงานให้ตัวเองมากขึ้นและเสียค่าใช้จ่ายที่ไม่จำเป็นสำหรับ บริษัท ของคุณ" - และหนี้สินความปลอดภัย ตัวเข้ารหัส JSON ของคุณทำงานล้มเหลวพร้อมกับสแต็กโอเวอร์โฟลว์หากคุณให้วัตถุที่เรียกซ้ำได้หรือไม่ parser ของคุณจัดการอักขระที่หลีกเลี่ยงได้อย่างถูกต้องหรือไม่? มันปฏิเสธอักขระที่ไม่ใช้ค่า Escape หรือไม่ที่ควร? แล้วตัวละครตัวแทนที่ไม่ได้จับคู่ล่ะ? มันล้นเมื่อ JSON เข้ารหัสจำนวนมากกว่า 2 ^ 64 หรือไม่ หรือเป็นเพียงevalเสื้อคลุมตัวเล็ก ๆ ที่มีการตรวจสติที่ถูกข้ามได้ง่าย?

— John Dvorak

4

"ชุด API ที่ จำกัด มากที่สุดสำหรับ. NET นั้นทำได้โดยการสร้างไลบรารี่แบบพกพาที่มีเป้าหมายเป็น Windows Phone และ Silverlight" ฉันจะออกไปที่แขนขาและอ้างว่ามีอย่างน้อย APIs บางส่วนในชุดย่อยที่ไม่สนับสนุนการใช้งานที่เป็นไปได้ทั้งหมดที่เคยมีอยู่ (และไม่มีใครสนใจ WinPhone หรือ Silvernight อีกต่อไปไม่ใช่แม้แต่ Microsoft) การใช้. NetStandard 2.0 เป็นเป้าหมายสำหรับเฟรมเวิร์กสมัยใหม่นั้นดูรอบคอบและไม่ได้ จำกัด เฉพาะ การอัปเดตเป็น 2.1 เป็นเรื่องราวที่แตกต่างกัน แต่ไม่มีสิ่งบ่งชี้ว่าพวกเขาต้องการทำเช่นนั้น

— Voo

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

— แจสเปอร์

51

เราถูกบังคับให้อยู่ในระดับ API ต่ำสุดของกรอบงาน (.net มาตรฐาน) เหตุผลเบื้องหลังสิ่งนี้คือว่าแพลตฟอร์มใหม่อาจมาถึงวันหนึ่งที่รองรับเฉพาะระดับ API ที่ต่ำมากเท่านั้น

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

เราได้ดำเนินการส่วนประกอบของเราเองสำหรับ (de) การทำให้เป็นอันดับ JSON และอยู่ในกระบวนการของการทำเช่นเดียวกันสำหรับ JWT สิ่งนี้มีอยู่ในเฟรมเวิร์ก API ที่สูงขึ้น เราได้นำ wrapper ไปใช้รอบ ๆ เฟรมเวิร์ก HTTP ของไลบรารี่มาตรฐานเพราะเราไม่ต้องการพึ่งพา HTTP impelemntation ของไลบรารี่มาตรฐาน รหัสทั้งหมดสำหรับการจับคู่กับ / จาก XML ถูกเขียน "ด้วยมือ" อีกครั้งด้วยเหตุผลเดียวกัน

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

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

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

— berry120
แหล่งที่มา

3

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

— การแข่งขัน Lightness กับโมนิก้า

5

จุดยอดเยี่ยมที่สิ่งที่ระดับต่ำกว่าตายเร็วขึ้น นั่นคือจุดรวมของการสร้าง abstractions

— การแข่งขัน Lightness กับโมนิก้า

"เก่ากว่าระดับ API ที่ต่ำกว่ามีแนวโน้มที่จะล้าสมัยและไม่รองรับมากกว่าที่ใหม่กว่า" ฮะ? NetSTandards นั้นถูกสร้างขึ้นมาให้สูงที่สุดเท่าที่ฉันรู้ (ความหมาย 2.0 คือ 1.3 + X) นอกจากนี้มาตรฐานยังเป็นเพียงว่า .. มาตรฐานไม่ใช่การนำไปปฏิบัติ มันไม่มีเหตุผลที่จะพูดถึงมาตรฐานที่ไม่ได้รับการสนับสนุนในการนำไปปฏิบัติที่เฉพาะเจาะจงที่สุดของมาตรฐานนั้นอาจจะมีในอนาคต หากไลบรารี่ของคุณไม่ต้องการอะไรนอกเหนือจาก NetStandard 1.3 ไม่มีเหตุผลที่จะเปลี่ยนเป็น 2.0

— Voo

11

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

ตัวอย่างเช่นพวกเขาอาจเซ็นสัญญากับลูกค้าโดยสัญญาว่าจะไม่ใช้ผลิตภัณฑ์โอเพ่นซอร์ส

อย่างไรก็ตามในขณะที่คุณชี้ให้เห็นคุณสมบัติเหล่านี้ไม่ได้โดยไม่เสียค่าใช้จ่าย

เวลาไปตลาด
ขนาดบรรจุ
ประสิทธิภาพ

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

หากลูกค้าทั้งหมดใช้ Json.NET อยู่แล้วให้ใช้มันในผลิตภัณฑ์ของคุณแทนที่จะใช้รหัสดีซีเรียลไลเซชั่นลดขนาดและปรับปรุงให้ดีขึ้น

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

— Ewan
แหล่งที่มา

11

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

— Bertus

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

— Ewan

12

"พวกเขาอาจเซ็นสัญญากับลูกค้าโดยสัญญาว่าจะไม่ใช้ผลิตภัณฑ์โอเพ่นซอร์ส" - พวกเขาใช้. NET Standard ซึ่งเป็นโอเพ่นซอร์ส มันเป็นความคิดที่ดีที่จะเซ็นสัญญานั้นเมื่อคุณอ้างอิงผลิตภัณฑ์ทั้งหมดของคุณในเฟรมเวิร์กโอเพนซอร์ส

— สตีเฟ่น

และผู้คนก็ยังทำได้

— Ewan

7

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

— Double Vision Stout Fat Heavy
แหล่งที่มา

2

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

— TKK

0

โดยทั่วไปทุกอย่างจะลงมาสู่ความพยายามและความเสี่ยง

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

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

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

— Dominic Hofer
แหล่งที่มา

-2

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

ด้วยวิธีนี้หากใครบางคนต้องการฟังก์ชั่น "Core" เท่านั้นพวกเขาก็สามารถทำได้

หากใครบางคนต้องการฟังก์ชั่น "ธรรมดา" พวกเขาสามารถมีได้

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

— Turtle1363
แหล่งที่มา