รุ่นใหญ่อย่างรวดเร็วชนกับหลักฐานของการออกแบบที่ไม่ดีหรือไม่?

16

ฉันเริ่มงานเป็นโปรแกรมเมอร์รุ่นพี่เมื่อไม่กี่เดือนที่ผ่านมา ระบบที่เรากำลังดำเนินการอยู่ได้รับการผลิตเป็นเวลา ~ 2 ปี ฉันไม่ได้เกี่ยวข้องกับการขอร้องของระบบและการออกแบบ

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

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

versioning semantic-versioning

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

2

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

— ร.

3

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

— amon

3

@amon ระบบใช้ภายในกับลูกค้ามือถือสาธารณะที่สื่อสารกับระบบผ่าน API ที่คล้ายกับ REST การกำหนดเวอร์ชันคือ Semver ตามที่ฉันกล่าวถึงไม่ใช่เวอร์ชันการตลาด

— user367035

ตัวเลขไม่สำคัญ แต่ฉันจะสงสัยถ้าตัวระบุเวอร์ชันมีคำย่อน่ารัก ๆ เช่น Windows NT หรือ Windows ME หรือ XP หรือ Windows จริงๆ

— John Wu

1

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

— Jörg W Mittag

14

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

ไม่จำเป็น.

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

นอกจากนี้ค่าเฉลี่ยอาจทำให้เข้าใจผิดอย่างหนาแน่น: บางทีพวกเขาอาจมีการเปลี่ยนแปลง API 11 ครั้งในช่วงสองสามวันแรกของการพัฒนาและมีเสถียรภาพตั้งแต่ 4 ปี? SemVer อนุญาตให้คุณทำการเปลี่ยนแปลงโดยไม่เพิ่มหมายเลขหลักหากหมายเลขหลักคือ 0 แต่ไม่บังคับให้คุณ บางทีพวกเขาอาจเริ่มใช้ SemVer ตั้งแต่วันที่ 0 ถึงแม้ว่าจะอยู่ในช่วงการสร้างต้นแบบ / ขั้นตอนการสำรวจ?

— Jörg W Mittag
แหล่งที่มา

5

คำตอบนี้ดูเหมือนจะตอบคำถามโดยตรง บางคำตอบอื่น ๆ จะใช้ได้ถ้าไม่ใช่สำหรับสมมติฐานของ OP ของการกำหนดเวอร์ชันเชิงความหมาย

— joshp

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

— Kat

1

คำตอบสั้น ๆ

ไม่

คำตอบที่ยาว

"บางครั้งตัวเลขก็แค่ตัวเลข"

ลืมเรื่อง "semantic versioning", "rationality", "logic" ในโลกปัจจุบันที่บ้าคลั่ง

เหตุใด Chrome จึงฮุบเลขเวอร์ชันอย่างรวดเร็ว

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

— ขี้เกียจแบดเจอร์
แหล่งที่มา

7

OP ได้กล่าวว่าพวกเขากำลังใช้การกำหนดเวอร์ชันความหมาย ทำไมคุณไม่สนใจมัน?

— Jörg W Mittag

-3

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

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

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

บางโปรแกรมมีการพึ่งพาภายนอกที่มีความสำคัญสูงสุดเนื่องจากผู้ใช้จะต้องอัปเดตทั้งสองในเวลาเดียวกัน ถ้าคุณมี Word-addon ที่ใช้งานได้กับ Word 2010 และอีกอันสำหรับ Word 2013 คุณอาจต้องการซิงโครไนซ์หมายเลขเวอร์ชันหลักของคุณกับ MS-Word ที่นี่ตัวเลขสำคัญมีความสำคัญมากเนื่องจากผู้ใช้ของคุณบางคนจะ "ล้าหลัง" กำหนดการอัปเดตปกติของคุณเนื่องจากพวกเขาไม่ได้อัปเดตเป็น Word เวอร์ชันปัจจุบันมากที่สุด (หรืออะไรก็ตามที่คุณพึ่งพา: SAP, Dynamics, ฯลฯ )

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

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

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

3

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

— Jörg W Mittag

1

@ JörgWMittagไม่ว่าฉันจะอ่านผิดหรือสเป็คพิเศษบอกว่าเมื่อคุณต้องชนหมายเลขรุ่น แต่มันไม่ได้พูดอะไรเลยเมื่อคุณอาจ

— Hazzit

-4

ข้อสรุปเกี่ยวกับความหมายของหมายเลขเวอร์ชันเป็นวิชาเอกที่สำคัญ minor.revision.buildnumber

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

ในโลกธุรกิจอย่างไรก็ตามอาจมีสาเหตุอื่นสำหรับการเพิ่มหมายเลขรุ่นหลัก ชอบ

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

— Martin Maat
แหล่งที่มา

6

คำถามถูกติดแท็กด้วยsemantic-versioning , OP กล่าวถึง semantic versioning ในคำถามและยืนยันอีกครั้งในความคิดเห็นที่พวกเขาใช้ semantic versioning ข้อมูลจำเพาะของ SemVer กล่าวอย่างชัดเจนมากเมื่อมีการเพิ่มรุ่นหลัก ไม่มี "เหตุผลอื่น" ที่คุณใช้

— Jörg W Mittag