这篇文章又是关于代码质量的，有些同学可能觉得我比较啰嗦。不过我就是想用这种方式让大家重视起来。其实说来说去就那么几种方法，但是实际执行起来真是难于登天。

低质量的代码真的是一种灾难。当你的代码变得越来越混乱，维护起来就会花费大量的时间。在最坏的情况下，代码将变得不可维护，并且项目会慢慢终止。

为了避免这种情况，你需要注意你的代码质量。尝试在代码质量上花费一些时间，长久来看，这将对你有很大的好处。

无论你是管理者，测试人员或者是开发者都应该去自觉维护代码质量，因为在整个开发流程中，大家的目标都是交付可用的、高质量的代码。

要想提高代码质量，需要做到以下六件事，其中一些是一个人可以完成的，而有些则必须要团队配合。

1. 四眼原则

四眼原则是易于理解和执行的。它的意思是必须要有至少两个人（包括作者）检查过代码，目前最流行的方法是Pull request。

Pull request是让你告诉别人你已经在GitHub上向分支push了一些代码改动。在开启Pull request之后，你就可以和协作者讨论潜在的问题，并且可以在你的代码被merge之前继续对它进行修改。

——Github.com

在代码审查期间，有几件事需要考虑。其中之一是检查代码是否违反了约定的代码规则。这一过程可以通过在管道中使用linter来实现自动化，但有时也需要手动执行。

另外一个需要检查的是代码的可维护性和错误处理。这件事还没办法自动化。最后，需要检查的是代码的完整性。这一修改是否完成了需要完成的全部功能？

2. 持续集成

“开发环境是好的。”这是某些开发人员常说的，还有就是：“在我电脑上没问题”。

如果希望避免这种问题的争论。持续集成可以给你提供很大的帮助。

持续集成是一种软件开发实践，团队的开发人员经常集成他们的工作，通常每人至少每天集成一次——这使得每天需要集成很多次。每次集成都应该由自动构建（包括测试）尽快确认是否存在集成错误。

—— Martin Fowler

持续集成的意义在于，它可以快速的向开发者提供结果反馈。

持续集成的两个基本作用是：

1. 保持快速构建，没什么比一次耗时一小时的构建更让人沮丧的了。

2. 快速修复损坏的构建。持续集成会让你始终在一个稳定的版本的基础上进行开发。

持续集成通过快速向开发者提供反馈来帮助提高代码质量。如果测试不通过，那么构建就会失败，此时开发者就会注意到。此外，最好在构建脚本中添加linter来检查是否符合编码规范。毫无疑问，这也是用于提高代码质量的。

3. 编码规范

拥有一系列的代码规约是非常重要的。但是在你开始制定代码规约之前，团队的每个人都应该参与。因为这期间可能存在大量的关于最优约定的讨论。

编码规范中应该包括怎样声明和命名一个变量等等。规则的数量是没有限制的，并且以后可以继续调整，前提是这些规则对你和你的团队有帮助。

当编码规范制定好以后，请务必遵守。就像我前面提到的，最好的检查办法是在管道中增加linter，这样就不需要人工干预了。如果不这样做，也可以选择在本地安装linter。但要保证在每次提交之前规范使用linter。这样你的团队的代码风格将非常统一，有利于提升代码的可读性和可维护性。

高质量的代码可以加快软件开发的速度，因为它可以被复用，并且开发人员不必花费大量时间修改bug和完善代码。同时新人加入项目也会更快适应。

4. 测试，测试，测试

代码质量越高，bug就越少。我们通常通过测试过滤出严重的bug，确保代码按照预期执行。

制定清晰的测试策略对于提高代码质量至关重要。至少要保证你的代码可以通过单元测试。如果你以其他方式进行测试就更好了，例如集成测试或回归测试。

根据测试金字塔，项目中数量最多的测试应该是单元测试，因为它们既简单又快速。有很多工具可以帮助你创建单元测试并生成代码覆盖率报告。

跑单元测试和生成代码覆盖率报告可以通过持续集成自动进行。当代码覆盖率达不到要求时，持续集成也会构建失败。

5. 分析bug

代码中有bug是必然的事情，如何处理这些bug才是关键。如果你想要提升自己，学会从错误中学习至关重要。这也是为什么你要分析bug。

