本文由 简悦 SimpRead 转码， 原文地址 mp.weixin.qq.com
一、提高定义问题本质能力
- 定义业务本质
套用标准的问问题流程，“凡事先问是不是，再问为什么”。
想解决问题，首先就是定义问题，定义问题的能力，才是从一堆复杂的现实世界表象里，明白问题的本质。
因为很多人带来的问题，极有可能只是问题的表象，如果只是单纯被带进了问题表象，很大的可能是费力还无法解决问题，同时给提问人来带能力差的印象。
更好的定义问题，才能自己真正需要解决的问题，当定义清晰之后，才能发现问题是不是值得解，最优解，当前解，长期解。
实际上，当出现问题时，很多人就立即动手开始上手各种工具或者凭借已有经验开始分析，往往这个时候需要花更多的时间来定义真正的问题。
比如我在处理一个行业化工作台创建的时候，客户长时间停留在降级的 native 页上，然后伴随多次刷新，于是表现就是 “降级并且还多次刷新”。降级的本质是推送延迟，刷新的本质是多次推送，因为问题的本质其实是” 推送慢且推送多次的原因是什么”。
只有把问题厘清，才可能找到最高效解决问题的路径。
回到具体业务需求和问题，先定义清楚需求是要解决什么问题，解决此类问题的价值是什么，下一步才是分析如何解决问题。
- 定义代码接口
和写代码一样，我在刚毕业实时，觉得第一步就应该开始写业务的具体实现代码，然后再回头修改代码 interface。最后总发现，接口往往和实现不一致，要不就是入参定义不一致，要不就是返回值定义不一致。只能匆匆忙忙的反复修改，现在再回头看，发现最重要的第一步，就是定义 interface，即定义要写的抽象功能，而非具体的实现。接口定义好了，等于编码成功了 80%，剩下的实现，应该都可以不用带着脑子就可以完成。借用《思考快与慢》的说法，系统 2 完成了复杂的设计，剩下的，交给不需要思考的系统 1 即可。
以前总是以自己实现了某个功能 / 算法获得成就感，现在再想，其实定义出功能 / 架构 / 算法，才是最核心的也是最难的步骤，就和设计大楼一样，设计出几百米的上海大厦才是最难的，而把楼盖起来，随意找个有资质的施工队按时间推进即可。
- 定义业务骨架和核心节点
对于较为复杂的项目，需要先定义出骨架和节点，然后进行流程编排，最后才是实现，而骨架和核心节点的定义，至少要占到整体工程实践的 80% 以上。这样才不会在实际编写代码的时候，不断返工甚至上线及其不合理导致后期无法维护的历史逻辑。
二、形成高效心流工作窗口
记得刚毕业的时候，经常听师兄们说的，就是 “基本上白天都是各种杂事，只有晚上才有点时间写代码”。
物理学家说，乱才是世界本质，维持熵减是需要能量的。因此外部环境是不会给你形成一个良好的、沉浸式、心流式的工作环境的。最大的能控制的变量还是你自己，如何才能更好的安排出自己心流的工作窗口，是实现高效工作的前提。毕竟，除了你自己逼你成长，其他人没有绝对义务帮你成长。
我自己的总结，当我能想到极好的产品方案、技术方案时，都是一个人安静的时候；文思如泉涌的时候，也是一个人安静到时候；代码写的顺畅，调试流畅不烦躁，也是一个人安静的时候；
因此要学会给自己一点高效勿扰工作窗口，关闭手机提醒，不看 @，不看微信，不被隔壁同事声音打扰，安安静静写完一个技术方案、写完一段代码、调完一个 BUG，也许这一天，这就是最高效的工作时刻。
三、善用工具
同等时间，效率高产出就更多；
听过一个大神的说法，一个合格的业务开发，80% 的时间应该用在写文档、画序列图，20% 放在实际的编码上。而很多同学在测试上、定位问题时，花费了过多的时间。以阿里巴巴的 AONE 部署为例，一般应用的部署平均在 6 分钟，因此一次调试如果无法定位，就需要再部署一次，结合代码修改，平均一次验证预计需要 15 分钟。一个小时只能验证 4 次，因此效率是极低的，如何高效调试和验证，可以大幅度提高代码生产效率。
之前跟前老板，现任得物 APP 的 CTO 云动聊天，我就提了一个问题，是每次写点功能代码就测试，还是尽量全部写完一起提交测试。云动的回复就是进来一次性写完提交测试，保证效率。
- 善用日志工具
部分日志中间件可以做到实时查询全量的符合规则的日志，可以通过检索关键字的方式来分析日志，因此只要请求打印合适的上下文 trace，就可以快速利用中间件工具来查询当前上下文的入参或者异常，进而快速分析到错误。
arthas 是阿里巴巴出品的 JAVA 诊断工具，目前已经开源。arthas 的作用有如下的描述：
arthas 的调试模型支持线上调试，可以打印运行期间的上下文和返回值，可以辅助快速协助线上调试。
- sublime txt 编辑器
程序员必备的是一款同时具备功能强大和简洁的编辑器。sublime 就是 MAC 下当仁不让的最佳选择。功能强大，就是可以有各种插件功能，比如 JSON 插件、批量替换等。简洁就是要求启动快，即开即用不卡顿，毕竟作为效率工具，本身效率不能太差。
四、提升思维方式
- 结构化思考
大家都首推 “金字塔原理” 这本书，这本书我还没看完，但是结构化思考能力是提升自己非常重要的方式，首先给人的感觉就是结构清晰不松散，其实是更提现自己的思考力。诸如对一个方案的需求背景、竞品对标、技术骨架设计、稳定性保障等等都考虑全面，就是一个很好的结构化产出方案的能力。
对目标的定义和树状拆解，可以通过指定 ROADMAP 实现业务目的，就是实现业务目标的第一步。
能够用 ER 图 - 流程图 - 时序图描述出一个系统，就是实现了对系统核心的把握。
- 以终为始
以终为始的同义词是长期主义。即在思考方案的时候，从最终的结果反推该如何开始。以工作台的降级页为例，原来在还未加载到真正的小程序工作台的时候，会显示一个兜底页，而实际上兜底页已经无法使用，而在真正的小程序工作台加载需要一定的耗时，因此就一定会或长或短的出现兜底页。我们之前长期在研究如何缩短工作台加载时间，进而还设计了大量的中间兜底页面。从以终为始的角度来看，降级页是一定不需要的，因此降级页本身就需要优化成一个中间态的 LOADING 页，配合缩短工作台加载时间，才能真正的解决长期问题。
- 第一性原理
程序员之所以被看成是一个吃青春饭的行业，其中一个很大的原因，就是经验经常无法复用，有很多新技术层出不穷，新技术则伴随着”高效”“底层本””时尚”，年纪大的学习力下降，不懂新东西，在公司眼里，这就是新时代的 “老顽固”、” 老不死”。程序员如何保持学习力？除了积极主动接受新东西外，更重要的是提升以不变应万变的能力。毕竟无论你怎么努力，是不可能学完所有东西的。
因此如何把握一种新产品、新技术的本质，就是要抓住其第一性原理。我一直在想着如何学好前端，有个已经出任某创业公司的前端总监 90 后好朋友提醒，其实前端也很简单，你只要抓住 DOM+CSS + 事件，你就了解了前端的本质，不管是新的什么框架都是基于这些基本原理，哪怕现在最流行的前端 PAAS 工具，也都是基于这些本质的技术去实现。一瞬间我仿佛恍然大悟。我确实不需要手把手写出一个漂亮的前端页面，但是我只要掌握了前端的核心基本原理，我就可以表达出包含前端的技术方案骨架。
- 少即是多，慢即是快
那什么是少？如何少？怎么才算少？少到什么程度？如何慢？怎么才算慢？什么情况下慢？
很多人确实一直在追求” 多”、“快”。如同安卓机在硬件上的堆叠、淘宝在商品上的堆叠、钉钉在功能上的堆叠。做多其实很简单，不需要思考，只要 follow 客户的需求、竞对的产品就可以直接实现功能上的增加。而做少才是真正考验大智慧。做少，不是少做或者不做，而是做最核心精华的部分。
这里同样适用于 20/80 原则，大部分用的是 20% 的功能，剩余 80% 的功能很少甚至几乎没人用，因此如何把兵力和精力集中做好这 20% 上，才是真正事半功倍。当然，这里更考验的，是要如何判断真正解决问题的 20% 的产品功能上。
我是一个心急的人，万事都追求极致的 “快”。而实际上因为粗心的” 快”引起了大量的慢，已经出过多次的线上问题，都是我过于求快，而导致止血、回滚，重新修复上线，从当初的求快，变成了实际上的慢。因此对外承诺，并非越快越好，每次达不到业务的预期，实际上再消耗对方对你的信任感。因此，慢一点，稳一点，全面一点，是对自己负责，也是对别人负责。
因此我的新原则就是：
权重越高的事，就越要慢，越要聊透；越核心的系统，发布就越要慢，给足充分的灰度和观察时间
五、小胜即庆
这是最近比较流行的一个词，和” 延迟满足” 不同，“小胜即庆” 的核心思想，就是当有阶段性的结果就庆祝，对自己或者团队一个鼓励。
已经有长时间的科学研究，鼓励对一个人的成长是有明显的提升的。这也是就我们无论何时何地都有三好学生、优秀职工的形象。
人都是要有成就感和反馈机制的，一旦有激励机制，不知不觉中就会心情愉悦，进而提高效率，提升生产力。
回到个人工作来说，也要学会自我激励。可以有多维度和多种方式，比如项目无故障上线，可以奖励自己和团队一瓶香槟；比如写完一篇高质量的文章，可以容忍自己去网吧玩一把游戏；比如拿到一个较好的业务结果，可以买一个自己喜欢的 XBOX 游戏机；