卓越工程师应该具备的思维认知

卓越工程师应该具备的思维认知思维导图，整理了勇于去研究你不懂的代码、精通代码调试(Debug)、重视能够节约时间的工具、优化你的迭代速度、系统性思考方式的内容，一起来学习。

卓越工程师应该具备的思维认知

• 勇于去研究你不懂的代码
  • 一般人都不愿意去研究自己不曾接触过的代码，很多人都没有尝试就放弃了。 如果你经常去研究你没有接触过的代码，你就会越来越熟悉不同的代码结构和设计模式。
  • 其实，大家都是在学习的过程中。在一个陌生的领域，没有人从一开始就是大神。
  • 如果你想变得越来越好，无论是写代码，与人沟通或者其它的技能，都是需要投入时间去学习的。
• 精通代码调试（Debug）
  • 很多人在写代码的过程中，经常会有的一个问题就是： 为什么我写出来的代码不能运行？为什么运行的结果不是我想要的？
  • 几乎所有的程序员写代码都不是一遍就能写好的。 但是顶尖的程序员非常快的就明白自己代码的问题可能是什么。 这是一个很重要的能力，但是偏偏学校里不教，面试的时候考官也不经常提及。
  • 如何调试代码呢？核心是一下几个方法
    • 不妨先猜测一下到底发生了什么。
    • 假设你的猜测是对的，想想你的猜测会导致程序有什么结果。
    • 试着观察这些结果有没有异常的地方。如果你没有发现异样，那么说明你的猜测就是对的
    • 如果你发现了异样，那么说明你的猜测是错的，接下来换一个猜测试试。
    • 对于顶尖程序员来说，这个过程在脑海中就是电光火石的一瞬间。只要你解决的问题足够多，你做出来的猜测就会越准确。
    • 至于如何发现异样？你就需要有一套自己的工具或者方法论了。最简单的就是在代码里输出日志来判断。但是这是比较笨的办法，你需要去接触一些高级的工具或者直接带有Debug功能的编辑器。
• 重视能够节约时间的工具
  • 最近打败人类的AlphaGo每天可以进行上百万局的下棋训练，我们人类一万个小时的训练却需要10年之久。
  • 电脑运行几分钟，可能就等于人类工作好几年
  • 曾经在Facebook担任技术总监的Bobby Johnson描述过，高效率的程序员都把时间花在制作工具上。 很多人也认为工具是很重要的，但是他们并没有花时间去制作、整合自己的工具。但是，Jonson团队最出色的员工耗费了他们1/3的时间在工具制作上，这些工具可以用来发布代码，监控系统，以及能让他们花更少的时间去做更多事情。
  • 不要花时间去做机器可以代替你去做的事情
  • 这里其实就是说尽量把重复的工作交给机器来做，或者说自动化。
• 优化你的迭代速度
  • 假设你要花12秒钟去搜索某个函数是在哪里定义的。 再假设你每天做这个动作60次，那么你每天就要花12分钟去搜索函数定义。 如果你用一个好一点的编辑器，每次找到函数定义只要2秒钟，那么你每天就会节约10分钟。 每年你就可以节约40个小时。
  • 如果你能找到3个这样的场景去优化一下，那么你每年可以节约一个月的时间。 想想这一个月你可以做多少有意义的事情。
  • 再假如你在调试一个App的bug的时候，改完一次代码都需要重启一下App，然后点击4、5次才能看到bug有没有改好。 那么你是不是可以先花几分钟设置以下，让App一启动就转到显示Bug的页面呢？ 千万不要小看这些琐碎的细节，改善它们的回报是巨大。
• 系统性思考方式
  • 当你在写代码的时候，你很容易就认为只要你按照需求实现了指定的功能，你的代码就写完了。 但是这其实只是冰山一角。任何没有发布到生产环境的代码都不会产生任何价值。
  • 如果想写出真正有影响力的代码，你需要从整个系统去理解你的工作：
    • 你的代码和其他人写的代码在功能上是什么关系？
    • 你有没有好好测试你的代码？或者其他人是否很容易测试你的代码？
    • 为了部署你的代码，线上生产环境的代码是不是需要改动？
    • 新的代码会不会影响到已经运行的代码？
    • 在新的功能下，你的目标用户的行为是不是你期望的？
    • 你的代码有没有产生商业上的影响？