发现bug后，先分析bug的影响。是一个低优先级的还是高优先级的？如果是高优先级的，就需要尽快解决。

分析bug时，你需要问自己一些问题。是什么导致了错误？为什么没有测出来？其他地方也有可能发生吗？以及我们应该怎样避免类似的bug产生？

当然，我们也要学会使用工具追踪bug。目前市面上有许多可用的bug追踪工具，你可以根据需要选择适合自己的工具。

6. 开始量化

在开始量化时，可以用几个指标来衡量代码的质量。

缺陷指标

缺陷的数量和缺陷的严重程度是衡量代码质量的重要指标。如果你想追踪bug，可以使用bug燃尽图。bug燃尽图和软件敏捷开发中的正常燃尽图一样。唯一不同的是bug燃尽图包含未修复的bug，而不是事故点。

复杂度指标

复杂度通常由圈复杂度衡量，它是程序的源代码线性独立路径数量的一个衡量。

圈复杂度数和缺陷频率之间存在一定的相关性：

许多研究调查了函数或方法中圈复杂度数和缺陷频率数之间的相关性。有些研究发现了圈复杂度和缺陷数的正相关性：函数和方法越复杂，缺陷也就会越多。然而，圈复杂度和程序大小之间的相关性已被多次证明。

从理论上来讲，降低代码的复杂度会使缺陷更少。

1、拥有坚实的基础并理解面向对象原则

Java开发人员必须深刻理解面向对象编程。如果没有面向对象编程的坚实基础，就无法感受到像Java这样的面向对象编程语言的美感。 如果你不太了解现象对象编程是什么，即使你使用的是面向对象编程语言，你仍可能会面向过程进行编码。仅研究面向对象原则并没有太多的帮助， 我们应该知道如何使用面向对象的方式应用这些原则来设计解决方案。 因此我们需要拥有丰富的对象建模，继承，多态，设计模式等方面的知识。

2、精通核心的API

如果你不了解语言结构和核心API，那么无论你在在理论知识方面有多强大也是枉然。对于Java语言，开发者对核心的API应具有非常丰富的实践经验，如java.lang.*包，I/O，异常，集合，泛型，线程，JDBC等。当涉及到构建Web应用程序时，无论你使用哪个框架，了解servlet和JSP的概念是必须也是至关重要的。

3、持续地编码

仅仅从理论上来看事情比较简单。我们可以在理论上非常容易地解决问题。但是当我们开始实现这些内容时我们才认识到问题的深度。在这个过程中你将了解到语言限制，或在编码时设计最佳实践。 所以需要你持续编码。

4、订阅技术论坛

在技术上我们并不孤单，在论坛上会有很多人在使用着与我们一样的技术。虽然在框架上进行简单的概念验证对你来说并没有什么挑战，但当你开始在实际项目中使用它时你将面临各种奇怪的问题，并且这些问题在其官方文档中根本找不到任何解决方案。在你开始使用新的技术时，第一件事就是订阅相关的技术论坛。无论你遇到什么问题，世界上其他人都可能已经遇到过并找到了解决方案。如果你能回答其他论坛用户提出的问题那就更好了。

5、关注博客并回复

就如我上面说的你并不孤单，全世界有成千上万的热心技术狂热者在博客上发表他们对技术的见解。你还可以从其他博客和开发人员那里获得有关相同技术有价值的观点。有些人可能会发现特定的框架特征非常有用，而其他人可能会发现这些特征是愚蠢而毫无意义的，给出了他自己为什么会这样认为的原因。因此你可以看到使用这些工具的其他开发人员的好与坏。通过查看其他博客获得价值的另一种方法是回复你的观点或是提出自己的问题。

6、阅读优秀开源项目代码

一个合格的开发者学习如何去使用框架，但如果你想成为一个优秀的开发者则还需要研究各种流行的优秀的框架源码。从这些框架源码中你可以知道框架内部的运行机制及其最佳实践。同时这将对使用框架有很大的帮助。

7、了解信息技术趋势

目前开源软件项目越来越多，开源趋势愈演愈烈。当你对使用某个框架有个好想法时，它有可能已经变得过时-因为一些新框架包含的功能是该框架提供的功能的超集。另外你在使用的框架中需要解决的问题或许在新的框架中仅使用一行配置即可解决。所以密切关注技术图谱中的技术哪些将会崛起，哪些将会过时。

