10x程序员是如何思考的？| 2

【1】
初涉编程的程序员可能觉得把功能实现出来的代码，就是好代码。更有追求的程序员会知道，仅仅实现功能是不够的，还需要写出可维护的代码。

计算机科学中只有两大难题：缓存失效和命名。----Phil Karlton
我们的讨论要从名字的意义说起。名字起得是否够好，一个简单的评判标准是，拿着代码给人讲，你需要额外解释多少东西。

任何人都能写出计算机能够理解的代码，只有好程序员才能写出人能够理解的代码。----Martin Fowler
只要你的代码是符合语言规范的，机器一定认。但是，我们写代码的目的是与人沟通，因为我们要在一个团队里与人协同工作。人要负责将业务问题和机器执行连接起来，缺少了业务背景是不可能写出好代码的。写代码的时候，尽可能用业务语言，会让你转换一个思路。
【用业务的语言写代码】

ps：可以看看此分类下的《代码整洁之道》。

【2】
开会是为了解决问题，但真实情况却是开了会又没有解决多少问题，这真是一个奇特的矛盾。凡是效果特别好的会议，基本上都是用来做信息同步的。

改善会议的第一个行动项是减少参与讨论的人数。我们的第二个行动项是，如果你要讨论，找人面对面沟通。这时候，开会的目的不再是讨论，而是信息同步：我准备这么干了，相关各方已经同意了，只会大家一下，结束。

站会(现公司的早会，但是有点像报告会…)
1.我昨天做了什么？
2.我今天打算做什么？
3.我遇到了什么问题，需要请求帮助。
【多面对面沟通，少开会。】

【3】
InfoQ
ThoughtWorks
雷达图是一种很好的将知识分类组织的形式，它可以让你一目了然的看到并了解所有知识点，并根据自己的需要，决定是否深入了解。
看板(效力过的每一家公司都有这东东)，是一种项目管理工具，它将我们正在进行的工作变得可视化。
【多尝试用可视化的方式进行沟通。】

【4】
持续集成的诞生，就是人们尝试缩短集成周期的结果。
想要做好持续集成，就需要顺应持续集成的本质：尽快得到工作反馈。这就引出了持续集成的两个重要目标：1)怎样快速的得到反馈；2)什么样的反馈是有效的。

用好本地构建脚本，保证各种各样的检查都可以在本地环境执行。但是随着时间增加，本地检查的时间会越来越长。有的团队做了分布式测试运行，有的团队将测试分类，在本地执行单元测试和集成测试，而把更复杂的系统测试放到CI(CruiseControl)服务器上运行。
ps：当然，现在持续集成的第一印象就是Jenkins？

做好持续集成遵守的纪律：
1.只有CI服务器处于绿色的状态才能提交代码；
2.CI服务器一旦检查出错，要立即修复。
【做好持续集成的关键在于，快速反馈。】

【5】
如果在开发过程中，同样的问题反复出现，说明你的团队没有做好复盘。把过程还原，进行研讨和分析的方式，就是复盘。为什么复盘这么好用？有一个重要的原因：客体化。用别人的视角看问题，这就是客体化。

回顾会议是一个常见的复盘实践，定期回顾是一个团队自我改善的前提(比如：周例会)。无论哪种做法，分析问题，找到根因是一个重要的环节。“5个为什么”就是一个常用的找到根因的方式。
【定期复盘，找准问题根因，不断改善。】

【6】
自己公司用自己的产品几乎成了全行业的共识，抛开一些大公司用这个说法做广告的因素，不断使用自家的产品，会让你多出一个用户的视角。谁离用户近，谁就有发言权，无论你的角色是什么。
【多走近用户。】

【7】
作为一个程序员，克服技术难题是我们工作的一个重要组成部分，所以，一旦有困难我们会下意识地把自己投入进去。但这真的是最好的做法吗？并不是，不是所有的问题，都是值得解决的技术难题。
写程序有一个重要的原则叫 Fail Fast，这是什么意思呢？就是如果遇到问题，尽早报错。

对我们来说，在程序中尽早暴露问题是很容易接受的。但在工作中暴露自己的问题，却是很大的挑战，因为这里还面临着一个心理问题：会不会让别人觉得自己不行。
【事情往前做，有问题尽早暴露。】

【8】
具有了知识结构后，当要构建应用时，只是需要把工具适配进去，到时再来学习响应的知识，这是非常有针对性的，学习的效率也会得到大幅度提高(万丈高楼平地起，根基一定要扎实)。

将零散的知识结构化，有很多种方式，但输出是非常关键的一环。输出的过程，本质上就是把知识连接起来的过程。(记笔记，写博客，给同事讲述)
【多输出，让知识更有结构。】

【9】
优秀程序员应该有三大美德：懒惰、急躁和傲慢（Laziness, Impatience and hubris）：
1.懒惰，是一种品质，它会使你花很大力气去规避过度的精力消耗，敦促你写出节省体力的程序，别人也能很好地利用，你还会为此写出完善的文档，以免别人来问问题。
2.急躁，是计算机偷懒时，你会感到的一种愤怒。它会促使你写出超越预期的程序，而不只是响应求。
3.傲慢，极度自信，写出（或维护）别人挑不出毛病的程序。

如果工作许多年，知识体系只能靠各种新框架新工具支撑，我们做程序员就只剩下疲于奔命了。不懂软件设计，只专注各种工具，其结果一定是被新技术遗弃，这也是很多人经常抱怨 IT 行业变化快的重要原因。
【请谨慎的将工作自动化。】

