จะทำอย่างไรเมื่อการทำงานที่สำคัญของผู้ที่ต้องพึ่งพาเสียและเป็นอุปสรรคต่อการพัฒนา


12

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

เป็นการแก้ไขด่วนฉันเพียงโคลน repo แก้ไขปัญหาด้วยรหัสเดียวกันกับที่ PR มีและชี้ Gemfile ของฉัน (ไฟล์อ้างอิงเวอร์ชันการควบคุม) ไปยัง Github fork ของฉันเองจนกว่าข้อผิดพลาดจะรวมกันกลับเป็นหลัก

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

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

และแน่นอนว่าการฟันดาบบนเก้าอี้สำนักงานหลายชั่วโมงหรือหลายวันก็ไม่ใช่ทางเลือก ...

คำตอบ:


19

นี่เป็นหนึ่งในเหตุผลที่คุณใช้ซอฟต์แวร์โอเพ่นซอร์สใช่ไหม

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

หากซอฟต์แวร์ของคุณต้องพึ่งพาการพึ่งพาไลบรารีโอเพนซอร์ซคุณสามารถทำได้สามวิธีเพื่อลดความเสี่ยง:

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

  2. มีไลบรารี่ย้อนหลังหากไลบรารี่แรกล้มลง นี่คือเหตุผลที่คุณตั้งโปรแกรมอินเทอร์เฟซ เพื่อให้คุณสามารถเปลี่ยนการใช้งานได้หากคุณต้องการใช่ไหม

  3. สร้างสมดุลระหว่างความต้องการเลือดออกกับความต้องการเพื่อความมั่นคง (เช่นไม่ใช้ซอฟต์แวร์อัลฟ่า) คุณรู้ว่าคุณกำลังทำอะไรใช่มั้ย


ขอบคุณสำหรับคำตอบของคุณ Robert ใช่ฉันตัดสินใจใช้ Rails 5 สำหรับคุณสมบัติใหม่และไม่ได้วางแผนโครงการอย่างสมบูรณ์และไม่ทราบว่าไลบรารีนี้จะมีปัญหาความเข้ากันได้กับ Rails 5 ไม่เป็นไรฉันแค่ปล่อยให้สาขานั้นเป็น WIP และ ฉันกำลังตรวจสอบ repo Github สำหรับการแก้ไข ผมคิดว่าหนึ่งในบทเรียนหลักที่นี่คือการวางแผนที่ดี ถ้าฉันได้ทำการวิจัยที่มีค่ามากกว่าหนึ่งชั่วโมงก่อนเริ่มการพัฒนาฉันจะได้เห็นปัญหานี้แล้ว!
Chris Cirefice

11

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

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

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

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


1

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

  • คุณสามารถสลับห้องสมุดบุคคลที่สามกับห้องสมุดอื่นได้โดยไม่ต้องเปลี่ยนรหัสใด ๆ
  • คุณสามารถโปรแกรมส่วนที่เหลือของรหัสของคุณกับส่วนต่อประสานอะแดปเตอร์ของคุณเอง ในกรณีที่เกิดปัญหาชั่วคราวกับไลบรารี่เพียงแค่เสียบฟังก์ชั่นไลบราของคุณเอง ด้วยวิธีการพัฒนาและทดสอบคุณสมบัติดาวน์สตรีมของคุณจะไม่ถูกบล็อก (แม้ว่าการปรับใช้โปรแกรมเต็มรูปแบบยังคงเป็น)
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.