8、手头保留通用代码片段及工具

随着时间的推移，你可能需要反复写入/复制粘贴相同的代码/配置。可以保留像log4.properties，JDBC配置等配置文件，或者像StringUtils，ReflectionUtils，DBUtils等实工具将更有帮助。我知道这可能本身不会让你成为优秀的开发者。但是想象一下，一些合作开发人员要求你帮助从集合对象中获取属性值列表，然后你只需使用ReflectionUtil在几分钟内提供解决方案：这将使你更加优秀。

9、了解不同的软件开发方法

熟悉Agile、SCRUM、XP、Waterfall等各种开发方法。选择何种开发方法取决于客户，一些客户喜欢敏捷，另一些客户对瀑布模型更中意。所以开发者对各种开发方法有所了解将是一个加分项。

10、记录自己对于技术的理解和思考

在日常工作中，你可以学习新的更好的做事方式，以及最佳实践，架构理念等。记录这些想法，发布博客，在社区中分享。想象一下你解决了一个在做简单的POC时发生的奇怪的问题并在博客上记录下这个问题。也许世界上其他的开发人员在生产部署的应用程序上也遇到了同样的问题，这时候你的这个解决方案对他们将是多有价值。所以用博客记录自己的思考，这将在以后的某天可能会对他人或自己有所帮助！

原文链接：https://dzone.com/articles/10-things-become-outstanding

作       者：Siva Prasad Reddy Katamreddy

译       者：klein

程序员的标准与要求

初级程序员

仅能完成简单模块和项目的开发工作，难以胜任复杂模块的开发。通常是入行不久， 1 年及以下工作经验的同学。

能力要求

1. 熟悉前端基础知识如 HTML、JS、CSS 。

2. 能够使用一门 MVVM 框架进行简单的业务开发。

3. 遇到复杂的组件和模块，会找现有的轮子使用。

4. 会使用百度、google 等检索工具搜索问题。

中级程序员（阿里 p5）

在必要的辅导或标准流程支持下，能独立负责一个子模块或者一个项目的具体任务，对及时性和准确性负责。通常是 2-3 年工作经验的同学。

能力要求

1. 除了前端基础知识外，熟悉计算机、网络等专业基础知识。

2. 熟练掌握工作中使用的技术栈开发业务。（除了 MVVM 框架外，还能了解 webpack 的配置）。

3. 能了解一个需求从开发-上线整个生命周期，并对各个环节负责。

4. 具备基本的逻辑分析、问题分解、归纳总结等能力。

5. 了解基本的数据结构和算法，写代码较熟练。

6. 知道从靠谱的渠道去查找问题，在找不到合适轮子的时候，会造一些简单的轮子辅助业务开发。

高级程序员（阿里 p6）

具有独挡一面的能力，能够高质量完成工作，能把握一个系统/团队的整体实现，在推行过程中能提炼新的方法或方案，或对现有方案提出改进建议并被证明有效。通常是 3 年+ 工作经验的同学。

能力要求

1. 具有独挡一面的能力，能高质量的完成模块级的工作。

2. 熟练掌握工作中使用的技术栈，并能了解它们的实现原理。

3. 能够在一个需求从开发-上线整个生命周期中找到痛点，并能使用技术的手段解决，提升效率。

4. 能在模块维度对问题或需求做出分析和拆解，并做出相对合理的实现方案。

5. 熟练掌握基础的数据结构和算法，代码符合规范，逻辑清晰。

6. 有较好的技术选型能力。

程序员的进化之路

初级 -> 中级

通常在初级这个阶段，是进步空间最大的阶段，这个阶段是不存在天花板的。

编码

编码是初级阶段最需要经常做的事情，古话说孰能生巧，写代码也是同样的道理。

• 写什么的样代码

  在公司要多做业务，尝试不同的业务，目标是让自己先成为一个熟练工。 下班后也可以折腾点小项目做，可以选择自己感兴趣的内容，尝试自己实现一遍。

• 如何写代码

  学会模仿，参考大牛的编码风格，照葫芦画瓢。 如果公司有代码规范，跟随着公司的代码规范走，如果没有，参考业界规范，并用工具（如 eslint）约束自己。 遇到一些不会写的，哪怕找到可以参考的代码，跟着抄一遍也行。

工作

大部分时间都在工作，那么如何合理的利用好 8 小时工作时间呢。

