【测开方法论】测开平台pk心得-抉择

作者曾经在某大厂，看到了内部gitlab上居然有着好几页的测试平台，看了一些redme, 发现功能设计很好，代码随便看了一点，发现写的很工整也很巧妙，但是为何会放在gitlab上落灰呢？

此情此景，就好像我身处一片早已结束的古战场上，看着遍地狼藉。倒在地上的，不乏装备精良的将军。  

此时此刻我明白了一个道理：俩个人比武，最终赢的人，不一定是装备最好的，身体最强的。大多数情况下，赢的人只是技巧和套路更高而已。  

**以此类推到测试平台的pk中，赢的那个并不一定是代码写的好的，也并不一定是架构设计巧妙的那个，大多数情况下，是平台开发者的套路更高而已。**

这个套路，不单单是代码的技术，而应该打开格局，是更多更上层的思考。  

比如今天要讲的一点：抉择

开发一个平台，尤其是没有产品经理，没有需求人员，没有ui设计，没有运维支持，没有多人配合。而是单枪匹马的去创造一个解决痛点的平台，这就是测开的宿命。

在这种情况下，你需要面临的风险和不可控性会非常大。很多时候都要面临抉择，比如一个功能开发过程中，你突然发现设计上有瑕疵，此时重构可以让这个功能上限更高更完美，但是时间上不太够。此时你应该怎么办？然后想想，领导似乎很着急上线，还是不太着急，领导比较讨厌缺陷呢？

你此时会想：如果先按原设计实现准时上线，然后以后有空再重构？那样太麻烦了，到时候重构成本也太高，一旦线上被吐槽，就会损失用户，损害自己形象。  

而要是推翻目前设计，立即重新做？那样很可能无法按时上线，如果有其他竞争对手先抢了坑，到时候你的平台就会被扣一个帽子：重复造轮子 。然后被领导无情腰斩。  

再比如，你在开发过程中发现了一个功能可以优化做的更好，但是这是一个使用频率不高的功能，如果要是不计成本的优化，那么肯定是划不来的。  

  

再比如，某个设计，很nice，但是很可能会出现多个风险和恶性bug，自己当下并没有时间去修改bug，也没有时间去冒险。此时你是选择这个优秀的设计，还是放弃呢？  

.....  

无数的抉择，你能否选对，才是你是否能够成功的关键。  

就像你是一个创业者，你突然发现社会上的某个需求，你急需开发一款app来占领市场，此时你的竞争对手可能也发现了这些，也在偷偷研发。  

你要怎么做？是更快速度抢占市场，引导用户习惯，制定行业标准，提高用户粘度，增加护城河。还是放弃速度，专心质量，让对手先占，然后自己再后发制人？无论怎么做，风险都很高，这也就是一场抉择。

抉择对了，不一定是天堂，因为后面还有大大小小的很多个抉择等着你，你是否能高瞻远睹，运筹帷幄，决胜千里很难说。  

但是抉择错了，那一定是地狱，未来能不能翻身估计也够呛了。  

很多时候，只顾埋头干活写代码不一定是好事，你要多抬头看看周围环境，然后权衡利弊，在平台开发过程之后的多个抉择中，要如何选择。  

这，才是真正的智慧！  

有句话说的好：过早的优化是万恶之源。  

但也有句话说得好：匠人精神，追求卓越。  

在整个平台开发的过程中，你就是在经历和指挥一场战斗，代码写的好那只是你的小规模战术胜利，但是战略如果不行，那么下场还是输。  

这种情况无论是在大公司还是小公司，都普遍存在。许多平台后起之秀，明明更优秀，但是却总是无法立项和推广落地，原因就在于战略上失败了。因为你忽略了公司内各个层级，各个部门，各个职位的人的心理和立场。  

在诸如：优化，流畅度，安全，风险，bug，维护成本，运营成本，易用性，效率性，功能实现，速度 等等这些元素发生冲突后，你要怎么抉择呢？  

会有一本书会给你讲过应该怎么抉择么？不可能有的。  

因为永远没有正确的答案，在不同的时间，不同的地点，不同的公司，不同的同事，不同的领导和不同的你，不同的测试平台上，答案都不会相同，甚至很多时候没有正确答案，或者都是正确答案。  

而能保证自己做出正确抉择的唯一方法，就是多多练习，多多经历，然后悟出里面的规则。  

但可惜的是，不是所有人都有足够的经验来升级。

这些东西，最好的办法就是跟着一个经验丰富的师傅身边工作，每天察言观色，久而久之，吸收经验，站在师傅的肩膀上。