前言
前几篇文章我们聊了，作为一个“职业新人”最重要的是“快速变得专业”。其中提到了四个需要注意的点，并且为你引入了“能力图谱”的概念。
越早拥有并持续维护你的能力图谱，你就能比同届的同学成长得更快。
今日内容
今天开始，我们进入一个新的板块，那就是“成为工程师”板块。其实更贴切的说应该是“成为优秀工程师”。
很多人认为，工程师的职责就是“完成研发工作”。说白了，就是根据业务需求写代码就行了。但其实，在大厂，对一个工程师的要求远不止此。
在大厂，一个优秀的研发工程师是应该为一个系统或者一个小型业务板块负责，也就是我们常提的系统owner或者业务技术接口人（对标阿里P6）。那工程师就不只需要具备优秀的研发能力，还需要具备一定的风险管控能力，以此来保障系统运行时的安稳。简而言之，优秀工程师可以独当一面，让人放心。在具体展开工程师内容之前，我们先对优秀工程师有一个全貌性的了解。
看完这个，你也能了解很多大厂对于工程师的要求。也许你从中能够看到自己面试失败的原因，或者是为你之后的面试做一些准备。
****
01
扎实的基础能力
首当其冲的自然就是扎实的基本功。主要包括两块：
【基础技术能力】 包括操作系统、计算机网络、数据结构和算法及计算机安全。 【应用类技术】 语言特性、基本用法、运行时原理、典型框架、设计模式。此外，一个优秀的工程师还需要具备“严谨不苟且”、“持续学习”、“开放心态”等软性素质。这些内容我们在之前的文章中也都有提及，不再赘述。
02
高质量研发
完成普通的业务需求可以说是对工程师的基本要求，但这还不够。
工程师除了要完成功能，更要追求“完成得好”。简单地说，就是“研发质量要高”。主要表现在：扩展性要好、健壮性要高、良好的编码风格。
01
扩展性好
研发质量首先表现在：你的设计具不具备良好的扩展性。
在英文单词里，Scalability和Expandability都是扩展性的意思，但是意义不同。
【Scalability】 指服务层面的横向扩展，也就是通过增加服务器或者数据库等资源达到更高的服务能力。
【Expandability】 指面对业务需求变化的时候，软件变化的难易程度。
所以，良好的扩展性就是你的设计是否能同时具有Scalability和Expandability。这样，你就可以从容应对无论是功能还是流量上的持续上涨。
02
健壮性高
其次，研发质量还体现在系统的健壮性上，健壮性又主要是指对异常的处理。
对于异常的处理起码包括：
【1】系统异常和业务异常的区分。
【2】对异常捕获后的处理（中断或者降级）。
【3】日志的打印（摘要还是详细？服务于监控和问题排查）。
【4】异常对调用方的返回（错误码、错误信息及对上游进一步操作的指引）
03
良好的编码风格
接着，研发质量还体现在你的代码可读性。也就是你的编码风格。
一个系统想要持续的发展，首先就是代码得容易让人理解。其中包括：
【1】是不是做到了足够且友好的注释（虽然有论调说好的代码不需要注释，但这是建立在代码结构设计足够清晰的基础上，并且不涉及专业领域晦涩概念的时候）？
【2】属性及方法的命名是否直观且无二义性？
【3】一个方法体里是不是有大段大段的代码？内聚性如何？
【4】是不是有良好的换行习惯？
【5】是不是尽力避免代码冗余？
【6】是否尽量遵循了SOLID原则？
【7】......
说到代码规范，真的非常多。在这里我非常推荐《代码整洁之道》这本书，我个人认为，这本书应该是研发工程师的必读书籍。
千万不要小看编码风格，编码一时爽，后人火葬场。看到那种几百行没注释还没分段的代码，火就蹭蹭蹭往上冒。同样，这也是表现你专业度很重要的地方。
遗憾的是，这些道理大家讲的时候都懂，但又有多少同学能够真的在实践中严格落实呢？
03
良好的风险控制能力
所谓的风险管控能力就是持续保障服务的可用性。说白了就是让一个系统能够在线上持续工作的能力。
难道系统上线以后，不是服务器持续供着电就能够一直工作吗？
真正处理过线上问题的同学看到这个问题，低头笑了笑。
一个系统在线上运行时会碰到各种各样的问题。包括代码发布引入bug、硬件或网络问题、容量问题、代码设计不合理造成的慢性问题等等。
一方面我们要能发现并fix这些问题，另一方面，我们要能及时消除线上的影响。在我们后续的工程师篇章中，会有详细的稳定性内容。这里我们先做一些概述。
01
风险控制设计
对于风险，最早的控制是在功能设计及研发阶段，也就是我们常说的研发态的时候。
例如，我们可以设计通过服务中心下发一个比例值，来实现灰度放量的功能。所谓灰度放量，也就是逐步地将新功能放开给用户使用。
例如，对于不重要的下游异常做降级设计。从而避免被不重要的功能影响主功能。
例如，我们可以使用线程池来控制并发，以保护我们的服务以及数据库的安全。
例如，对于一些关键错误记录日志并上传日志中心，帮助监控报警。
等等......
这是一个非常大的命题，涉及的内容也比较广，我们也会在后面展开。
02
变更风险管控
【变更风险】指由于系统变更导致服务不可用或性能下降的风险。这里的系统升级包括代码变更发布、配置变更、数据库表结构变更、数据迁移、机器更换等。
所以，对于变更，我们往往会引入很多的规范、工具来帮助降低风险。例如要求测试用例覆盖、引流验证、灰度变更、灰度放量等等。我们后面都会逐一展开。
变更是最容易导致线上问题的。所以每到重要节日，很多公司都要实行封网（不允许变更）。
03
快速线上应急
残酷的现实告诉我们，当我们做了一切努力以后，我们仍然无法避免出现线上问题。
所以，线上应急是一项非常关键能力。这里又引出三个问题：
【1】你有没有及时发现线上问题的能力？展开说，你有没有关键的监控？有没有清晰报警？你的报警会不会太多被淹没？【2】你有没有快速应对线上问题的方法？展开说，你有没有日志能清晰定位原因？你有没有针对变更或者经常出现的问题整理过应急文档？【3】你有没有快速应对线上问题的工具？展开说，是否有定位问题（诊断）的工具？能否快速回滚变更？是否有快速熔断请求的能力？是否有快速标记机器下线的能力？
线上问题的故障等级往往按分钟计算，上面三点有一点做得不够，后果就可能非常严重。
到这里，我们就把一个优秀工程师大致需要掌握的内容说完了。上面讲的这些内容看似简单，但实践不易，我们会在整个系列文章中逐步展开。
今日总结
今天开始，我们进入了“成为工程师”篇章。我们讨论了作为优秀工程师需要具备的一些能力，包括：扎实的基础能力、高质量研发、良好的风险控制能力。
下一篇文章开始，我们会一点一滴走进细节，帮助你成为一个优秀的工程师。优秀工程师是走向架构师的必经之路。你所期待的各种技术细节也将逐一登场。加油吧，未来的架构师们！