• 熟悉业务 不要仅仅埋头写代码，也需要对业务了解，认真参与需求评审环节，明确自己所做的任务。

• 熟悉工作流程

  要熟悉从需求-开发-联调-测试-上线的每个工作环节，认真按照规范来执行，对上线要有敬畏心。

• 提升效率

  工作的时候，尽量不要被打断，可以安排一个免打扰时段，比如下午的 2点-4点，只编码而不去处理其它事情。减少在群里 灌水和斗图的时间。

• 加班

  可以接受合理的加班（比如为了赶某一个需求加班一阵子），不接受没有任何补偿和调休的日常加班（996），因为日常  加班会压缩你学习和生活的时间。

学习

初级阶段是需要通过大量的学习来提升自己的能力。

• 明确自己的学习目标 学习是为了提升能力，能让你胜任更复杂和有挑战的工作。

• 应该学习什么内容 前端基础，JS、CSS、HTML 反复学习。 工作中用到的一门前端 MVVM 框架。 了解一些广度知识，比如 HTTP、正则表达式、Web安全、性能优化、设计模式，数据结构和算法。

• 找到合适的学习方式

  看书+编码：购买经典的书籍阅读，并作为平时写码的参考工具，看书和编码是一个反复的过程，基本就是看书->编码->看书->编码循环个 3-4 次，这个过程就是在不断修炼内功。

  视频：慕课网的入门实战视频，根据自己的需求购买，要充分学习自己购买的每一个视频，认真的跟着老师学习一遍写一遍，遇到不懂的要积极提问，学习在于深入而不在于多。视频比书籍的好处在于更贴合实践，也更贴合公司业务，另外，课程的升级和更新也更加灵活。

  官网文档：学习每一个新的技术栈，入门最好的方式是通过它的文档学习，可以系统的过一遍文档，手敲它每一个示例。

  社区：慕课网手记、掘金、CSDN、InfoQ 等中文社区，利用碎片化时间看一些高质量文章学习。

  GitHub：学会 GitHub 的使用，知道 clone、fork、pull、push 等基本操作。

• 花更多的学习时间 如果想比别人成长的快，就得花比别人更多的时间用来学习（这也是为什么不鼓励日常加班），尤其是初级这个阶段，成长曲线是非常快的。

• 知识沉淀 俗话说好记性不如烂笔头，可以养成写博客的习惯，把学习的内容用文字的形式记录下来，整理成文，并按学习的技术方向做归类。

提问

在初级阶段，免不了经常遇到问题，会提问也是一门技术活，好的提问姿势能让你事半功倍。

• 不好的提问方式

  “这个报错是什么意思？”；缺乏思考，没有体现自己关于问题的思考过程。

  “为什么我的代码和你的一模一样，就是运行不了？”；缺乏上下文，应告知代码是编译不过还是运行不起来、错误提示信息、相关代码、可能出错的代码分析。没有足够的上下文，神仙都不知道如何解决相关的问题。

  “为什么 xxx 能（不能）yyy”；问的问题本身就是一个错误的结论，通常是只是看到了现象，而没有分析问题的本质。

• 好的提问方式

  首先你在提问之前，自己应该经过充分的思考，并学会把问题拆解，在拆解的过程中就会把问题的复杂度降低。 其次要善用搜索引擎，把关键字提取出来去搜索引擎上去搜索，先尝试自己去解决问题。

  如果仍然不能解决，可以将问题的相关上下文、截图及必要标识及自己的思考过程、查找到的相关资料，以及自己的分析发送给想要帮助你的人，并能提供最小化复现的问题。

  最后，请将你的问题及解决方案重新整理，并告知帮助你的人问题已经解决，重新整理解决问题的过程会帮助你理清思路、从而对问题有着更深的理解。

中级 -> 高级

到了中级阶段，基本上意味着你可以在大公司缺人的时候进入大公司工作了，如果想成为大公司不可拒绝的人才， 那你还需要朝着高级阶段努力。

编码

没错，到了中级阶段，你想要提升最重要的途径还是要编码。

• 写什么的样代码

  和初级不同，除了做业务之外，你也参与开发做一些偏技术类型的项目，比如参与组内组件库的开发，一些通用 JSSDK 的开发，这些会对你的技术要求会更高。

  有机会去参与平时使用到的一些开源技术栈的共建，比如想实现每个 feature 但现有开源库不满足，实现难度不大的情况下可以去提一个 pull request。

