产品版本管理
date
May 14, 2025
slug
product-version-management
status
Published
tags
Product
summary
type
Post
这学期学校里开了一门实践课程，内容是以小组为单位协作开发设计出一套保险理赔应用。原先我对上课毫无兴趣，更别说需要小组合作的课程了，因为小组合作意味着逃课不便。这学期是大三的最后一个学期，我的大学生活也即将走向尾声，不舍的情感让我不再那么抗拒去上课，然而仅仅有这份不舍之情还不够，我们这家小创业公司的工作实在太紧张，想要抽出时间，需要情感之外的理由。我找到了这份理由，这门课的小组合作不同于其他课程，为期足够长，挑战足够大，能真正学到关于合作的东西。
为了和组内的同学更顺利的协作，我需要去搞透Git这个工具的每个边边角角，而以往我只需要了解几个基本的操作就足够应付日常所需。Git的设计十分精巧，一切基于由commit节点组成的graph，branch的概念通过一个指向当前分支最新节点的指针就得以实现，头指针（Head）串联起了工作区，版本回退，分支切换等丰富功能……
版本管理在尚且没那么复杂的软件工程领域，就已经十分重要。在复杂度可以高非常多的产品设计领域，版本管理更为重要了，于是就有了这篇博客。
由于产品形态的多样性，在产品版本管理方面，并没有出现一个Git式的强力工具，不过这不重要，我们掌握其思想即可。
产品版本管理最重要的原则是：不过度设计。在砍功能中我们曾聊到，“如果让砍功能变得简单，加功能变得困难，那么团队最终产出的产品质量一定会远远高于从前“，而这一思想的起点除了正交分解的组合理念之外，那次对话所没有提及的是，现实世界的动态性。泡泡玛特的王宁老板有个abcd理论，“本来你想做成a突然做成b，有可能是在c成功，然后有可能就d变得伟大”，在这纷繁变化的世界，这实在太精辟。而存在于这变化世界之中的产品，如果过度设计，就必然面临反反复复的拆迁工作，也许大费周章拆了重建，也许根本拆不动。为了尽可能不陷入这样的局面，我们必须在版本管理上保持足够的克制，不过度设计，不大跃进，不指望一个版本就能够一劳永逸。
对产品的版本管理来说，不同产品、不同团队的表现差别非常大，很多产品可能只迭代了一个版本就再也没有推出新版，这可能是出于克制，也可能是出于对变化的恐惧。我们千万不要忘记，不过度设计的另一层意思是，在能力范围之内做到最好。如果忘却了这一面，我们就容易丧失追求，不敢进行任何新的设计与变动，而这无异于在产品层面实现自杀，使得一个生命周期可能可以更长的产品过早的结束了生命。
目标与蓝图则表现为产品版本管理工作过程中的可见材料，当目标愈发清晰，蓝图愈发可行，可能就说明我们的工作走上了正确的方向。
理论枯燥无味，让我们来看看实例。学校，作为社会的基础设施产品，每年都将迎来一届又一届的新生，当新生入学的那一刻，不管校方是否愿意推动这古老产品的变动，学校的版本已然开始变化。得益于JS的流行，npm生态非常繁荣，许多包都在努力的持续迭代，而这其中不乏为了更新而更新的，甚至滥用破坏性的大版本号变动。《五年高考三年模拟》除了要在每年进行例行的习题更新之外，还要对书内结构进行思考与调整……The show must go on！