今天 因为iOS 开发的内部版本号耿耿于怀好久，释然后让我有了一个新想法：从前，能让我兴奋的点是解决一个有一个拗脑筋的问题，见大部分博客便知，都是技术方面的积累。
那么从今天起我决定让自己有个新起点，我要为成为一名出色的架构师而努力奋斗了。
起因: 发布了新的测试包，为 iOS 2.0.0(
2.0.0.2) ，项目管理人员，不懂括号是什么意思。
对话场景：
我：是内部版本号。
他：能不能写成整数？
我：安卓是有的 （想起安卓是build 一个整数 只升不降）
他：iOS能也是整数吗
我：不理解 你这么干的意义 版本号 包括一个或多个时期分隔的整数。内部版本号build也一样，虽然简单来说 每次要比上一次大，但是 用以记录开发版本的版本号和发布版本号同样重要，版本号的管理是一件非常谨慎的事情
他：是的，我只是想了解编号规则，外部/内部要尽量分开，尽量不能混淆
比如一个是2.0.0 另一个是412
。。。。。
中断过程，我在我的几个技术群里发起讨论，全部回答不过于：“当然可以写成整数，不过我不这么写。”的结论
他来到我工位面前继续讨论
他：改成整数有什么问题吗(应该是不满意 我上面的回答)
这么改，内部版本号和外部版本号就分开了并且不混淆，结构非常清晰，并且 你会知道你这个版本打了多少个包
我：（1）内部版本号可以跟踪每一个发出的版本，发出的错误 ，定位错误信息具体发生的位置
(2) 正式版本有利用外部版本号区分版本 做强制升级的作用，版本号分割的每一级别每一时期都有区分。当然内部版本号也可以发挥这个作用
(3) 参考了同行业人员，虽然可以，但并没有人这么写或者说这么写的人不是大多数
他：这个理由不好 （应该是整数也可以blabla的意思）
我：如果你觉整数版本号能够知道打多少包，有这个需求的话，分段式版本号是可以实现的，不觉得哪里还有不妥
。。。
剩下的过程，他一直强调我在紧张，我平常处理矛盾方式是，认怂和妥协来避免冲突。毕竟冲突时刻，不是用脑子用的是情绪。我不是紧张，而是一直动脑想表达分段内部版本号是谨慎，广泛，友好的。
但是他的话术起左右了，说紧张我的音量就提高放大的告诉他，我怕他。。。（现在觉得我不该那么说，不够理智，这是话术的作用，被对方一直揣测情绪变化，反而真的有情绪变化。根本原因 就是我不够强大，心理和技术表达 两个方面，唯一值得表扬的是技术立场的坚持）
上午，在争论后，和一堆琐事中结束，但是我的思考没停止。
“这不是理由，我想听理由。。。” 如果是CTO，对技术人员来说很有指导意义，但是目前能对iOS产品端负责的人是我，有且只有我能负责iOS技术担当和架构担当， 我应该有充分的站得住的立场。
我想了好久，其实这还可以从好多角度去考虑这个问题。
重点来了：
（1）内部版本号到底该对谁友好？
内部版本号 应该是对开发人员有好的重要参数，记录了每一个新产生的版本包括的内容产生情况和即每个build都记录你的 ipa 包和套装的联系。 （整数并没有体现对开发人员更友好）
（2）上面有提到 使用整数作为内部版本号，是小众使用，如果出问题，是小众问题，偏问题，解决效率大打折扣，存在一定时间内无解可能 。 而分段式版本号是最普遍业内人士开发者遵循并使用的。即使出了问题，也是大众问题，也会是容易迎刃而解的问题。 （相比而言，我们不是一个技术创公司，比不上苹果，微软 我们拿什么胆量来 才承担使用类似偏技术，小众使用的方法规则带来的后果）
(3) 知道产品迭代包的个数 ，或者怎么能清晰表达产品迭代 这个是什么问题？
这应该是一个需求 不应该是技术选择 。
技术选择应该是架构师考虑的事，而不是项目管理替技术人员做选择的事。架构师只需要规约成一个功能方案。达到需求目的
（此时方案已经和谐成了内部版本号最后一位做累加，直观表示内部版本开发阶段打包次数）
当然还有别的解决方案，比如做登记表，统计每一次打包 迭代内容，甚至把每一次打包都存到公司云管理上。甚至每打一个包都要打tag,方便用来复现和深度追踪问题
并且打多少包还和测试程序，测试节奏有关系。
参考安卓，连续四天天打出的包都叫 1.1.0 (Build 28)这样怎么追踪问题呢？？ 是哪个具体子版本出了问题？目测只知道是第28个包，但是不出来是哪个内部版本，或者团队合作打出的分支功能测试包之类的。（分段版本号的意义在此凸显）
随着公司不断引进新的牛逼的技术人才，突然一眼看到我们的内部版本号不是分段的，是个整数。会不会对我们整个技术团队的信赖感甚至公司的认同感都会大打折扣？
总结：
当有人 给你提问题的时候，你要动脑认真思考一下他问你的问题的本质。
他问的到底是个什么问题？ 这时候 不需要激情反对，也不需要完全妥协。
如果是功能性方面有需求，那么我们就应该用技术去翻译 解决。
如果是技术上的问题，尤其是牵涉到技术使用了，那么提出的人是谁？
如果是CTO,你的技术主管，这个技术指导意义非常大，并且CTO能够对技术使用负责。
如果是公司其他职位的人，向技术人员提出的问题只能是功能性质的问题，不能是技术问题，因为他们不会对技术负责。其次，有且只有你自己能对自己的使用技术负责。
说道这，真的觉得豁然开朗。
不是有冲突就不好，真的能让自己成长。
参考：
1. https://developer.apple.com/library/content/technotes/tn2420/_index.html#//apple_ref/doc/uid/DTS40016603-CH1-VERSION_NUMBER_AND_BUILD_NUMBER_CHECKLIST
转载于:https://www.cnblogs.com/someonelikeyou/p/7923386.html