【10】
几乎每个重复的工作或是繁琐的工作，都应该自动化。我们不应该把时间和精力浪费在那些机器可以很好地替我们完成的工作上。(比如Jenkins自动打包)
【将你的工作过程自动化。】

【11】
我们今天的关注点在于，将开发过程产生的构建产物部署起来。部署过程要依赖于运维知识，每个程序员都应该学习运维知识，保证我们对软件的运行有更清楚地认识，而且部署工作是非常适合自动化的。

【有系统地学习运维知识。】

【12】
持续交付，是一种让软件随时处于可以部署到生产环境的能力。让软件具备部署到生产环境的能力，这里面有两个关键点：验证发布包和部署。

验证发布包，不仅是功能上的验证，还包括与环境结合在一起的验证。所以，通常会用几个不同的环境验证，每一个环境都是一个单独的阶段，一个阶段不通过，是不能进入下一阶段的，这种按照不同阶段组织构建的方式，称之为构建流水线（Build Pipeline）。

与部署相关的一个重要概念是 DevOps，也就是将开发和运维结合起来。DevOps 包含了很多方面，对程序员最直接的影响是各种工具的发展，这些工具推动着另一个理念的发展：基础设施即代码（Infrastructure as code） 。有赖于这些工具的发展，今天定义交付，就不再是一个发布包，而是一个可以部署的镜像。
【将部署纳入开发的考量。】

【13】
验收测试（Acceptance Testing），是确认应用是否满足设计规范的测试。验收测试是技术交付必经的环节。

编写 BDD 测试用例的最佳实践：用业务的视角描述测试用例。在编写步骤定义时，还要考虑设计自己的业务测试模型。

验收测试的方法不止 BDD 一种，像实例化需求（Specification by Example，SbE）也是一种常见的方法。验收测试框架也不止 BDD 框架一类，像 Concordion 这样的工具甚至可以让你把一个验收用例写成一个完整的参考文档。

如果你有兴趣，可以深入地去了解。无论哪种做法，都是为了缩短业务人员与开发团队之间的距离，让开发变得更加高效。
【将验收测试自动化。】

【14】
面向对象设计原则SOLID：
单一职责原则（Single responsibility principle，SRP）
开放封闭原则（Open–closed principle，OCP）
Liskov 替换原则（Liskov substitution principle，LSP）
接口隔离原则（Interface segregation principle，ISP）
依赖倒置原则（Dependency inversion principle，DIP）

如果说设计模式是“术”，设计原则才是“道”。设计模式并不能帮你建立起知识体系，而设计原则可以。
【把函数写短。】

【15】
分层架构实际是一种设计上的分解，将不同的内容放在不同的地方，降低软件开发和维护的成本。

分层，更关键的是，提供抽象。这种分层抽象在计算机领域无处不在，无论是编程语言，还是网络协议，都体现着分层抽象的价值。有了分层抽象，人们才能更好地在抽象的基础上构建更复杂的东西。

在日常工作中，我们应该把精力重点放在构建自己的领域模型上，因为它才是工作最核心、不易变的东西。
【构建好你的领域模型。】

【16】
一方面，有人会因为对业务量级理解不足，盲目低估其他人系统的复杂度；另一方面，也有人会盲目应用技术，给系统引入不必要的复杂度，让自己陷入泥潭。采用恰当的技术，解决当前的问题，是每个程序员都应该仔细考虑的问题。
【用简单技术解决问题，直到问题变复杂。】

【17】
微服务是很多团队的努力方向，然而，现在市面上对于微服务的介绍多半只停留在技术层面上，很多人看到微服务的好，大多数是结果，到自己团队实施起来却困难重重。想要做好微服务，关键在于服务的划分，而划分服务，最好先学习 DDD。
【学习领域驱动设计。】

【18】

【了解一个项目，从大图景开始。】

【19】
改造遗留系统的建议：
构建测试防护网，保证新老模块功能一致；
分成小块，逐步替换；
构建好领域模型；
寻找行业中关于系统构建的最新理解。
【小步改造遗留系统，不要回到老路上。】

【20】
当你有了“一专”，拓展“多能”，就会拥有更宽广的职业道路。比如，我拥有了深厚的技术功底，通晓怎么做软件：
如果还能够带着其他人一起做好，就成了技术领导者。
如果能够分享技术的理解，就有机会成为培训师。
如果能够在实战中帮助别人解决问题，就可以成为咨询师。

找一个好问题去解决，解决了一个好的问题能够让你的水平快速得到提升。
如果你还什么都不会，那有一份编程的工作就好。
如果你已经能够写好普通的代码，就应该尝试去编写程序库。
如果实现一个具体功能都没问题了，那就去做设计，让程序有更好的组织。
如果你已经能完成一个普通的系统设计，那就应该去设计业务量更大的系统。

学习区模型：

最内层是舒适区（Comfort Zone），置身其中会让人感觉良好，但也会因为没有挑战，成长甚微，你可以把它理解成做你最熟悉的事情。
最外层是恐慌区（Panic Zone），这是压力极大的地方，完全超出了你的能力范围，你在其中只会感到无比的焦虑。
中间的是学习区（Learning Zone），事情有难度，又刚好是你努力一下可以完成的，这才是成长最快的区域。
【在学习区工作和成长。】