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

·  阅读 42

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

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

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

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

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

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

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

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

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

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

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

    

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

    .....

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

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

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

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

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

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

    这,才是真正的智慧!

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

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

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

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

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

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

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

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

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

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

   

分类:
开发工具
标签:
收藏成功!
已添加到「」, 点击更改