• 如何写代码

  学会模仿，除了参考大牛的编码风格，还要琢磨他们的编码思路，多思考他们为什么这么做。

  学会组件化、模块化的开发方式，学会复用和封装，减少 CV 的操作。

  对自己的代码质量负责，可以经常组织 code review。

工作

想要进阶，需要在工作方面有些产出。

• 业务思考

  要明白业务和公司的目标，参与到需求的早期阶段中，同时也要多思考业务，想着有没有通过技术手段来提升业务价值，比如移动端的白屏时间减少，可以带来很好的用户体验，提升用户的留存率。

• 技术思考

  思考业务开发中的一些痛点，如何用技术手段去优化业务的开发流程，提升开发效率，比如为业务量身定制一款脚手架工具。

• 优化工作流程

  不仅要熟悉从需求-开发-联调-测试-上线的每个工作环节，还要多思考每个环节有没有可以提升的点，特别是上线过程，比如能不能做到自动化，能不能做到小流量上线，能不能及时回滚代码。

• 技术分享

  把工作中遇到的一些问题的解决方案、学习的一些新技术，产出的一些技术项目总结下来，作为组内技术分享和输出，这样一是可以总结沉淀你的技术，二是可以让大家能知道你做的东西，并活跃组内的技术氛围，三是锻炼自己的表述能力，这个能力在大公司的晋升述职中非常重要。

学习

中级阶段仍然需要通过大量的学习来提升自己的能力。

• 明确自己的学习目标

  学习是为了提升自己的硬实力，不仅仅能够提升工作效率，还能让自己更好的服务于业务，升职加薪。

• 应该学习什么内容

  研究工作中所用到的工具链，不仅仅是运行时的 MVVM 框架，还可以是编译时的 webpack，必要的时候去研究其中的源码实现。

  深入学习一些广度知识，比如 HTTP、正则表达式、Web安全、性能优化、设计模式，数据结构和算法，并把它们应用到你的工作中。

• 找到合适的学习方式

  看书：找到所学习方向的经典书籍阅读，适当做一些学习笔记。

  视频：如慕课网的进阶实战视频，根据自己的需求购买。

  官网文档：可以尝试去看一下英文文档。

  社区：StackOverflow、HackerNews，慕课网手记、掘金等，除了利用碎片化时间看一些高质量文章学习，也可以往上面发布一些优质文章。

  GitHub：关注 trending，参与开源社区的共建，并尝试自己造一些轮子。

• 学习时间与深度

  在中级阶段，你仍然需要花很多时间去学习，这个时候要注重自己学习的深度了。

• 知识沉淀

  俗话说好记性不如烂笔头，可以养成写博客的习惯，把工作中深入学习到的一些非敏感知识记录下来并发布，而不仅仅去发布一些基础知识的学习了。

• 技术视野

  除了自己工作中的使用的技术栈之外，也要了解同类其它优秀的开源技术栈，从多个维度（feature 完整性、文档、上手难度、维护力度、生态等）去做对比。

  要保持对新技术的敏感的关注，并时刻思考这些技术能否为自己的业务带来价值，在需要的时候做合理的技术选型。

总结

所谓技术能力其实就是解决问题的能力和学习能力，所以无论你在哪个阶段，甚至是更高的阶段，不断提升这两个能力都是你应该一直要做的事情。

在互联网公司中，研发团队可谓是第一生产力，他们看待问题非常的理性，除了薪资外，还讲究一种叫技术氛围的东西。那什么是技术氛围？听起来挺虚的是不是？我个人认为，就是技术在整个团队乃至公司中，能被足够的重视。团队中的大部分人，能热爱技术，喜欢折腾，乐于分享。在这样的环境下，一方面能激发团队不断的推陈出新，另一方面也能使团队成员有持续的个人成长。

Leader是否重视技术这件事，非常大程度上直接决定了团队的技术氛围走向。如果Leader只是把成员当成螺丝钉，以春蝉到死丝方尽的理念用他们，那结果就很明显了——大家每天都很累，感觉身体被掏空，没有精力去学习新技术，去分享技术。久而久之，觉得没有成长，就离开了。显然这种短期让团队在单位人天内创造价值最大的方式，无异于杀鸡取卵。他们是一群充满活力的年轻人，需要被肯定价值，让他们感觉到希望，未来可期。

