题图： TGO鲲鹏会上海分会三周年庆
上周末是TGO鲲鹏会上海分会三周年，也许因为天生厚脸皮的缘故，又或许因为有董事会身份的 “光环”，不仅让我在整个聚会中收获颇丰，并认识了一些志同道合的新朋友。
无论大会，还是聚会，我始终保持着早到的习惯，这项习惯既能助我占个好位置，又能充当吹牛皮的资本，所以这次也不例外，我足足比原定时间提前了一小时到达，但推门那一刹那，我顿感这次牛皮估计吹不成了，为啥？有位深圳会员比我早到，居然顶着强台风 “山竹”，翻越千山万水，提前到达了晚会现场。
在我的印象里，他因工作原因需常年逗留在香港，而香港高楼大山密度那么大，相比其他城市，强台风应该对香港造成灾难性的打击，交通应该全部瘫痪才对啊。他听后笑着回答道，有点你别忘了，香港，乃至珠三角，是我国国内台风遭遇次数、强度最大的区域，无论是设计之初，还是发展过程中的迭代或重构，可以说是身经百战、经验颇丰。另外，我国所有沿海城市，基本都经受过自然灾害的考验，为什么它们可以发展至今？历史上又有多少伟大的城市淹没在了大海或黄河中？
这一番科普很有威力，最后他又补充了一句「城市与系统一个道理，没有一套优秀的系统是靠设计得来的，而是靠不断演化与迭代逐渐形成的」。
的确，喝着茶，扯着蛋，总觉得大道理是金石良言，一旦进入实战场景，又有多少技术小伙伴会将这种觉悟贯彻到底？估计都在做着 “追求一战成名，并被推崇为偶像，名利双收，加官进爵” 的千秋大梦。
不信？我拿个还热乎的案例解读下这种感受。
两个月前，为加快交付速度与质量，某产品团队提出接入持续集成平台的需求，其目的是为了将原先杂乱无章的自动化测试脚本通过平台进行管理，并使用定时/手工两种触发方式生效，最终形成报告。
无论从技术难易度，还是资源使用率，这样的需求都不算复杂，所以平台负责人不仅爽快答应，并迅速在一星期后提交了方案初稿。
（平台方提交的方案）
在平台架构师的眼里，这个方案的优点有以下五点：
动态链接测试脚本SVN库
实时下载最新测试脚本
自动化流水线编译打包（Java语言）
自动化运行用例，自动生成报告
将报告与结论发送至产品负责人
不得不承认，这套流水线堪称完美，一步到位，用户体验极佳，难怪在宣讲过程中，脸上时刻都洋溢着得意的笑容。
一个巴掌拍不响，一个人自嗨也没啥乐趣，在客户的眼里是不是也这么想？
在产品团队的眼里，这个方案不仅难以实施，甚至有些画蛇添足，质疑有以下五点：
暂时没使用SVN管理脚本，后期规划也没讨论过。
脚本更新频率为周更新，数量也就几十个，要那么实时干嘛？
几个破脚本本地编译下就行了，要哪门子自动编译呀。
测试环境的问题怎么解决？由平台方提供自动化构建？还是自己搞？
流水线固然好，但如果SVN挂了，或编译打包出问题了，该如何处理？
（需求方提出的方案）
在短暂讨论后，产品团队（需求方）提出了自己的方案，理由也很简单，“面对现状，以最低成本直击痛点，后期逐渐迭代”。这番看似务实的论调，显然激起了平台方的不满，开始充满火药味的争论起来。
平台方的觉得，不就建个SVN库吗？这很难吗？自动化更新功能即便你现在用不到，未来也许会用到呢？都在本机编译的话，你们怎么保障JDK版本的一致性问题？还好意思说测试环境，你们的产品，难道还要我们来给你们搭建环境吗？SVN与编译系统都啥年代的系统了，还会宕机？你们在怀疑我们的高可用能力吗？
总而言之，平台方认为自己的职责是提供高效而全功能的工具，其他的都应由产品方自己解决，而需求方则觉得，平台方更应从实际情况出发，充分与需求方沟通有关的技术债、人员编制、资源投入，以解决痛点为目的，不应贪功心切，更不应追求完美，一步到位。
说到这也许有人问，最后的结果是什么？我挺身而出，在一番安慰后，婉言驳回了平台方的方案，选择了需求方的方案。
这样的案例每天都在发生，在面试时也遇到许多候选人聊起过类似事件，有的认为对方都是傻X，是他们瞎了狗眼不识真货，有的认为团队没有技术文化，领导就是个吉祥物，最大的能力就是装B，瞎指挥。
那没问题，离开这里就行了，找你的极乐世界去，还记得《大话西游》中唐僧是怎么对孙猴子说的？「等你明白了舍生取义的道理，你自然会回来和我唱这首歌的」。
当今许多的技术小伙伴都觉得， “想要名利双收，就往死里钻研技术，不就完了？” 其实我觉得，语言的掌握、对框架的掌握、数据库管理能力、安全管理能力等都是对技术的综合运用上，我曾在某次分享中谈到，“很多人都在谈技术执行力，究竟指的是啥意思？我认为，抛开软技能不谈，少些大道理与抱怨，领导团队极其面对客观现实，在仅有的天时、地利与人和的条件下，通过一步一个脚印将业务目标平稳落地。”
所以说，不要让你的完美主义，毁了你的技术执行力。
- END -
欢迎朋友圈分享转发
欢迎加入知识星球交流、讨论
原文作者：头哥侃码；如有侵权，请联系管理员删除。
