https://zhuanlan.zhihu.com/p/68012293
导读：本文系腾讯专家工程师刘德超撰文，我们获得授权发布，通过本文，带你了解一位资深工程师背后的思索，希望对你有所启迪。
我们这一行，有人称我们为码农，但是我们这行和农业差距甚远；有人称我们为程序员，但是我们的工作不仅仅是在写程序。我们更愿意自称为：工程师。
我们这一行和传统工业的分工很像，有人做设计，有人打地基，有人做框架，有人做浇筑，有人做美工。我们在虚拟世界中建造高楼大厦，去改变人们的生活，改变这个世界。
面对这个世界日新月异的变化，我们也有困惑。
如果才能保证自己能够持续地创造价值，保持核心竞争力？技术虽然一直在变化，但是做事的态度，确是始终不变的。
在工程师的自我修炼过程中，需要始终保持三种态度：主人翁意识、追求卓越、追根究底。
主人翁意识
主人翁 VS 螺丝钉
我曾经听过一个择业的观点：“选择小公司是为了锻炼能力，选择大公司就是为了来做螺丝钉的”。
在小公司阶段，没有主人翁意识是不行的。因为人数就那么多，而且大家都在探索，没人知道下一步该怎么走。
在大公司阶段呢，一个团队里有Leader，带头人，看起来好像的确是“责任有别人承担，方案有别人规划”，安心的做一个螺丝钉就好。
但现在整体的人力资源环境不允许工程师只做螺丝钉。至少有三件事在驱动着工程师不能仅满足于螺丝钉：一是职称评定，二是绩效，三是人员流动。
在绝大多数场景下，作为Leader都喜欢具有主人翁意识的员工。因为一个人的精力是有限的，不可能去思考、规划所有的事情，需要有人能帮其分忧。
一个成熟的团队，必然有一个成熟的金字塔状结构。金字塔的中间节点的每一位骨干，都需要具备独当一面的能力，可以为团队分忧，能担责任，能主动做事，是项目的主人。
以主人翁态度做事
工程师实现产品，也用产品，也经常吐槽产品。以主人翁的角度来思考，假如一个产品让用户不满意，作为工程师应该怎么提供更好的办法去改进？
工程师需要帮助产品经理去尝试各种各样的想法，能够快速试错；需要能够从数据的角度上给出更加全面的用户行为分析，辅助产品判断。
甚至在一些产品经理没有发觉的地方，主动的提出自己的建议。通常情况下工程师和产品经理的知识结构有很大不同，很有可能会有一个产品的认知盲区需要工程师去补足。
在深度学习大趋势下，不少产品是算法驱动。以主人翁的角度来思考，工程师在深度学习大环境下应该做些什么？将一个算法驱动的产品拆解开，除了深度学习部分，还有分布式存储、分布式计算、流式计算、分布式搜索、数据挖掘、高性能分布式服务、网络安全、用户产品反馈通道等等好多好多方面可以考虑。
工程师不是为深度学习打辅助，而是帮助深度学习更好的在产品里起作用。
追求卓越
大部分的工程师在选择工作的时候，都有一个诉求就是“想要进步”。曾经有些工程师和我抱怨，说他过去在某个团队里因为某某原因，待废了；当时我给的回答是，如果有着“追求卓越”的精神，那么在哪都不会废。因为“追求卓越”是个人态度。
持续学习是自己的事
我们活在信息爆炸的时代，偏偏从事着发展最迅速的行业。几乎每年都有新的技术冒出来，然后又可能快速地过时淘汰。互联网行业，真的是逆水行舟、不进则退。
所以我们要学习。学习的目标，有这几个来源：最新的论文、最新的开源技术、技术社区最新动态。
对于研究员，读论文是家常便饭。但对于工程师，很多人不知道要读论文。实际上每一年工程方向上的论文有非常多。
而且工程方向一些经典的文章不容易过时，比如GFS。每一位工程师都有义务了解自己所在领域的最新情报，而读论文是一个很好的方法。
感谢Github，开源技术有了一个集中营地。Github上的高星评价的项目以及形成的讨论社区，都非常值得一看。即使是经典的思想，经过新的开源重构后，也有可能焕然一新。比如ElasticSearch，其所用技术并没有什么特别，分布式存储、Lucene都是很老的东西。将其重新组合成一个更易用的ElasticSearch，就非常好用，非常耀眼。
国内现在技术社区非常多，个人比较喜欢的是CSDN和知乎。CSDN是大杂烩什么都有，知乎上经常有一些牛人整理好的某个方向成熟、有条理的好文。常混社区，了解现在流行什么，大家都在讨论什么，有助于开拓思路、开拓视野，获得灵感。
建议大家看一看周围4级以上的同事，看看他们是怎么学习的。如果比你优秀的人比你更努力，那你该怎么做？
打80分还是100分
我们如何衡量一个系统的好与坏？大多数情况下，一个系统满足了现有需求，就是一个好系统。但是在实际工作实践中，并不存在一个“需求封闭集”，需求永远在变。
一个优秀的系统，必定是一个可发展的系统，可以应变的系统。如果给“完成现有需求”打80分，那么“考虑未来需求”才可以给系统打上100分。
有些工程团队发声，手上的事情已经做无可做，想要做新的事。这让我非常的惊讶。怎么可能“做无可做”？
现有工作已经做到非常“卓越”了吗？考虑一下功能可扩展性、考虑一下性能可扩展性、考虑一下运维的复杂性、考虑一下可迁移性和可复制性、考虑一下节省计算资源、考虑一下我们的竞争对手是怎么做的？
在系统中去发现优化点，去探索新技术将其引入系统中。永远不满足于80分，去做100分，是追求卓越的态度。
追根究底
知其然也须知其所以然
大家在工作中是否遇到过如下几个问题：
- 因为历史原因，某程序大家都在用，运行很稳定，但是没有人读过源代码。
- 某个服务，缓慢内存泄漏。于是写了脚本，每天低峰期定时重启。
- 线上报警多了，通常情况下报一阵子自己就恢复了。
- 线上模型修改了某个参数，效果突然就变好了。
如果单纯只看结果，可以知其然不知其所以然，不去深究。这些问题就像是不定时炸弹，可能一直不出问题，也可能在未来的某个时间引爆，影响了工作。积累的类似问题多了，炸弹引爆的概率就会越来越大，偶然变成必然。
我建议大家能够以追根究底的态度去面对每一个问题，在追问题、解决问题的过程中，会学到书本上学习不到的内容，技能（通过实践掌握）得以成长。
下面我举几个案例：
案例一：我追过一个线上偶发Coredump问题。因为Coredump后实例会自动重启，而线上同时有几十个实例，所以优先级不高。
在忙完手上高优问题后，我专门找了一个晚上仔细追查。最后查到是主程序依赖了某个库X的a版本，而动态链接库依赖了该库X的b版本，在某个特定处理逻辑下因为不同版本逻辑不一致会导致Coredump。从那以后，我在使用动态链接库的时候就会非常小心，一定会排查一下主程序和动态链接库的编译依赖，尽量保证主程序和动态链接库在同样的环境下联编。
案例二：线上某个服务缓慢内存泄漏，所有使用指针的地方都是shared_ptr，常规代码Review无法发现原因。
于是我采用了“代码二分查找法”，注释掉程序一半的逻辑，mock掉程序所有后端，然后使用压力工具发压力。最后发现是部分缓存数据在异常情况下缓慢增长，且永不过期导致的。
案例三：线上某个服务，在序列化和反序列化过程中，C++ Client的反序列化很稳定，而Golang通过cgo调用C++ lib的时候反序列化很不稳定。
经过排查代码发现C代码实现里的序列化/反序列化过程是将一段内存直接赋值给了一个结构体。因为内存管理过程中，Golang和C++差异，导致了对这块内存的解析存在不稳定偏差。
每次追问题都学习到了新的知识，并且知道在未来遇到类似情况该怎么办。积累下来的经验与技能，将成为了一个工程师的核心竞争力之一。
Bug侦探
追问题有如探案一般，都是根据现有线索去追寻“真相”。计算机程序的世界是完美的逻辑世界，每个问题、现象都能找到原因。
先要有逻辑的信念，然后要有追根究底的态度，下一步需要的就是具体的“探案”方法了。
前面提到了一个“代码二分查找法”，在很多场景下都适用。还有其他有效的方法：
- 善用各类工具：包括但不限于：代码阅读工具，版本管理工具，代码检查工具，压力测试工具，性能分析工具，内存泄漏检测工具。
- 常用原则：看到递归就要想到用循环去重构；看到循环就要考虑是否会死循环；看到数组就要考虑是否越界；看到指针就要考虑是否正确析构；看到多线程就要考虑是否线程安全；看到频繁内存申请就要想到内存池。
- 了解内在原理：函数调用时栈的状态；对象析构的时机；高级语言中的可变对象与不可变对象；Map/Set/HashMap的存储结构；Map Reduce的原理；文件分布式存储的原理；画出完整的模块关系图和数据流图。
- 不放过任何Warning/异常：写出无Warning的代码，包括编译的Warning和各种检查工具的Warning；合理打印Warning日志。
- 善用搜索：能够从国内/外站中搜索问题。
- 记笔记：将每一个问题的追查过程记录下来，定期回顾与分享。
追根究底的产品观
追根究底的态度不仅仅适用于问题追查，产品上也是一样的。数据浮动的背后是用户行为的变化，这个变化可能存在某种诱因。
熟知的诱因有周末效应、月末效应等，但还有很多诱因是不知道的。对数据、对用户行为追根究底，有可能发现某个新的产品突破点。