那作为一个Leader，怎么样才能打造一支具有好的技术氛围的团队呢？这里分享下我个人的一些经验，主要分为以下五点。

参与感

在项目的整个流程中，让研发有更多的话语权，使得他们能感觉到自己是项目的主人。比如，在制定研发周期的时候，leader不要直接把时间估好，然后跟团队说：“这个功能我认为只要2天就行了，从明天开始开发吧”。研发听到这种被安排的口气时，虽然表面上去做了，但内心是不爽的。因为，他觉得你不尊重他。更好的做法是，先让研发来排期，把一部分周期主导权交到研发来把握，只要跟你估计的时间没有太大的出入，那就没问题。如果相差较多，可以进行沟通。这个过程，除了研发能收获尊重，还能提高研发的周期把握水平，一举两得。除此之外，在一些产品的决策上，可以收集一下研发的意见，让研发参与决策。这些方式都可以很好的激发研发人员的积极性和主动性，氛围感自然就上来了。

技术规划

Leader要结合产品规划以及相应技术栈未来的趋势，制定出一些更有挑战性和前瞻性的任务，根据每个研发不同的情况来分配。这样既能为产品未来打下坚实的技术基础，还能将研发解救于枯燥、重复的业务代码开发中，使其有机会能接触到更高难度的任务，提示自己的技术能力。这样一中和，能有效的缓解职业疲劳，开心撸码。

更高的技术要求

那如果由于产品方向不明确、产品发展处于白热化阶段或者不符合预期，导致比较难做出技术规划怎么办？还别说，这种情况其实非常普遍。在这种情况下，即使做了技术规划并执行，对项目的收益也不见得很大，反而有可能会产生负收益。毕竟产品未来方向不明朗，这个时候与其投入人力去做未来的技术铺垫，还不如投入资源多做些功能去试错。这个时候，你可以对当前产品的技术提出更高的要求。比如，可以梳理目前项目中存在的技术问题，排列优先级，分配给研发去解决。在某些问题的解决过程中，是能帮助研发提高自己的技术能力的，解决完成后形成文档，说不定还能借此跟大家分享一下解决思路和方法。这对项目来说也非常有益的。

提供学习的环境

在这点上，主要从三个方面来讲

在忙碌的产品周期迭代之余，要去引导和驱动团队不要只满足于手头上的工作，得紧跟前沿技术、最佳实践。把学习到的知识运用到项目中，组织进行分享。开发同学一转以往两耳不闻窗外事，一心只撸圣贤码的角色，在公众面前进行表达，收获大家赞许的目光。

推动互相审核代码。代码审核的这个过程，其实是非常好的互相学习的机会。审核的人能学习到被审核人的代码实现、代码设计。被审核的人也能从别人审核出来的问题中，发现自己的不足并改进。这个过程中，互相交流技术实现的氛围就慢慢形成了。

给予机会去参加外面的技术论坛、分享会，感受整个行业的技术氛围。

鼓励创新

首先，要提供一种创新的氛围。在大家没有主动创新意识的时候，可以通过激励等手段，去倡导和鼓励创新。比如，设计一种机制，在每个月组织一个创新提案会，团队成员可以将自己的技术想法提出来，大家一起评审这个想法。如果该想法通过，则在排期上给予时间去实现，并在落地后给予一定的激励。即使最后实现的结果不如人意，也要给予一定的宽容，这也是在鼓励团队试错，在错误中成长。通过这种机制的保障，团队成员的创新意识会被慢慢培养起来。

其次，在技术选型方面，可以适当的激进些，鼓励将一些新的技术运用到项目中。我见过很多Leader比较保守，对新的技术新的非常排斥，导致项目中使用的技术万年不变。当然，新技术的引入也意味着带来风险，但通过一个完善的评审机制是可以规避大部分风险的。

结语

营造技术氛围是个长期的过程，不能一蹴而就，重在对这件事情的坚持。很多时候Leader们推行一个机制来提高技术氛围，认为推行后团队的技术氛围就能自动的且持续的提高，推行后不久就没有再跟进，结果是注定失败的。所以，如果想让团队拥有良好的技术氛围，Leader们必须要有持续的热情去刻意营造，这样团队的技术氛围才会一天比一天好。