• 什么是系统架构师？
  • 系统架构师是一个既需要掌控整体，又需要洞悉局部瓶颈，并依据具体的业务场景给出解决方案的团队领导型人物。
  • 一个架构师需要有足够的想像力,能把各种目标需求进行不同维度的扩展，为目标客户提供更为全面的需求清单。
  • 架构师一直是程序员「羡慕且追求」的高度，今天来说说我眼里优秀的架构师该如何定义。
  • 系统架构师应具备哪些能力？
    • 四项关键能力：「平衡取舍、预判未来、抽象思维、容错机制」。
    • 平衡取舍
      • 一个架构本质上总会有优有劣，它不可能是完美的、普适的，也不存在一个架构在 A 场景能用，在 B 场景也最适用的情况，所以就需要我们准确判断，作出取舍。
      • 我们可以根据具体的业务需求来调整架构，也就是以当前的业务需求，选出最匹配的架构。另外，架构师还需要根据现状衡量好需求和资源、效率和安全、时延和吞吐等等之间的关系，做出判断
      • 比如对于在线交易系统，可能更重要的是保证它的低时延，因此就可以牺牲一定的吞吐量，而对于离线系统，吞吐量则更重要一些。
    • 预判未来
      • 架构师需要具备一定的未来的预判能力，因为架构的调整周期通常比较长。 这也是程序员和架构师之间一个很大的区别所在。
      • 程序员负责一个项目，在当前的互联网大背景下，项目的迭代周期非常快，基本以天或周为单位，最多一个月。 如果发现不合适的代码，需要重构，程序员基本也能在几天或几周内就能完成重构。 而架构的调整是相对漫长的过程，可能需要数月，甚至要几年。 因此，在设计架构时就需要架构师具备预判意识，对很多不确定的事情做出预判和选择，诸如未来访问量会增长到什么量级，会不会产生新的业务，这些会对系统产生什么样新的要求等等。
    • 抽象思维
      • 除了懂得取舍和拥有预判意识，架构师在设计架构时还要掌握抽象的方法，不能胡子眉毛一把抓，要做好分层和区隔。 因为架构师面对的是一个很庞大的系统，为了避免过早陷入细节，不要去看各个组件的细节，而是把它们的角色定义下来之后，再分块来思考。而在看每个分块时，其他分块都可以视为一个抽象的概念，另外，也需要考虑复用的问题。
      • 举个例子，我之前在饿了么做在线客服机器人，就运用了分层思想，并且高复用，一个对话机器人可以完成各种各样的业务需求。这其实是一个非常复杂的系统，里面有各种各样的对话机器人的模块，有的特别适合去做检索式的查询，还有的适合做任务导向的、产品推荐导向的对话等等。 我们把对话机器人抽象成一个通用的接口，再将它分为一个个小机器人。这样一来，每个小机器人只需要关注自己的业务模块就行了。然后，我们会在前端再引入一个路由机器人，由路由机器人根据当前对话管理的状态，来判断当前的对话应该交给哪个小机器人去完成。这就是典型的分层的思想。
    • 容错机制
      • 相比程序员，架构师面对的环境要恶劣的多，因为系统更复杂了，出错的概率也增加了，每个节点、每个功能都有可能出错，所以这就需要架构师为错误而设计（Design For Failure），事先提前做好解决方案。
      • 除了应用出错，还有可能产生数据丢失的情况，这个可以通过备份来预防。
      • 另外，如果出现故障，该怎样做到快速恢复呢？我们现在普遍的做法是不修只换，因为如果要修复一个异常状态，可能修复后还会出现连带问题，而如果能通过技术手段，删除已出现的故障，换一个全新的系统，就能够保证它迅速恢复到正常状态。