国内外的企业 IM 的本质差别

国内企业级在线交流工具主要有：企业微信、钉钉、飞书，国外的则是：Slack、Discord这两大IM工具，你会发现，他们有很多不一样的东西，其中有两个最大的不同，一个是企业管理，一个是企业文化。

企业管理

Slack/Discrod 主要是通过建 Channel ，而国内的IM则主要是拉群。你可能会说，这不是一样的吗？其实是不一样的，很明显，Channel 的属性是相对持久的，而群的属性则是临时的，前者是可以是部门，可以是团队，可以是项目，可以是产品，可以是某种长期存在的职能（如：技术分享），而拉群则是相对来说临时起意的，有时候，同样的人群能被重复地拉出好几次，因为之前临时起意的事做完了，所以群就被人所遗忘了，后面再有事就再来。很明显，Channel 这种方式明显是有管理的属性的，而拉群则是没有管理的。

所以，在国内这种作坊式，野蛮粗放式的管理风格下，他们需要的就是想起一出是一出的 IM 工具，所以，拉群就是他们的工作习惯，因为没有科学的管理，所以没有章法，所以，他们不需要把工作内的信息结构化的工具。而国外则不然，国外的管理是精细化的，国外的公司还在重度使用 Email 的通讯方式，而 Email 是天生会给一个主题时行归类，而且 Email 天生不是碎片信息，所以，国外的 IM 需要跟 Email 竞争，因为像 Email 那样给邮件分类，把信息聚合在一个主题下的方式就能在 IM 上找到相关的影子。Channel 就是一个信息分类，相当于邮件分类，Slack 的 回复区和 Discord 的子区就像是把同一个主题信息时行聚合的功能。这明显是懂管理的人做的，而国内的拉群一看就是不懂管理的人干的，或者说是就是满足这些不懂管理的人的需求的。

企业文化

团队协作和团队工作最大的基石是信任，如果有了信任，没有工具都会很爽，如果没有信任，什么工具都没用。信任是一种企业文化，这种文化不仅包括同级间的，还包括上下级间的。但是，因为国内的管理跟不上，所以，就导致了各种不信任的文化，而需要在这里不信任的文化中进行协同工作，国内的 IM 软件就会开发出如下在国外的 IM 中完全没有的功能：

• 监控员工。获取员工的工作时间以及工作位置。
• 有详细的已读标注。这样会给对方要回复的压力。
•  发出的信息不能修改，不能删除，非常有限地可撤回。

而国外的 IM 则是，发出的信息可以修改/删除，没有已读标准，也不会监控员工。这种时候，我总是会对工作在这种不信任文化中人感到可怜……如果大家需要靠逼迫的方式把对方拉来跟我一起协作，我们还工作个什么劲啊。

小结

所以，我们可以看到，畸形的企业管理和企业文化下，就会导致畸形的协同工具。最令人感到悲哀的是，有好多同学还觉得国内的钉钉非常之好，殊不知，你之所以感觉好用，是因为你所在的环境是如此的不堪。你看，人到了不同的环境就会有不同的认识，所以，找一个好一些的环境对一个人的成长有多重要。

给一些新入行的人的建议就是，一个环境对一个人的认知会有非常大的影响，找一个好的环境是非常重要，如果不知道什么 环境是好的，那就先从不使用钉钉为工作协同软件的公司开始吧……

什么是好的协同工具

我们从上面可以得到，协同的前提条件是你需要有一个基于信任的企业文化，还需要有有结构化思维的科学的管理思维。没有这两个东西，给你的团队再多的工具都不可能有真正好有协同的，大家就是装模作样罢了。

假设我们的管理和文化都没有问题，那下面我们来谈谈协同工具的事。

我个人觉得 IM 这种工具包括会议都不是一种好的协同工具，因为这些工具都无法把信息做到真正的结构化和准确化，用 IM 或是开会上的信息大多都是碎片化严重，而且没有经过深度思考或是准备的，基本都是即兴出来的东西，不靠谱的概率非常大。

找人交流和开会不是有个话题就好的，还需要一个可以讨论的“议案”。在 Amazon 里开会，会前，组织方会把要讨论的方案打印出来给大家看，这个方案是深思过的，是验证过的，是有数据和证据或是引用支撑的，会议开始后，10 -15分钟是没有人说话的，大家都在看文档，然后就开始直接讨论或发表意见，支持还是不支持，还是有条件支持……会议效率就会很高。

但是这个议案其实是可以由大家一起来完成的，所以，连打印或是开会都不需要。试想一下，使用像 Google Doc 这样的协同文档工具，把大家拉到同一个文档里直接创作，不香吗？我在前段时间，在公网上组织大家来帮我完成一个《非常时期的囤货手册》，这篇文章的形成有数百个网友的加持，而我就是在做一个主编的工作，这种工作是 IM 工具无法完成的事。与之类似的协同工具还有大家一起写代码的 Github，大家一起做设计的 Figma……这样创作类的协同工具非常多。另外，好多这些工具都能实时展示别人的创作过程，这个简直是太爽了，你可以通过观看他人创作过程，学习到很多他人的思路和想法，这个在没有协同工具的时代是很难想像的。

好的协同工具是可以互相促进互相激励的，就像一个足球队一样，当你看到你的队友在勇敢地争抢，拼命地奔跑，你也会被感染到的。

所以，好的协同就是能够跟一帮志同道合，有共同目标，有想法，有能力的人一起做个什么事。所以，在我心中我最喜欢的协同工具从来都是创作类的，不是管理类的，更不是聊天类的。管理和聊天的协同软件会让你产生一种有产出的假象，但其实不同，这种工具无论做的有多好，都是支持性的工具，不是产出类的工具，不会提升生产力的。

另外，在创作类的协同工具上如果有一些智能小帮手，如：Github 发布的 Copilot。那简直是让人爽翻天了，所以，真正能提升生产力的工具都是在内容上帮得到你的。

结束语

我其实并不喜欢今天所有的 IM 工具，因为我觉得信息不是结构化的，信息是有因果关系和上下文的，是结构化的，是多维度的，不是今天这种线性的方式，我们想像一下“脑图”或是知识图，或是 wikipedia 的网关的关联，我们可能就能想像得到一个更好的 IM 应该是什么 样的……

协同工作的想像空间实在是太大了，我觉得所有的桌面端的软件都会被协作版的重写，虽然，这种协作软件需要有网络的加持，但是协作软件的魅力和诱惑力实在的太大了，让人无法不从……

未来的企业，那些管理类的工具一定会被边缘化的，聊天类的会被打成一个通知中心，而创作类的会大放异彩，让大家直接在要干的事上进行沟通、交互和分享。

（全文完）

写这篇文章的原因主要还是因为V2EX上的这个贴子，这个贴子中说——

“对接同事的接口，他定义的所有接口都是 post 请求，理由是 https 用 post 更安全，之前习惯使用 restful api ，如果说 https 只有 post 请求是安全的话？那为啥还需要 get 、put 、delete ？我该如何反驳他。”

然后该贴中大量的回复大概有这么几种论调，1）POST挺好的，就应该这么干，沟通少，2）一把梭，早点干完早点回家，3）吵赢了又怎么样？工作而已，优雅不能当饭吃。虽然评论没有一边倒，但是也有大量的人支持。然后，我在Twitter上嘲讽了一下，用POST干一切就像看到了来你家装修工人说，“老子干活就是用钉子钉一切，什么螺丝、螺栓、卡扣、插销……通通不用，钉枪一把梭，方便，快捷，安全，干完早回家……不过，还是有一些网友觉得用POST挺好的，而且可以节约时间。所以，正好，我在《我做系统架构的原则》中的“原则五”中反对API返回码无论对错全是200的返回那，我专门写下这一篇文章，以正视听。

这篇文章主要分成下面这几个部分：

1. 为什么要用不同的HTTP动词？
2. Restful 进行复杂查询
3. 几个主要问题的回应
   • POST 更安全吗？
   • 全用 POST 可以节省时间沟通少吗？
   • 早点回家的正确姿势
   • 工作而已，优雅不能当饭吃

为什么要用不同的HTTP动词

编程世界通常来说有两种逻辑：“业务逻辑” 和 “控制逻辑”。

• 业务逻辑。就是你实现业务需求的功能的代码，就是跟用户需求强相关的代码。比如，把用户提交的数据保存起来，查询用户的数据，完成一个订单交易，为用户退款……等等，这些是业务逻辑
• 控制逻辑。就是我们用于控制程序运行的非功能性的代码。比如，用于控制程序循环的变量和条件，使用多线程或分布式的技术，使用HTTP/TCP协议，使用什么样数据库，什么样的中间件……等等，这些跟用户需求完全没关系的东西。

网络协议也是一样的，一般来说，几乎所有的主流网络协议都有两个部分，一个是协议头，一个是协议体。协议头中是协议自己要用的数据，协议体才是用户的数据。所以，协议头主要是用于协议的控制逻辑，而协议体则是业务逻辑。

HTTP的动词（或是Method）是在协议头中，所以，其主要用于控制逻辑。

下面是HTTP的动词规范，一般来说，REST API 需要开发人员严格遵循下面的标准规范（参看RFC7231 章节4.2.2 – Idempotent Methods）

方法	描述	幂等
GET	用于查询操作，对应于数据库的 select 操作	︎
PUT	用于所有的信息更新，对应于数据库的 update 操作	︎︎
DELETE	用于更新操作，对应于数据库的 delete 操作	︎︎
POST	用于新增操作，对应于数据库的 insert 操作	✘
HEAD	用于返回一个资源对象的“元数据”，或是用于探测API是否健康	︎
PATCH	用于局部信息的更新，对应于数据库的 update 操作	✘
OPTIONS	获取API的相关的信息。	︎

其中，PUT 和 PACTH 都是更新业务资源信息，如果资源对象不存在则可以新建一个，但他们两者的区别是，PUT 用于更新一个业务对象的所有完整信息，就像是我们通过表单提交所有的数据，而 PACTH 则对更为API化的数据更新操作，只需要更需要更新的字段（参看 RFC 5789 ）。

当然，现实世界中，可能并不一定严格地按照数据库操作的CRUD来理解API，比如，你有一个登录的API /login 你觉得这个API应该是 GET ，POST，PUT 还是 PATCH ?登录的时候用户需要输入用户名和密码，然后跟数据库里的对比（select操作）后反回一个登录的session token，然后这个token作为用户登录的状态令牌。如果按上面表格来说，应该是 select 操作进行 GET ，但是从语义上来说，登录并不是查询信息，应该是用户状态的更新或是新增操作（新增session），所以还是应该使用 POST，而 /logout 你可以使用 DELETE 。这里相说明一下，不要机械地通过数据库的CRUD来对应这些动词，很多时候，还是要分析一下业务语义。

另外，我们注意到，在这个表格的最后一列中加入了“是否幂等”的，API的幂等对于控制逻辑来说是一件很重要的事。所谓幂等，就是该API执行多次和执行一次的结果是完全一样的，没有副作用。

• POST 用于新增加数据，比如，新增一个交易订单，这肯定不能是幂等的
• DELETE 用于删除数据，一个数据删除多次和删除一次的结果是一样的，所以，是幂等的
• PUT 用于全部数更新，所以，是幂等的。
• PATCH用于局部更新，比如，更新某个字段 cnt = cnt+1，明显不可能是幂等操作。

幂等这个特性对于远程调用是一件非常关键的事，就是说，远程调用有很多时候会因为网络原因导致调用timeout，对于timeout的请求，我们是无法知道服务端是否已经是收到请求并执行了，此时，我们不能贸然重试请求，对于不是幂等的调用来说，这会是灾难性的。比如像转帐这样的业务逻辑，转一次和转多次结果是不一样的，如果重新的话有可能就会多转了一次。所以，这个时候，如果你的API遵从了HTTP动词的规范，那么你写起程序来就可以明白在哪些动词下可以重试，而在哪些动词下不能重试。如果你把所有的API都用POST来表达的话，就完全失控了。

除了幂等这样的控制逻辑之外，你可能还会有如下的这些控制逻辑的需求：

• 缓存。通过CDN或是网关对API进行缓存，很显然，我们要在查询GET 操作上建议缓存。
• 流控。你可以通过HTTP的动词进行更粒度的流控，比如：限制API的请用频率，在读操作上和写操作上应该是不一样的。
• 路由。比如：写请求路由到写服务上，读请求路由到读服务上。
• 权限。可以获得更细粒度的权限控制和审计。
• 监控。因为不同的方法的API的性能都不一样，所以，可以区分做性能分析。
• 压测。当你需要压力测试API时，如果没有动词的区分的话，我相信你的压力测试很难搞吧。
• ……等等

也许，你会说，我的业务太简单了，没有必要搞这么复杂。OK，没有问题，但是我觉得你最差的情况下，也是需要做到“读写分离”的，就是说，至少要有两个动词，GET 表示是读操作，POST表示是写操作。

Restful 复杂查询

一般来说，对于查询类的API，主要就是要完成四种操作：排序，过滤，搜索，分页。下面是一些相关的规范。参考于两个我觉得写的最好的Restful API的规范文档，Microsoft REST API Guidelines，Paypal API Design Guidelines。

• 排序。对于结果集的排序，使用 sort 关键字，以及 {field_name}|{asc|desc},{field_name}|{asc|desc} 的相关语法。比如，某API需要返回公司的列表，并按照某些字段排序，如：GET /admin/companies?sort=rank|asc 或是 GET /admin/companies?sort=rank|asc,zip_code|desc

• 过滤。对于结果集的过滤，使用 filter 关键字，以及 {field_name} op{value} 的语法。比如： GET /companies?category=banking&location=china 。但是，有些时候，我们需要更为灵活的表达式，我们就需要在URL上构造我们的表达式。这里需要定义六个比较操作：=，<，>，<=，>=，以及三个逻辑操作：and，or，not。（表达式中的一些特殊字符需要做一定的转义，比如：>= 转成 ge）于是，我们就会有如下的查询表达式：GET /products?$filter=name eq 'Milk' and price lt 2.55 查找所有的价柗小于2.55的牛奶。

• 搜索。对于相关的搜索，使用 search 关键字，以及关键词。如：GET /books/search?description=algorithm 或是直接就是全文搜索 GET /books/search?key=algorithm 。

• 分页。对于结果集进行分页处理，分页必需是一个默认行为，这样不会产生大量的返回数据。

  • 使用page和per_page代表页码和每页数据量，比如：GET /books?page=3&per_page=20。
  • 可选。上面提到的page方式为使用相对位置来获取数据，可能会存在两个问题：性能（大数据量）与数据偏差（高频更新）。此时可以使用绝对位置来获取数据：事先记录下当前已获取数据里最后一条数据的ID、时间等信息，以此获取 “该ID之前的数据” 或 “该时刻之前的数据”。示例：GET /news?max_id=23454345&per_page=20 或 GET /news?published_before=2011-01-01T00:00:00Z&per_page=20。

注意：这里需要注意一下，在理论上来说GET是可以带 body 的，但是很多程序的类库或是中间件并不支持 GET 带 body，导致你只能用 POST 来传递参数。这里的原则是：

1. 对于简单的查询，很多参数都设计在 restful API 的路径上了，而 filter/sort/pagination 也不会带来很多的复杂，所以应该使用 GET 

2. 对于复杂的查询来说，可能会有很复杂的查询参数，比如：ElasticSearch 上的 index/_search里的 DSL，你也应该尽可能的使用 GET，而不是POST 除非客观条件上不支持GET。ElasticSearch 的官方文档里也是这么说的。

The authors of Elasticsearch prefer using GET for a search request because they feel that it describes the action—​retrieving information—​better than the POST verb. （我们推荐使用 GET而不是 POST，因为语义更清楚）However, because GET with a request body is not universally supported, the search API also accepts POST requests （除非你的类库或是服务器不支持 GET带参数 ，你再用POST，我们两个都支持）

陈皓注：但是在 ElasticSearch 7.11 后，GET 也不支持 body 了。这是 ElasticSearch 的设计和实现不对应了。

最后，如果你想在Rest中使用像GraphQL那样的查询语言，你可以考虑一下类似 OData 的解决方案。OData 是 Open Data Protocol 的缩写，最初由 Microsoft 于 2007 年开发。它是一种开放协议，使您能够以简单和标准的方式创建和使用可查询和可互操作的 RESTful API。

几个主要问题的回应

下面是对几个问题的直接回应，如果大家需要我回应更多的问题，可以在后面留言，我会把问题和我的回应添加到下面。

1）为什么API 要Restful，并符合规范？

Restful API算是一个HTTP的规范和标准了，你要说是最佳实践也好，总之，它是一个全世界对HTTP API的一个共识。在这个共识上，你可以无成本地享受很多的技术红利，比如：CDN，API网关，服务治理，监控……等等。这些都是可以让你大幅度降低研发成本，避免踩坑的原因。

2）为什么“过早优化”不适用于API设计？

因为API是一种契约，一旦被使用上，就很难再变更了，就算你发行新的版本的API，你还要驱动各种调用方升级他们的调用方式。所以，接口设计就像数据库模式设计一下，一旦设计好了，未来再变更就比较难了。所以，还是要好好设计。正如前面我给的几个文档——Microsoft REST API Guidelines，Paypal API Design Guidelines 或是 Google API Design Guide 都是让你好好设计API的不错的 Guidelines.

3）POST 更安全吗？

不会。

很多同学以为 GET 的请求数据在URL中，而 POST 的则不是，所以以为 POST 更安全。不是这样的，整个请求的HTTP URL PATH会全部封装在HTTP的协议头中。只要是HTTPS，就是安全的。当然，有些网关如nginx会把URL打到日志中，或是会放在浏览器的历史记录中，所以有人会说 GET 请求不安全，但是，POST 也没有好到哪里去，在 CSRF 这个最常见的安全问题上，则完全就是针对 POST 的。  安全是一件很复杂的事，无论你用哪方法或动词都会不能代表你会更安全。

另外，

• 如果你要 防止你的 GET 上有敏感信息，应该加个密，这个跟 POST是一样的。
• 如果你要防止 GET 会被中间人修改，你应该做一个URL签名。（通常来说， 我们都在 GET 上做签名，POST 就忘做了）
• 如果你要防止有人发一些恶意链接来 hack 你的用户（传说中的 GET 不如 POST 安全的一个问题），你应该用 HMAC 之类的认证技术做好认证（参看 HTTP API 认证授权术）。

总之，你要明白，GET 和 POST 的安全问题都一样的，不要有谁比谁更安全，然后你就可以掉以轻心的这样的想法，安全都是要很严肃对待的。

4）全用 POST 可以节省时间减少沟通吗？

不但不会，反而更糟糕。

说这种话的人，我感觉是不会思考问题。

• 其一，为API赋于不同的动词，这个几乎不需要时间。把CRUD写在不同的函数下也是一种很好的编程风格。另外现在几乎所有的开发框架都支持很快速的CRUD的开发，比如Spring Boot，写数据库的CRUD基本上就不需要写SQL语言相关的查询代码，非常之方便。
• 其二，使用规范的方式，可以节约新加入团队人员的学习成本，而且可以大大减少跨团队的沟能成本。规范和标准其实就是在节约团队时间提升整体效率的，这个我们整个人类进行协作的基础。所以，这个世界上有很多的标准，你只要照着这个标准来，你的所生产的零件就可以适配到其它厂商的产品上。而不需要相互沟通。
• 其三，全用POST接口一把梭，不规范不标准，使用你的这个山寨API的人就得来不断的问你，反而增加了沟通。另外，也许你开发业务功能很快了，但是你在做控制逻辑的时候，你就要返工了，从长期上来讲，你的欠下了技术债，这个债反而导致了更大的成本。

5）早点回家的正确姿势

不要以为你回家早就没事了，如果你的代码有这样那样的问题，别人看懂，或是出误用了你的代码出了问题，那么，你早回家有什么意义呢？你一样要被打扰，甚至被叫到公司来处理问题。所以，你应该做的是为了“长期的早回家”，而不是“短期的早回家”，要像长期的早回家，通常来说是这样的：

• 把代码组织设计好，有更好的扩展性。这样在面对新需求的时候，你就可以做到少改代码，甚至不改代码。这样你才可能早回家。不然，每次需求一来，你得重新写，你怎么可能早回家？
• 你的代码质量是不错的，有不错的文档和注释。所以，别人不会老有问题来找你，或是你下班后，叫你来处理问题。甚至任何人都可以很容易地接手你的代码，这样你才可能真正不被打扰

6）工作而已，优雅不能当饭吃

回应两点：

其一，遵循个规范而已，把“正常”叫“优雅”，可见标准有多低。这么低的标准也只能“为了吃饭而生存了”。

其二，作为一个“职业程序员”，要学会热爱和尊重自己的职业，热爱自己职业最重要的就是不要让外行人看扁这个职业，自己都不尊重这个职业，你让别人怎么尊重？尊重自己的职业，不仅仅只是能够获得让人羡慕的报酬，而更是要让自己的这个职业的更有含金量。

希望大家都能尊重自己从事的这个职业，成为真正的职业化的程序员，而不是一个码农！

（全文完）

本文分成下面个部分：

• 公司监控员工的技术手段有哪些？
• 为什么要监控员工？
• 外企和国企有什么不一样？
• 我对此事的看法

技术手段

下面是我经历过的几个手段：

1）通过网络嗅探的方式。也就是说，你只要上了公司的网络，你个人设备上的通讯信息就可以被人以网络抓包+分析的方式进行分析。当然，这样的手段已经不怎么好用了，因为现在的网络基本上都是HTTPS加密的，网络嗅探的方式只能知道你访问了什么IP，对于其中的数据是没有办法知道的。

2）通过使用公司提供的软硬件工具。你使用公司的电子邮箱，浏览器（或是公司的代理服务器），通讯工具（包括语音电话），手机办公应用……等来处理你的个人事宜的时候，必然会被监控。这样，你只需要不要使用公司的软件来处理自己的私事就好了。

3）通过安装一个监控程序。这个是最可怕的了，因为无论你加不加密都没用了。一般来说，你不安装这个程序，你就没有办法连上网络，包括公司内网和外网。这个监控程序，会收集你电脑或手机上能够收集的到的所有的信息，比如，你的网络信息，按键操作，录屏，软件数据……等等。

4）办公区监控。我见过的还有使用摄像头，在会议室中安装声音和视频监控设备，对整个办公区内发生所有的事情进行监控。

5）通过爬虫。通过爬虫分析员工的社交平台上的各种言论，包括招聘网站。除了公司需要分布和自己相关的舆情，同样也开始监控员工的行为和价值观等。这已经不是监控隐私信息了……

公司监控的目的

公司监控的目的最早就是为了防止自己公司内的数据和信息外泄，所以，他们害怕自己的员工访问了什么不合适的网站，或是下载了什么有恶意的软件，或是不小心发错了邮件。另外一些公司也会使用外包人员，所以，对于外部编制的人员更需要有信息泄漏防范的安全需求。当然，也害怕有一些商业间谍或是自己的员工被收买了窃取公司内部的敏感信息。尤其是对于一些本身就是做数据的公司，如我以前呆过的Thomson Reuters，这家公司主要是卖金融数据的，所以，对信息泄漏是非常注重的，其就是需要在员工的电脑上安装监控软件。

还有一些劳动密集型的工作，比如在Amazon里的仓库里工作的人，公司会监控员工的工作量，以此来评估员工的工作绩效。对于用监控软件来评估程序员的工作量，我到今天仅见过监控外包人员的，在中国，外包人员需要使用甲方的电脑进行签到和签退，以及相关的工作。除了上述的信息安全目前，还能够看到员工的工作时长的情况。

所以，一般来说，公司监控的目的主要是为了自己的信息安全，还有员工的工作量评估，一般来说，不会涉及员工的隐私。

但是，随着收集的数据越来越多，有些公司发现还可以做更多的事，比如，上述的员工离职倾向的分析。还有一些公司还会收集员工在外网的数据，比如你在社交平台上的各种言论，来分析你对公司的忠诚度和你的价值观取向……我个人觉得这些已经令人不耻了。

外企与国企不同之处

我经历过的公司中，外国公司和中国公司都有监控的经历，这里说一下他们的不一样之处。最大的不一样的地方是，外国公司会让你有知情权，而中国公司则完全没有。

我记得我进入Thomson Reuters 公司的时候，公司要求签署一份监控的知情的同意书，其中用中英文写的，就是说，你授权公司监控你的如下这些信息：1）上网记录，2）下载的软件，3）工作电脑，4）公司的座机电话，5）会议室和办公区的语音和视频监控……大概有两页A4纸，然后也说明了这些数据公司仅用于信息安全的风控，不用于个人隐私分析等等……并且会符合法律要求保护员工的这些数据不外泄……这些条款都经得起法律的推敲。这样的协议是需要员工签字的，并且对双方都有法律约束的。

中国的公司则不会告诉你他们会监控你哪些数据，而这些数据拿来做什么。 我记得我在某公司工作的时候，就有员工发现自己访问自己的gmail的录屏被公司收集后的愤怒……

我对此事的看法

一方面，我对于公司通过使用监控软件监控员工的行为我是能够理解的，但是，应该让员工有知情权，并和员工明确一个监控的信息和范围，包括收集的数据的用途和安全措施，以及数据多长时间销毁的协议。如果没有这个协议的话，我觉得本质上就是一种流氓行为。

另一方面，针对监控员离职的倾向来说，我实在不知道有什么意义？公司你知道了又能如何呢？你是要找员工作思想工作，还是要给员工更好的待遇，还是直接开掉？如果你对自己的企业有信心，你就不必担心员工会离开，如果你的企业有问题，你为什么不把心思花在建设自己的企业上来呢？安装这样的监控软件对于企业没有什么帮助，反而只会让你的企业的形象更low……

再仔细想想，员工有一万种方法泄漏你公司的信息，无论你怎么监控，只要他想，他总是能够找到方法的，不是么？如何让找到或是培养有职业操守的员工，如何管理自己企业的商业信息，如何建立一个更好的企业文化让员工更有归属感，成为企业的共同体，一同维护共同利益，为企业着想，这不才是公司真正应该干的事吗？！监控员工充分暴露了这样的企业没有一个好的企业文化，不懂得高级的管理，所以，只能靠监控这样的手段来管理企业了……这样的企业不去也罢了。

（全文完）

原则一：关注于真正的收益而不是技术本身

对于软件架构来说，我觉得第一重要的是架构的收益，如果不说收益，只是为了技术而技术，而没有任何意义。对于技术收益来说，我觉得下面这几个收益是非常重要的：

• 是否可以降低技术门槛加快整个团队的开发流程。能够加快整个团队的工程流程，快速发布，是软件工程一直在解决的问题，所以，系统架构需要能够进行并行开发，并行上线和并行运维，而不会让某个团队成为瓶颈点。（注：就算拖累团队的原因是组织构架，也不妨碍我们做出并行的系统架构设计）
• 是否可以让整个系统可以运行的更稳定。要让整个系统可以运行的更为的稳定，提升整个系统的 SLA，就需要对有计划和无计划的停机做相应的解决方案（参看《关于高可用的架构》）
• 是否可以通过简化和自动化降低成本。最高优化的成本是人力成本，人的成本除了慢和贵，还有经常不断的 human error。如果不能降低人力成本，反而需要更多的人，那么这个架构设计一定是失败的。除此之外，是时间成本，资金成本。

如果一个系统架构不能在上面三个事上起到作用，那就没有意义了。

原则二：以应用服务和 API 为视角，而不是以资源和技术为视角

国内很多公司都会有很多分工，基本上都会分成运维和开发，运维又会分成基础运维和应用运维，开发则会分成基础核心开发和业务开发。不同的分工会导致完全不同的视角和出发点。比如，基础运维和开发的同学更多的只是关注资源的利用率和性能，而应用运维和业务开发则更多关注的是应用和服务上的东西。这两者本来相关无事，但是因为分布式架构的演进，导致有一些系统已经说不清楚是基础层的还是应用层的了，比如像服务治理上的东西，里面即有底层基础技术，也需要业务的同学来配合，包括 k8s 也样，里面即有底层的如网络这样的技术，也有需要业务配合的 readniess和 liveness 这样的健康检查，以及业务应用需要 configMap 等等 ……

这些东西都让我感觉到所谓 DevOps，其实就是因为很多技术和组件已经分不清是 Dev 还是 Ops 的了，所以，需要合并 Dev和 Ops。而且，整个组织和架构的优化，已经不能通过调优单一分工或是单一组件能够有很大提升的了。其需要有一种自顶向下的，整体规划，统一设计的方式，才能做到整体的提升（可以试想一下城市交通的优化，当城市规模到一定程度的时候，整体的性能你是无法通过优化几条路或是几条街区来完成的，你需要对整个城市做整体的功能体的规划才可能达到整体效率的提升）。而为了做到整体的提升，需要所有的人都要有一个统一的视角和目标，这几年来，我觉得这个目标就是——要站在服务和 对外API的视角来看问题，而不是技术和底层的角度。

原则三：选择最主流和成熟的技术

技术选型是一件很重要的事，技术一旦选错，那会导致整个架构需要做调整，而对架构的调整重来都不是一件简单的事，我在过去几年内，当系统越来越复杂的时候，用户把他们的  PHP，Python, .NET，或 Node.js 的架构完全都迁移到 Java + Go 的架构上来的案例不断的发生。这个过程还是非常痛苦的，但是你没有办法，当你的系统越来越复杂，越来越大时，你就再也不能在一些玩具技术上玩了，你需要的更为工业化的技术。

• 尽可能的使用更为成熟更为工业化的技术栈，而不是自己熟悉的技术栈。 所谓工业化的技术栈，你可以看看大多数公司使用的技术栈，比如：互联网，金融，电信……等等 ，大公司会有更多的技术投入，也需要更大规模的生产，所以，他们使用的技术通常来说都是比较工业化的。在技术选型上，千万不要被——“你看某个视频公司也在用这个技术”，或是一些在论坛上看到的一些程序员吐槽技术的观点（没有任何的数据，只有自己的喜好）来决定自己的技术，还是看看主流大多数公司实际在用的技术栈，会更靠谱一些。
• 选择全球流行的技术，而不是中国流行的技术。技术这个东西一定是一个全球化的东西，不是一个局域化的事。所以，一定要选国际化的会更好。另外，千万不要被某些公司的“特别案例”骗过去了，那怕这个案例很性感，关键还是要看解决问题的思路和采用的技术是否具有普世性。只有普世性的技术有更强的生命力。
• 尽可能的使用红利大的主流技术，而不要自己发明轮子，更不要魔改。我见过好些个公司魔改开源软件，比如有个公司同魔改mesos，最后改着改着发现自己发明另一个 kubernetes。我还见过很多公司或技术团队喜欢自己发明自己的专用轮子，最后都会被主流开源软件所取代。完全没有必要。不重新发明轮子，不魔改，不是因为自己技术不能，而是因为，这个世界早已不是自己干所有事的年代了，这个时代是要想尽方法跟整个产业，整个技术社区融合和合作，这样才会有最大的收益。那些试图因为某个特例需要自成一套的玩法，短期没问题，但长期来说，我都不看好。
• 绝大多数情况下，如无非常特殊要求，选 Java基本是不会错的。一方面，这是因为 Java 的业务开发的生产力是非常好的，而且有 Spring 框架保障，代码很难写烂，另外，Java 的社区太成熟了，你需要的各种架构和技术都可以很容易获得，技术红利实在是太大。这种运行在JVM上的语言有太多太多的好处了。在 Java 的技术栈上，你的架构风险和架构的成本（无论是人力成本，时间成本和资金成本）从长期来说都是最优的

在我见过的公司中，好些公司的架构都被技术负责人个人的喜好、擅长和个人经验给绑架了，完全不是从一个客观的角度来进行技术选型。其实，从 0 到 1 的阶段，你用什么样的技术都行，如果你做一个简单的应用，没有事务处理没有复杂的交易流程，比如一些论坛、社交之类的应用，你用任何语言都行。但是如果有一天你的系统变复杂了，需要处理交易了，量也上来了，从 1 到 10，甚至从 10 到 100，你的开发团队也变大了，需要构建的系统越来越大，你可能会发现你只有一个选择，就是 Java。想想京东从.NET 到 Java，淘宝从 PHP 到 Java……

注，一些有主观喜好的人一定会对我上述对 Java 的描述感到不适，我还用一些证据说明一下——全中国所有的电商平台，几百家银行，三大电信运营商，所有的保险公司，劵商的系统，医院里的系统，电子政府系统，等等，基本都是用 Java 开发的，包括 AWS 的主流语言也是 Java，阿里云一开始用 C++/Python 写控制系统，后面也开始用 Java ……你可能会说 B站是用 go语言，但是你可能不知道 B 站的电商和大数据是用 Java……懂着数据分析的同学，建议上各大招聘网站上搜一下 Java 的职位数量，你就知道某个技术是否主流和热门……

原则四：完备性会比性能更重要

我发现好些公司的架构师做架构的时候，首要考虑的是架构的性能是否能够撑得住多大多大的流量，而不是考虑系统的完备性和扩展性。所以，我已经多次见过这样的案例了，一开始直接使用 MongoDB 这样的非关系型数据库，或是把数据直接放在 Redis 里，而直接放弃关系型数据库的数据完备性的模型，而在后来需要在数据上进行关系查询的时候，发现 NoSQL 的数据库在 Join 上都表现的太差，然后就开始各种飞线，为了不做 Join 就开始冗余数据，然而自己又维护不好冗余数据后带来的数据一致性的问题，导致数据上的各种错乱丢失。

所以，我给如下的一些如下的架构原则：

• 使用最科学严谨的技术模型为主，并以不严谨的模型作为补充。对于上面那个案例来说，就是——永远使用完备支持 ACID 的关系型数据库，然后用 NoSQL 作补充，而不是完全放弃关系型数据库。这里的原则就是所谓的“先紧后松”，一开始紧了，你可以慢慢松，但是开始松了，以后你想紧再也紧不过来了。
• 性能上的东西，总是有很多解的。我这么多年的经历告诉我，性能上的事，总是有解的，手段也是最多的，这个比起架构的完备性和扩展性来说真的不必太过担心。

为了追求所谓的性能，把整个系统的完备性丢失掉，相当地得不偿失。

原则五：制定并遵循服从标准、规范和最佳实践

这个原则是非常重要的，因为只有服从了标准，你的架构才能够有更好的扩展性。比如：我经常性的见到很多公司的系统既没有服从业界标准，也没有形成自己公司的标准，感觉就像一群乌合之众一样。最典型的例子就是 HTTP 调用的状态返回码。业内给你的标准是 200表示成功，3xx 跳转，4xx 表示调用端出错，5xx 表示服务端出错，我实在是不明白为什么无论成功和失败大家都喜欢返回 200，然后在 body 里指出是否error（前两年我在微信公众号里看到一个有一定名气的互联网老兵推荐使用无论正确还是出错都返回 200 的做法，我在后台再三确认后，我发现这样的架构师真是害人不浅）。这样做最大的问题是——监控系统将在一种低效的状态下工作。监控系统需要把所有的网络请求包打开后才知道是否是错误，而且完全不知道是调用端出错还是服务端出错，于是一些像重试或熔断这样的控制系统完全不知道怎么搞（如果是 4xx错，那么重试或熔断是没有意义的，只有 5xx 才有意义）。有时候，我会有种越活越退步的感觉，错误码设计这种最基本最基础的东西为什么会没有？并且一个公司会任由着大家乱来？这些基础技能怎么就这样丢掉了？

还有，我还见过一些公司，他们整个组织没有一个统一的用户 ID 的设计，各个系统之间同步用户的数据是通过用户的身份证 ID，是的，就是现实世界的身份证 ID，包括在网关上设置的用户白名单居然也是用身份证 ID。我对这个公司的内的用户隐私管理有很大的担忧。一个企业，一个组织，如果没有标准和规范，也就会有抽象，这一定是要出各种乱子的。

下面，我罗列一些你需要注意的标准和规范（包括但不限于）：

• 服务间调用的协议标准和规范。这其中包括 Restful API路径, HTTP 方法、状态码、标准头、自定义头等，返回数据 JSon Scheme……等。
• 一些命名的标准和规范。这其中包括如：用户 ID，服务名、标签名、状态名、错误码、消息、数据库……等等
• 日志和监控的规范。这其中包括：日志格式，监控数据，采样要求，报警……等等
• 配置上的规范。这其中包括：操作系统配置、中间件配置，软件包……等等
• 中间件使用的规范。数据库，缓存、消息队列……等等
• 软件和开发库版本统一。整个组织架构内，软件或开发库的版本最好每年都升一次级，然后在各团队内统一。

这里重要说一下两个事：

• Restful API 的规范。我觉得是非常重要的，这里给两个我觉得写得最好的参考：Paypal 和 Microsoft 。Restful API 有一个标准和规范最大的好处就是监视可以很容易地做各种统计分析，控制系统可以很容易的做流量编排和调度。
• 另一个是服务调用链追踪。对于服务调用链追踪来说，基本上都是参考于 Google Dapper 这篇论文，目前有很多的实现，最严格的实现是 Zipkin，这也是 Spring Cloud Sleuth 的底层实现。Zipkin 贴近 Google Dapper 论文的好处在于——无状态，快速地把 Span 发出来，不消耗服务应用侧的内存和 CPU。这意味着，监控系统宁可自己死了也不能干扰实际应用。
• 软件升级。我发现很多公司包括 BAT，他们完全没有软件升级的活动，全靠开发人员自发。然而，这种成体系的活动，是永远不可能靠大众的自发形成的。一个公司至少一年要有一次软件版本升级的review，然后形成软件版本的统一和一致，这样会极太简化系统架构的复杂度。

原则六：重视架构扩展性和可运维性

在我见过很多架构里，技术人员只考虑当下，但从来不考虑系统的未来扩展性和可运维性。所谓的管生不管养。如果你生下来的孩子胳膊少腿，严重畸形，那么未来是很难玩的。因为架构和软件不是写好就完的，是需要不断修改不断维护的，80%的软件成本都是在维护上。所以，如何让你的架构有更好的扩展性，可以更容易地运维，这个是比较重要的。所谓的扩展性，意味着，我可以很容易地加更多的功能，或是加入更多的系统，而所谓可运维，就是说我可以对线上的系统做任意的变更。扩展性要求的是有标准规范且不耦合的业务架构，可运维性要求的则是可控的能力，也就是一组各式各样的控制系统。

• 通过服务编排架构来降低服务间的耦合。比如：通过一个业务流程的专用服务，或是像 Workflow，Event Driven Architecture ， Broker，Gateway，Service Discovery 等这类的的中间件来降低服务间的依赖关系。
• 通过服务发现或服务网关来降低服务依赖所带来的运维复杂度。服务发现可以很好的降低相关依赖服务的运维复杂度，让你可以很轻松的上线或下线服务，或是进行服务伸缩。
• 一定要使用各种软件设计的原则。比如：像SOLID这样的原则（参看《一些软件设计的原则》），IoC/DIP，SOA 或 Spring Cloud 等 架构的最佳实践（参看《SteveY对Amazon和Google平台的吐槽》中的 Service Interface 的那几条军规），分布式系统架构的相关实践（参看：《分布式系统的事务处理》，或微软件的 《Cloud Design Patterns》）……等等

原则七：对控制逻辑进行全面收口

所有的程序都会有两种逻辑，一种是业务逻辑，一种是控制逻辑，业务逻辑就是完成业务的逻辑，控制逻辑是辅助，比如你用多线程，还是用分布式，是用数据库还是用文件，如何配置、部署，运维、监控，事务控制，服务发现，弹性伸缩，灰度发布，高并发，等等，等等 ……这些都是控制逻辑，跟业务逻辑没有一毛钱关系。控制逻辑的技术深度会通常会比业务逻辑要深一些，门槛也会要高一些，所以，最好要专业的程序员来负责控制逻辑的开发，统一规划统一管理，进行收口。这其中包括：

• 流量收口。包括南北向和东西向的流量的调度，主要通过流量网关，开发框架 SDK或 Service Mesh 这样的技术。
• 服务治理收口。包括：服务发现、健康检查，配置管理、事务、事件、重试、熔断、限流……主要通过开发框架 SDK – 如：Spring Cloud，或服务网格Service Mesh等技术。
• 监控数据收口。包括：日志、指标、调用链……主要通过一些标准主流的探针，再加上后台的数据清洗和数据存储来完成，最好是使用无侵入式的技术。监控的数据必须统一在一个地方进行关联，这样才会产生信息。
• 资源调度有应用部署的收口。包括：计算、网络和存储的收口，主要是通过容器化的方案，如k8s来完成。
• 中间件的收口。包括：数据库，消息，缓存，服务发现，网关……等等。这类的收口方式一般要在企业内部统一建立一个共享的云化的中间件资源池。

对此，这里的原则是：

• 你要选择容易进行业务逻辑和控制逻辑分离的技术。这里，Java 的 JVM+字节码注入+AOP 式的Spring 开发框架，会带给你太多的优势。
• 你要选择可以享受“前人种树，后人乘凉”的有技术红利的技术。如：有庞大社区而且相互兼容的技术，如：Java, Docker,  Ansible，HTTP，Telegraf/Collectd……
• 中间件你要使用可以 支持HA集群和多租户的技术。这里基本上所有的主流中间件都会支持 HA 集群方式的。

原则八：不要迁就老旧系统的技术债务

我发现很多公司都很非常大的技术债务，这些债务具体表现如下：

• 使用老旧的技术。比如，使用HTTP1.0， Java 1.6，Websphere，ESB，基于 socket的通讯协议，过时的模型……等等
• 不合理的设计。比如，在 gateway 中写大量的业务逻辑，单体架构，数据和业务逻辑深度耦合，错误的系统架构（把缓存当数据库，用消息队列同步数据）……等等
•  缺少配套设施。比如，没有自动化测试，没有好的软件文档，没有质量好的代码，没有标准和规范……等等

来找我寻求技术帮助的人都有各种各样的问题。我都会对他们苦口婆心地说同样的一句话——“如果你是来找我 case-by-case 解决问题，我兴趣不大，因为，你们千万不要寄希望能够很简单的把一辆夏利车改成一辆法拉利跑车，或是把一栋地基没打好的歪楼搞正。以前欠下的技术债，都得要还，没打好的地基要重新打，没建配套设施都要建。这些基础设施如果不按照正确科学的方式建立的话，你是不可能有一个好的的系统，我也没办法帮你 case-by-case 的解决问题……”，一开始，他们都会对我说，没问题，我们就是要还债，但是，最后发现要还的债真多，有点承受不了，就开始现原形了。

他们开始为自己的“欠的技术债”找各种合理化的理由——给你解释各种各样的历史原因和不得以而为之的理由。谈着谈着，让我有一种感觉——他们希望得到一种什么都不改什么都不付出的方式就可以进步的心态，他们宁可让新的技术 low 下来迁就于这些技术债，把新的技术滥用地乱七八糟的。有一个公司，他们的系统架构和技术选型基本都搞错了，使用错误的模型构建系统，导致整个系统的性能非常之差，也才几千万条数据，但他们想的不是还债，不是把地基和配套设施建好，而且要把楼修的更高，上更多的系统——他们觉得现有的系统挺好，性能问题的原因是他们没一个大数据平台，所以要建大数据平台……

我见过很多很多公司，包括大如 BAT 这样的公司，都会在原来的技术债上进行更多的建设，然后，技术债越来越大，利息越来越大，最终成为一个高利贷，再也还不了（我在《开发团队的效率》一文中讲过一个 WatchDog 的架构模式，一个系统烂了，不是去改这个系统，而是在旁边建一个系统来看着它，我很难理解为什么会有这样的逻辑，也许是为了要解决更多的就业……）

这里有几个原则和方法我是非常坚持的，分享给大家：

• 与其花大力气迁就技术债务，不如直接还技术债。是所谓的长痛不如短痛。
• 建设没有技术债的“新城区”，并通过“防腐层 ”的架构模型，不要让技术债侵入“新城区”。

原则九：不要依赖自己的经验，要依赖于数据和学习

有好些人来找我跟我说他们的技术问题，然后希望我能够给他们一个答案。我说，我需要了解一下你现有系统的情况，也就是需要先做个诊断，我只有得到这些数据后，我才可能明白真正的原因是什么 ，我才可能给你做出一个比较好的技术方案。我个人觉得这是一种对对方负责的方法，因为技术手段太多了，所有的技术手段都有适应的场景，并且有各种 trade-off，所以，只有调研完后才能做出决定。这跟医生看病是一样的，确诊病因不能靠经验，还是要靠诊断数据。在科学面前，所有的经验都是靠不住的……

另外，如果有一天你在做技术决定的时候，开始凭自己以往的经验，那么你就已经不可能再成长了。人都是不可能通过不断重复过去而进步的，人的进步从来都是通过学习自己不知道的东西。所以，千万不要依赖于自己的经验做决定。做任何决定之前，最好花上一点时间，上网查一下相关的资料，技术博客，文章，论文等 ，同时，也看看各个公司，或是各个开源软件他们是怎么做的？然后，比较多种方案的 Pros/Cons，最终形成自己的决定，这样，才可能做出一个更好的决定。

原则十：千万要小心 X – Y 问题，要追问原始需求

对于 X-Y 问题，也就是说，用户为了解决 X问题，他觉得用 Y 可以解，于是问我 Y 怎么搞，结果搞到最后，发现原来要解决的 X 问题，这个时候最好的解决方案不是 Y，而是 Z。 这种 X-Y 问题真是相当之多，见的太多太多了。所以，每次用户来找我的时候，我都要不断地追问什么是 X 问题。

比如，好些用户都会来问我他们要一个大数据流式处理，结果追问具体要解决什么样的问题时，才发现他们的问题是因为服务中有大量的状态，需要把相同用户的数据请求放在同一个服务上处理，而且设计上导致一个慢函数拖慢整个应用服务。最终就是做一下性能调优就好了，根本没有必要上什么大数据的流式处理。

我很喜欢追问为什么 ，这种追问，会让客户也跟着来一起重新思考。比如，有个客户来找我评估的一个技术架构的决定，从理论上来说，好像这个架构在用户的这个场景下非常不错。但是，这个场景和这个架构是我职业生涯从来没有见过的。于是，我开始追问这个为什么会是这么一个场景？当我追问的时候，我发现用户都感到这个场景的各种不合理。最后引起了大家非常深刻的研讨，最终用户把那个场景修正后，而架构就突然就变成了一个常见且成熟的的模型……

原则十一：激进胜于保守，创新与实用并不冲突

我对技术的态度是比较激进的，但是，所谓的激进并不是瞎搞，也不是见新技术就上，而是积极拥抱会改变未来的新技术，如：Docker/Go，我就非常快地跟进，但是像区块链或是 Rust 这样的，我就不是很积极。因为，其并没有命中我认为的技术趋势的几个特征（参看《Go,Docker 和新技术 》）。当然，我也不是不喜欢的就不学了，我对区块链和 Rust 我一样学习，我也知道这些技术的优势，但我不会大规模使用它们。另外，我也尊重保守的决定，这里面没有对和错。但是，我个人觉得对技术激进的态度比起保守来说有太多的好处了。一方面来说，对于用户来说，很大程度上来说，新技术通常都表面有很好的竞争力，而且我见太多这样成功的公司都在积极拥抱新的技术的，而保守的通常来说都越来越不好。

有一些人会跟我说，我们是实用主义，我们不需要创新，能解决当下的问题就好，所以，我们不需要新技术，现有的技术用好就行了。这类的公司，他们的技术设计第一天就在负债，虽然可以解决当下问题，但是马上就会出现新的问题，然后他们会疲于解决各种问题。最后呢，最后还是会走到新的技术上。

这里的逻辑很简单 —— 进步永远来自于探索，探索是要付出代价的，但是收益更大。对我而言，不敢冒险才是最大的冒险，不敢犯错才是最大的错误，害怕失去会让你失去的更多……

（全文完）

首先，我们先扪心自问一下，我们自己觉得读到的好的技术文章是什么？我不知道大家的是什么，我个人认为的好的文章是下面这样的：

• 把复杂的问题讲解的很简单也很清楚。比如我高中时期读到这本1978年出版的《从一到无穷大》，用各种简单通俗通懂的话把各种复杂的科学知识讲的清清楚楚。还有看过的几本很好的书，有一本是《Windows程序设计》，从一个hello world的程序开始一步一步教你Windows下的原生态编程。
• 有各种各样的推导和方案的比较，让你知其然知其所以然。有了不同方案的比较，才可能让人有全面的认识。这个方面的经典作著是《Effective C++》。
• 原理、为什么、思路、方法论会让人一通百通。这里面最经典的恐怕就是《十万个为什么》了，在计算机方面也有几本经典书，有《Unix编程艺术》、《设计模式》、《深入理解计算机系统》等书，以及《The C10K Problem》等很多技术论文。

其实，从教科书，到专业书，再到论文，都有上面这些不错的特质。

所以，如果你想做一个好的技术分享的话，下面是我总结出来的方法，供你参考。

• 先描述好一个问题。这样能够听众带入进来，如果这个问题是他们感同身受的，那是最好了。千万不要一上来就说What，或是直接冲进答案里。这样的分享是在灌输和填鸭。把Why说清楚。没有Why，直接谈What的技术分享，通常来说价值不大。
• How比What重要。在讲How的时候，也就是如何解这个问题。
  • 先要把问题模型说清楚，有了问题模型这个框框后，方案才有意义。
  • 然后要有不同技术的比较。有了比较后，听众才会更相信你。
  • 直接上What的技术细节，其实没有太大意义。
• 一定要有Best Practice或方法论总结，否则上不了档次的。也就是分享中大家可以得到的重要收获。

说明了这个模型就是：问题 –> 方案 –> 总结。这其中是有一定的心理学模型的，具体表现如下：

• 用问题来吸引受众，带着受众来一起思考
• 用问题模型来框住受众的思考范围，让受众聚焦
• 给出几种不同的解决方案，比较他们的优缺点，让受众有一种解决问题的参与感。
• 最后，给出最佳实践，方法论或套路，因为有了前三步的铺垫，受众欣然接受。
• 整个过程会让受众有强烈的成长感和收获感。

这里有几个示例，也是我在我司 MegaEase 内部的技术分享，供你参考（我个人的YouTube频道）

技术分享：Prometheus是怎么存储数据的（Youtube）

技术分享：Distributed Lock Manager（Youtube）

下面是我写在我们公司内的Knowledge Sharing中的Best Practice，供参考

Sharing Guideline

Please follow the following sharing protocols

Understand Sharing

• Sharing is the hard way to learn knowledge. The presenter gains the biggest advantages. not audience. 分享是学习知识的最难的方式。分享者获得的好处最最多的，而不是观众。
• Sharing can open the knowledge door for the audience, but you have to walk to knowledge by yourself. 分享可以为听众打开知识的大门，但你能不能获得知识还要靠你自己。

Best Practices

To perform a great sharing, please follow the below practices.

• Do not share a big topic, a small topic is better. A big topic could make the audience lose focus. Remember, Less is More!
• Sharing time less than 60 mins is the best.
• English language for slides is preferred.
• While prepare the sharing contents, it’s better to discuss with the senior people to help you to see the whole picture, understand the good side and bad side, know what you don’t know … etc.
• Strong Recommend Materials Outlines
  • What’s the Problem?
  • How to Solve the Problem?
  • The Best Solution or Practice.
  • The Mechanism, Key Techniques, and Source Code
  • Pros/Cons
  • References (Further reading)

For example, if you want to sharing a topic about Docker. the following outlines would be good one:

• What’s the major problems need to solve. (Provision, Environment, Isolation etc.)
• The Alternative solutions. (Puppet/Chef/Ansible, VM, LXC etc.)
• The Best Solution – Docker. Why?
• Docker’s key techniques – image, cgroup, union fs, namespace…
• Docker’s Pros/Cons
• Further reading list.

（全文完）

对我来说，在我二十多年的工作经历来看，期间经历了很多技术的更新换代，整个技术模式、业务模式也是一直变来变去，我们这群老程序员成长中所经历的技术比今天的程序员玩的还更杂更多。我罗列一下我学过的，而且还被淘汰掉的技术，大家先感受一下。

- MIS应用开发：FoxPro，PowerBuilder，Delphi
- OA：Lotus Notes，VBScripts
- 微软：ODBC/ADO，COM/DCOM，MFC/ATL，J++
- 服务器：AIX，HP-UX，SCO Unix
- Web：CGI，ISAPI，SOAP
- RPC：CICS，Tuxedo
- J2EE：Websphere，Weblogic
- DB：Sybase，Informix 

我想说的是，无论过去还是今天，我们这些前浪和你们后浪所面对的技术的挑战和对技术的焦虑感是相似的，我们那个时候不但玩996，还玩封闭开发（就是一周只能回家一天）。当然，唯一好的东西，就是比起今天的程序员来说，我们那个年代没有像微信、微博、知乎，抖音这些巨大消耗你人生的东西，所以，我们的工作、生活和成长都有很效率，不会被打断、喜欢看书、Google还没有被封……当然，那时代没有StackOverlow和Github这样的东西，所以，能完成的东西或质量都一般。

当然，这里并不是想做一个比较，只是想让大家了解一下两代程序员间的一些问题各有千秋，大同小异。在整个成长过程中，其实有很多东西是相通的，其本上来说，就是下面的三件事——

第一，如果想要把控技术，应对这个世界的一些变化，需要大致知道这个世界的一些规律和发展趋势，另外还得认识自己，自己到底适合做什么？在这个趋势和规律下属于自己的发挥领域到底是什么？这是我们每个人都需要了解的。

第二，打牢基础，以不变应万变，不管世界怎样变化，我都能很快适应它。基础的重要程度对于你能够飞多高是相当有影响的，懂原理的人比不懂原理的人能做出来的事情或是能解决的问题完全是两个层级的。

第三，提升成长的效率，因为现在社会的节奏实在太快了，比二十年前快得太多，技术层出不穷，所以我们的成长也要更有效率。效率并不单指的快，效率是怎么样更有效，是有用功除以总功（参看《加班与效率》），怎么学到更有效的东西，或者怎么更有效学习，是我们需要掌握的另一关键。

下面是我这多年来的一些认识，希望对你有帮助。

世界发展趋势

我个人经历的信息化革命应该分成三个阶段：

• 1990年代到2000年，这个时代MB时代，是雅虎、新浪、搜狐、网易门户网站的时代，这个时代就是ISP/ICP互联网提供商，把一些资讯数字化，然后发布到网络上。
• 2000年到2010年，这个时代叫GB时代，或是叫多媒体或UGC时代，上网开始变得普遍了，每个人手里的数码设备开始变得多了起来，可以上传照片，可以上传视频，甚至可以在网上做社交。
• 2010年到2020年，这个时代叫TB时代，这过去的十年是移动互联网时代，移动互联网只需要手机在线，不需要依靠电脑。因为手机随时在线，所以个人的各种各样的数据始终在被收集，只要用户上网就会产生数据，所以人的行为最终也被数字化了。

所有的硬件和软件都是跟着需要处理的数据而演进的，我们需要更大的带宽，更大的硬盘，更多的处理器……大到一定时候就只能进入分布式化的技术架构了，再大，数据中心也顶不住了，就会要引入更为分布式的边缘计算了。

另一方面，从业务上来看，我们可以看到整个世界就在不断地进行数字化，因为，只要数字化了，就可以进行复制传播和计算，只要可以进行计算了，就可以进行数学建模，就可以自动化，只要可以自动化了就可以规模化，只要可能规模化了，就可以改变整个行业。人类的近代史的大趋势基本上都是在解决能源和自动化的事，源源不断的能源是让机器不知疲倦的前提条件，用机器代替牲口，代替人类进行工作是规模化的前提条件。

所以，技术的演进规律基本是自动化加规模化，从而降低成本，提升效率。这就是为什么世界变得越来越快，人类都快跟不上节奏的原因，主要是整个社会不断被机器、数据所驱动。

人才需求

在这个过程中，需要什么样的人？下面是我的一些认识——

• 技工，在机器和自动化面前，肯定是需要能够操作机器的技术工人了，这类人是有技术的劳动力。在编程的圈子里俗称“码农”，他们并不是真正的工程师，他们只是电脑程序的操作员，所以，随着技术门槛的下降或是技术形式的变更他可能就会变得越来越不值钱，直到被淘汰掉。
• 特种工，这种人是必须了解原理和解决难题的一类人，他们是解决比较难的、特定的一些技术问题。当一种技术被淘汰，他并不容易被淘汰，因为他懂原理，原理就是解决问题的能力，是解决问题的套路和方法。
• 工程师，不但是使用技术，还可以把活儿做好，他们认为代码更多的时间是在维护，这些人使用各种各样的手段和各种技术，精益求精地持续不断地提高代码的易读性、扩展性、可维护性和重用性，这个过程似乎永无止境。对于这些有“洁癖”，有“工匠精神”，有“修养”的技术人员，我们称他们为工程师。这种人做事又稳又快，而且可以做出很多称手的工具和方法论。
• 再往上是设计师和架构人员，这些人主要是开发一些工具，框架，模式，提升软件开发和维护效率，同时也提升用户体验，和提升稳定性、性能、代码重用等，总的来说就是为了降本增效。这类人的工作降低了技术得到门槛，他们把技术门槛降低了以后，就可以把这个技术普及开来，就可以由广大劳工、技工、特殊工人使用了。
• 还有一类人是经理，经理主要是组织团队、完成项目、创造利润。这类人中，即有身先士卒的leader，也有高高在上的boss，但无论怎么样，这些人只不过是为了让一个公司或是一个团队更好组织在一起的“粘合剂”，这类人只有在大公司中才会变成更有价值。

这就是我总结的世界需要哪些人才，我们了解这些东西以后大概就明白我们现在所处的位置有什么样的问题，我们应该去什么样的地方。

Google评分卡

接下来，我们再来看看Google的SRE的自我评分卡：

0 – 对于相关的技术领域还不熟悉
1 – 可以读懂这个领域的基础知识
2 – 可以实现一些小的改动，清楚基本的原理，并能够在简单的指导下自己找到更多的细节。

3 – 基本精通这个技术领域，完全不需要别人的帮助
4 – 对这个技术领域非常的熟悉和舒适，可以应对和完成所有的日常工作。

• 对于软件领域 – 有能力开发中等规模的程序，能够熟练和掌握并使用所有的语言特性，而不是需要翻书，并且能够找到所有的冷知识。
• 对于系统领域 – 掌握网络和系统管理的很多基础知识，并能够掌握一些内核知识以运维一个小型的网络系统，包括恢复、调试和能解决一些不常见的故障。

5 – 对于该技术领域有非常底层的了解和深入的技能。

6 – 能够从零开发大规模的程序和系统，掌握底层和内在原理，能够设计和部署大规模的分布式系统架构
7 – 理解并能利用高级技术，以及相关的内在原理，并可以从根本上自动化大量的系统管理和运维工作。
8 – 对于一些边角和晦涩的技术、协议和系统工作原理有很深入的理解和经验。能够设计，部署并负责非常关键以及规模很大的基础设施，并能够构建相应的自动化设施

9 – 能够在该技术领域出一本经典的书。并和标准委员会的人一起工作制定相关的技术标准和方法。
10 – 在该领域写过一本书，被业内尊为专家，并是该技术的发明人。

SRE需要自评如下这些技术或技能。

– TCP/IP Networking (OSI stack, DNS etc)
– Unix/Linux internals
– Unix/Linux Systems administration
– Algorithms and Data Structures
– C/C++
– Python
– Java
– Perl
– Go
– Shell Scripting (sh, Bash, ksh, csh)
– SQL and/or Database Admin
– Scripting language of your choice (not already mentioned) _____________
– People Management
– Project Management

这个评分卡是面试Google前需要候选人对自己的各种技术进行自评，也算是一种技术人员的等级的度量尺，其把技术的能分成11个等级，我用颜色把其它成四大层级，希望这个评份卡能够给你一个能力提升的参考标准。

认识自己

认识了世界是怎么发展的，也知道技术人员的种类和层级，那么还要了解一下自己，因为如果不了解自己，那么你也无法找到自己的路和适合自己的地方。

我觉得，一个人要认识自己就需要认识自己的特长、兴趣、热情、擅长等，下面是一个认识自己的标准方法：

• 特长。首先你要找得到自己特长。你要认识自己的特长，找到自己的天赋，找到你在DNA里比别人强的东西，就拿你的DNA跟别人竞争就好了。所以你要找到自己可以干成的事，找到别人找你请教的事，你身边人找你请教就是说明你有特长。这是找到自己特长非常非常重要，扬长避短。
• 兴趣。如果你没有找到自己特长，就找自己有兴趣有热情的东西。什么叫兴趣？兴趣是再难再累都不会放弃的事。如果你遇到困难就会放弃不叫兴趣，那叫叶公好龙。不怕困难，痴迷其中，就算你没有特长，有了这种特质，你也是头部的人才。
• 方法。如果你没有特长，没有兴趣和热情就要学方法。这种方法就是要有时间观念，要会做计划，要懂统筹、规划对于做过的事情，犯过的错误多总结，举一反三，喜欢自己找答案，自己探究因果关系，这是一些方法，自己总结一些套路。
• 勤奋。如果你没有特长，没有兴趣，也没有方法，你还能做的事就是勤奋，勤奋注定会让你成为一个比较劳累的人，也是很有可能被淘汰的人随着你的年纪越来越大，你的勤奋也会越来越不值钱。因为年轻人会比你更勤奋，比你更勤奋、比你斗志更强，比你能力更强，比你要钱更少的人会出现。勤奋最不值钱，但是只要你勤奋至少能够自食其力。

以上就是为了应对未来技术变化，作为个人必须要从特长、兴趣、方法一层一层筛选挖掘，如果没有这些你就要努力和勤奋。就只能接受“福报”了。

从我个人而言，我不算是特别聪明的人，但自认为对技术还是比较感兴趣的，难的我不怕。有很多比较难啃的技术，聪明点的人啃一个月就懂了，我不行，我可能啃半年。但是没有关系，知识都是死的，只要不怕困难总有一天会懂的。最可怕是畏难，为自己找借口，这样就不太好了。

打好基础

最前面提到我学的各式各样的被淘汰的技术，会让你感觉很迷茫，或是迷失。但前面也提到了“谷歌评分卡”，在这个评分卡中，我们看到了许多基础原理方面的内容，其实要应对未来的变化，很重要的一点就是无招胜有招，以不变应万变。

变化都是表面的东西，内在的东西其实并没有太多的变化。理论层面上变得不多，反而形式上的东西今天一个花样，明天一个花样，所以如果要去应对这种变化，就一定要打牢自己的基础，提升内功修养。比如像编程的一些方式和套路，修饰模式原理本质，解耦，提升代码的重用度等。提升代码重用度必须解耦，要跟现实解耦，提升抽象，这些都是一些技术基础。无论用什么语言，都是这么做的。

打牢基础就可以突破瓶颈，不打牢基础没有办法突破瓶颈。在技术世界不要觉得量变会造成质变，这是不可能的。技术这个东西就像搞建筑砌砖头，砌砖头砌的再多也不可能让你能成为一个架构师的，因为你不懂原理，不懂科学方法，你就不可能成长上去的，就像学数学一样，当你掌握了微积分这种大杀器后，你解题的能力是无所披靡，而微积分这种方式绝对不是你能“量变”出来的。

所以你必须学习基础的理论知识，如果不学这些基础理论知识，还要学习解题思路和方法，如果你只学在表面，那么当这个技术的形式有变化，就会发现以前学的都没用了，要重头学一遍。掌握技术基础可以让自己找到答案和知识，基础是抽象和归纳，很容易形成进一步的推论。我们学的很多技术实现都逃不脱基础原理，不管是Java，还是其他语言，只要用TCP用的都是相同的原理，逃不出范围，只要抓住原理，举一反三，时间一长了，甚至还可以自己推导答案。对于技术的基础，我会把其它成四类：

• 程序语言：语言的原理，类库的实现，编程技术（并发、异步等），编程范式，设计模式……
• 系统原理：计算机系统，操作系统，网络协议，数据库原理……
• 中间件：消息队列，缓存系统，网关代理，调度系统 ……
• 理论知识：算法和数据结构，数据库范式，网络七层模型，分布式系统……

这些知识其实就是一个计算机科学专业的学生他所要学习的原理，但可惜的是，我们的一些学校教得也很糟糕，不但老师能力不足，而且放着世界上最优秀的教课书不用了，一定要自己写一本。讲也讲不全，还有各种错误，哎……总之，如果你学习用用到的教材不行，那么可以肯定的是你的学习效率一定是很糟糕的。这就是为什么我们大学上完了，还是跟个傻瓜一样，还要在工作中再重新自学。

不过，就算自学，这些基础技术大概需要四五年的时间堆叠。我工作二十年了，这二十年来基本还是这些原理没变，无论形式怎么变，但是核心永远还是这些，理论创新很难，这是以不变应万变。

学习效率

谈到学习效率，就需要拿出这张学习金字塔的图来了。从图可以看到学习方法分布两层，一种是被动学习，也是浅度学习，听讲，阅读，视听，演示都是在被动学习，而与人讨论，自己动手实践，教授给别人是主动学习。主动学习我们称之为深度学习，如果你不能深度学习，你就不能真正学到东西。这也是你会经常有“学那么多干什么，不用就忘了”，这就是浅度学习的症状了。

下面，我给出一些我自己觉得不错的学习经验：

1、挑选一手知识和信息源。对于学习方法：第一我们一定要到知识源去挑选知识，知识信息源非常关键，二手信息丢失太大了，谭浩强写的书就丢失太多信息了。目前计算机一手知识基本都是国外的，所以英文非常重要。我鼓励大家一定读第一手的资料。如果你英语有问题，至少要看翻译过来，最好是原汁原味翻译的，不要我理解了给你讲那种，那种也是被别人嚼一遍再讲给你你没有体会，是别人带着你，别人的体会会影响你，也许你的体会会比他更好，因为是你自己总结出来的东西，所以知识源很重要。

2、注意原理和基础第二要注重基础原理。虽然可以忘记这个技术，但是原理记在心里，我可以徒手实现出来，而且通过原理可以更快学习其他类似的技术。所以原理很重要！当你学会C、C++要学Java和GO都很快。

3、使用知识图谱一定要学会使用知识图，把知识结构化。从一个技术关键点开始不断地关联和细化下去，比如：关于TCP协议，首先第一个要记住状态图，怎么建立连接，怎么断连接，状态怎么变迁。TCP没有连接，是靠状态维护连接的。其次，要了解TCP怎么保证可靠性，就是丢包以后怎么重传，重传有哪些技术点。然后，重传会让你联想到拥塞控制，拥塞控制到滑动窗口……。这基本就是TCP的所有东西了，找到关键点，然后顺着这个脉络一点点往下想，通过知识图关联就可以进行顺藤摸瓜。我们不需要记所有知识，那些手册的知识不需要记，你知道在哪里能找到就可以了。你脑子里面要有地图，学一个东西就跟在城市生活一样，闭上眼睛就知道地图，A点到B点怎么去大概方向要知道。我在北京我去广州，广州在南边，我大概坐飞机还是火车要心里有数。。

4、学会举一反三。就是用不同方法学一个东西，比如说学TCP协议，看书是一种方法，编程是另外一种方法，还有用做Debug去看的，用不同方法学一个东西会让你更加熟悉，你学一个知识的同时把周边也学了。比如说学前端能不能把HTTP学一下，比如说长连接、短连接，包括hp1、hp2有一些不一样的东西。

5、总结和归纳。只有学会总结和归纳，才能形成自己的思维框架、自己的套路、自己的方法论，以后学这个东西应该怎么学。就像学一门新的语言，不管GO语言，还是Rust语言，第一件事情就是了解内存是怎么管理的，数据类型什么样，第二是泛型怎么搞，第三是并发怎么弄。还有一些抽象怎么弄，比如说怎么解耦，怎么实现多态？套路这种东西只有学的多了以后才能形成套路，如果你只学会一门语言不会有套路，你要每年学门语言，不用学多精，你思考这个语言有什么不一样，为什么这个这种有玩法，那个有那种玩法，这些东西思考多了套路方法论就出来了。比如说Windows和Linux有什么不同，Linux和Unix又有什么不同？只有总结自己的框架、套路和方法，这些才永远不会被淘汰。

6、实践和坚持。剩下就是多做多练，多坚持，只有实践才会有经验，只有锻炼了才能够把自己的脂肪变没，所以，要把知识变成技能必须练，就像小学生学会加减乘除，还是要演练，必须多做题，题目做得多了，自然掌握得好。要挑选好的知识源，注重原理技术，有一些原理的基础的书太枯燥，但是我告诉你学习这些基础太值得投入时间，搬砖赚几十元不值得，因为赚的是辛苦钱，老了就赚不了，必须要赚更有能力的钱，这是学习投资。

小结

好了，该到这篇文章收尾的时候了，小结一下，如果你想更好的把握时代，提升自己，你需要知道这个时代的趋势是什么，需要什么样的人，这些人需要什么样的能力，这些能力是怎么获得的，投入到基础知识的学习就像“基建”一样，如果基础不好，不能长高，学习能力也是需要适应这个快速时代的重要的基础能力，没有好的学习能力，很快就会掉队被淘汰。

这些东西，是我从业二十年来的总结和体会，希望对你有用。

（全文完）

我们在早期的时候，8个员工来自5个城市，现在的20来个员工来自8个城市2个国家。虽然我们现在使用“共享办公室”，但是本质上，我们的整个文化是远程工作的文化。在2017-2018年度，我们公司产品商业化以来，公司早期的8个工程师在远程工作的状态下成功支持了得到的老罗的跨年演讲活动，以及其它几个客户，一方面验证了用户愿意付费购买我们的产品和服务之后，另一方面也有一些不错的收入，客单价都在百万左右。还记得当时，有几个投资人并不相信我们连个办公室都没有，而且8个人分布在5个城市，觉得我们是个骗子公司（哈哈）。在过去的一年，我们通过我们的产品和服务帮助银行电信互联网等公司进行了他们的系统架构的改造和升级，让复杂和高门槛的分布式技术和架构可以被更多的企业所掌握所应用。这说明，远程工作是没有什么问题的。实际上远程团队远程工作真的不新鲜，Github上有个Repo维护着一个支持远程工作的公司列表，还有一个跟远程工作相关的Awesome索引。

当然，自从我创业以来，我身边就一直有好些不同的声音质疑远程工作。听过他们的理由后，我能够理解他们的疑虑和困惑，因为管理的确是一个很复杂的事，因为要面对的是极为复杂的人，所以，有这些疑虑也是正常的。下面是我的一些经验和分享。先说宏观管理，再说微观实践。

宏观管理

我发现很多人比较质疑远程工作的原因，更多的是表现在对宏观的管理上有问题。所以，我还是想先说一下宏观管理，这其实并不分远程办公还是集中式办公，如果能够解决好些这管理上的根本问题，其实，远程不远程都无所谓了。只不过，这些问题在“远程办室”的场景更更突显罢了。

一、努力找到好的人

团队管理的头等大事是找人，没有之一。很多人都会跟我说，你的这种远程团队需要很好的人。是的，没错，人很关键。远程团队需要的人的一般需要有这些特质：

• 能独挡一面的人。这样交给他的事能独立完成，没有路能自己找路，这样可以省很多管理成本。
• 沟通能力很强的人。一方面，他们把模糊的事能变清楚，另一方面，他能有效地说服他人。不然就会非常扯皮和消耗时间。
• 能自管理和自驱动。不能自管理和自驱的人，会增加大量的管理和教育成本。能自驱动的人，都是对负责的事情有认同的人。

如果你仔细思考一下，你会发现，这样的人是任何一家公司所渴望的人，和远不远程无关。只不过，如果是远程团队的话，你会被逼着要招到这样的人。

招到这样的人，你团队的执行力会非常的强悍。招不到这样的人，你只能为他们不能自管理和自驱而招“经理”，不能写出好的代码而招“测试”，不能很好的沟通而招个“项目经理”，不能独档一面，而要把好的人安排给他们当“教练”，而好的人则会被累死……

这个时候，你就需要计算一下了，是花时间精力在教育不好的人，还是花时间精力找好的人？无论远不远程，聪明的管理者都会选择后者。这也就是为什么Amazon的Bezos会说，“我宁愿面50个人一个人都招不到，我也不愿意降低我的面试标准”。

二、设定共同的目标和使命

对于远程团队来说因为见不到面，所以，缺乏交流和沟通。所以，需要团队里所有人能在同一篇上，能够对要做的事有一个统一标准的认识。也就是共同的目标和使命的认知。知道要要什么，不要什么。知道取舍，知道trade-off。这些东西都是需要团队一起达成的共识。如果没有这样的“Same Picture”的目标和使命，就会出现很多不必要的误解和冲突。另外，因为团队和业务也在迅速发展中，所以，也需要不断地调整和沟通。这都需要领导者花费时间统一目标和使命。

老实说，无论远程不远程，一个团队也是需要有共同的目标和使命的。没有共同的目标，就算是集中在一起办公，也一样没有效率的。

三、倾向使用小团队

因为沟通成本的问题，远程团队更为倾向使用小团队，但并不是说小团队会限制整个公司的规模。《人月神话》说过，只有小团队才能驾驭复杂的系统。Amazon 的 Two Pizza Team的文化（团队的大小只能到两张披萨就能喂饱的大小），就是把整个系统拆成“微服务”架构，这样可以导致整体效率的巨大提升。表现在，可以并行开发，专注于一个功能更利于解决复杂问题，简单可以更容易的运维，可以更容易的规模化……

我工作的这20多年来经历过很多公司，尤其是创业的这几年来，看过的公司更多了（50+以上了），我发现，人数越多的团队，基本上来说，就更偏劳动密集型。劳动密集型的一个特征就是，大家整天在想，得整点什么事给这么多人，好让他们忙起来。而人数少的团队，因为人不够，所以每天都在想，什么样的事更重要，什么样的事可以自动化，怎么做更有效率……小团队和大团队的关注点就这么不一样了，所以做出来的事也就不一样了……

当然，并不是说劳动密集型有什么问题，就像《软件团队的两种管理方式》一文所说的一样，远程团队工作更倾向于“电影工作组”式的每个人都是leader的知识密集型的团队。

微观实践

在远程工作中，我们需要有很多的微观操作来让大家能够更好的进行远程工作。因为远程工作也有一些问题（但是方法总比问题多，不是吗？）

• 文档驱动。首先，远程的问题就是沟通不方便了，集中化的办公一群人可以在白板上进行讨论，然后远程工作这个事就变成很复杂了。所以，当要讨论什么事的时候，需要发起人先写一个文档，然后大家在这个文档上进行讨论（我们通常使用Github的issue，Pull Request或Google Doc）。另外，写文档的好处太多了，除了给后人有一个可以追溯的东西，更重要的是，写作是一种深度思考，当你把你脑子里想的东西写下来的时候，你就会发现你的思考更多了。所以，文档驱动我们团队能力非常重要的事。

• 自动化和简化。自动化和简化是我平时追得最多的东西了，从软件的Unit Test, Functional Test, Performance Test 一直到用Kubernetes进行自动化部署，我要求的就是从一提交完代码后就自动化的上线。我们玩的是Amazon的“单分支”代码管理的玩法，一旦代码merge上master，就会直接上线（当然需要通过灰度）。因为远程团队如果没有自动化的工具，那么，就会导致整体效率的下降。

• Owner文化。这个太重要的了，但是，这并不是在说，如果一个事没有owner，就会像“三个和尚”那样，事情就进了没人管的地步。这是因为很多人在工作中都是比较 nice 的，比较 nice 的人通常来说都不好意思跳出来对别人发号施令。所以，Owner 文化就是要求每件事都要定义一个Owner，而这个Owner是有权对其它人发号施令的，其他人也有义务要配合他。当然，Owner 的权利越大，责任也会越大！

• Review文化。Review文档是一种把知识或是想法传递出去的方式。我们在实践过程中，需要大家把好的想法写下来，这需要包括问题背景、目标、可选的方案（这些方案需要有引用和数据，不能是拍脑袋）、还需要有Pros/Cons的比较。然后再发起讨论。这样，事情在一开始就做好，那么就可以让大家的讨论更加地有效率。很多人以为开会讨论有个议题就行了，其实不够，有效率的开会讨论需要的是议案，而且还是高质量的议案！

• 目标承诺。我们需要每个人承诺自己的工作目标，这个完全由每个个体来发起、完成。一般来说，每个人自己给自己制定的计划最好是在1-2周内。

• 自我管理。我们的实践是没有审批制度，无论是，休假、报销、出差，完全是自己自由安排，但需要告诉团队（除非在一些关键时期没法休长假，需要整个团队全力以赴），但千万不要撒谎和作弊，一旦发现，直接开除就好了。这个是基于好人更多的原则制定的（没有必要为了少数的坏人一刀切后让所有人痛苦）

• 闲聊和自行见面。见面和不能见面是一件非常不一样的事，在一起工作时，人和人是会有感情的，因为会有闲聊。远程的时候，则只有工作了。所以，我们鼓励团队人员间的私聊，闲聊，互相对方讲讲自己的经历和过往，同时，也鼓励员工自行出差到对方的城市见见跟你一起工作的人，公司报销差旅费。

• 知识分享会。我们每周都有知识分享会，一次只讲半个小时，不贪多，就讲一个小的知识点。然后，团队中的一些人还主动使用Google Form来收集分享的反馈信息。

• 就地奖励文化。我们默认上是没有年终奖，只有就地奖励文化。也就是说，你做的事挣钱了，利润中有70%公司拿走，剩下的30%团队的人就地分掉。这样会让团队里的每个人都会想怎么挣钱，除了可以把精力放到那些能够让用户付费的地方上，更重要的是让团队成员了解一下业务和用户为什么要付费，这个是非常关键的。当然，如果公司没有挣钱，但是员工工作的不错，我们还是会给年终奖的。不挣钱的主要责任是我的，而挣钱的主要功劳是团队的。

• 外包支持性的工作。一些支持性的工作尽可能地使用外包，比如：HR、行政、发工资财务、员工持股、测试人员、定制化开发……这样可以让你的团队更小，更高内聚。更利于远程。

• 异步编程。如果一个项目是从零开始的，对于一个团队来说可能会是无从下手的，这需要有个人（owner）把代码的框架和结构给组织好。然后其他的人进入把坑填了，这样的效率会高很多。另外，不见面的结对编程，完全可以使用异步的方式进行，这其实就是多人干同一个pull request的方式。有Github这样的协议工作，远程编码变得很方便。

关于我们的远程工具，我们主要是使用：

• 开发环境
  • AWS，我们主要使用AWS，因为我希望团队在使用AWS的时候能够被潜移默化。
• 协作工具
  • Github。我们所有跟软件开发的工作都会在Github上，我们重度使用 Github 的 pull request 和 issue，也会使用 Github Project 里的看板和 Wiki。
  • Google全家桶。我们重度使用 Google，Google Group、Google Driver、Google Docs 主要是一些各式各样的文档。
• 通讯工具
  • 语音沟通。主要是使用Zoom，因为Zoom不但可以支持几十人在线，还可以云录制。如果小范围交流的话，一般使用微信语音。
  • 工作沟通。主要是使用Slack，Slack作为一个信息集散地，可以分频道，可以分thread讨论，微信注是个渣。
  • 吹水群。我司的吹水群主要是Telegram，因为比微信好太多了……

你会发现，我们的工具有好些都是在墙外的，是的，因为墙内的同类的工作实在是太难用了，没办法不用。而且，我倾向于让大家用上最先进的工具，这样我们团队中的每个人的品味才会被这些好的工具潜移默化。

远程工作协议

下面是我们的远程工作协议（无删减），这是每一个远程工作人员需要同意并做到的协议（其中有 Amazon Leadership Principles 的影子），目前在 v1.3 版，未来还会更新，我现在把它晒出来，也希望得到更好的建议！

MegaEase 远程工作团队协作协议 v1.3

Principles

0）Ownership & Leadership

每个人都是Owner，都是Leader， 如果看到团队或是项目有问题的时候，不要等，也不忍，请马上说出来，并给出相应的方案， 自己跳出来召集开会，及时调整。不要闷在那里，自己憋！

1）Initiative

每人个都必需是主动的，都需要自己发起要做的事，或是自己要认领要做的事，如果发现自己没有事情了， 需要学会主动发现问题，主动找到可以improve的地方，创新来源于此。没有路要学会自己造路！

2）Objectives Oriented

每个人都是产品经理，也都是项目经理，每个人都必需把自己的工作和我们大的目标连接在一起，知道什么是重点，重点的东西就是两件事：一）从用户的角度出发，二）从产品的角度出发。 这意味着我们要随时观察整个产品的样子，而不只是自己这一块东西 。

3）Insists on High Standard

举法其上，得乎其中，举法其中，得乎其下，举法其下，法不得也。我们要坚持用高的标准要求自己，对于高标准的目标不妥协，但是在实施路径和策略上可以妥协。

Practices

0）Online

工作的时候必需在线。如果不在线了，需要说一下不在线的时长, 目前我们工作的事宜在通讯工具采用Slack， 如果需要请假的情况，如果不是紧急情况，需要提前一天 在MegaEase的Slack #random 频道中提前说明。如果是紧急情况，也需要提前在random频道中告知大家。

1) Documentation Driven

面对面交谈、电话语音、微信、Slack虽然是比较实时的反馈工具，但是只有文档是可以把重要信息给结构化的，而且写文档其实是比起前面的方式来说是更为深度的思考，因为会让你自己审视自己的想法。所以，对于一些重要 “功能”、“流程”、“业务逻辑” 、“设计”、“问题”，以及“想法”，最好都以文档化的方式进行。请使用Github的 wiki、project、issue这些工具或是使用Google Doc.

2）Design Review

对于一些重要的问题或是工作（每个人都能够判断什么是关键问题和工作）， 需要先把自己的想法share出来，而不是先实现 。

一个好的 Design 文档需要包括如下项：

• Background。交待这个事的背景、需求和要解决问题。
• Objectives。说明这个事的目标和意义。
• Alternative Solutions。 给出多个解决方案，并能够进行 Pros/Cons 对比。
  • Reference。方案需要有权威引用支持。
  • Data。方案需要有相关数据数据支持。
• Conclusion。结论是什么。

3) Simplification & Automation

简化和自动化是软件工程所追求的两大目标，简化不是简陋，简化是对事物一种抽象和归纳能力，其能够提升软件的复用能力和扩展性，自动化是工程能力的重要体现，一方面，远程工作中自动化的能力可以让整个团队更高效地协作，另一方面，自动化是规模化的提条件。所以，我们要无时无刻地思考如何简化和自动化现有的事情。

4）Review & Re-factory

无论是代码还是工作都是需要反思和重构的。反思是进步的源泉，项目告一段落时，出现问题时，都应该召集团队做集体反思，把好的东西坚持下去，把不好的东西优化掉。这样才能进步和改进。但是任何的优化措施是可执行的。

5）Milestone Commitment

对于一个项目，每个人都需要有自己的 milestone 计划， 这个计划最好是在2周以内，1周内是最好的。而且要承诺到 。

6）Evidence Driven

任何讨论和分析都要基于权威的证据、数据或是引用。在我们做设计的时候，或是有争论的时候，说服对方最好的方式就是拿出证据、数据或是权威引用。比如：我的XX设计参考了TCP协议中的XX设计，我的XX观点是基于XX开源软件的实现……如果争论不休就停止争论，然后各自收集和调查自己观点的佐证。

7）Demo Day

把自己做的东西跟团队做一次实时的演示。这样有助于开发人员从产品角度思考自己的工作。除了演示产品功能，还可以演示算法，设计，甚至代码。

8) Effective Meeting

会议主要处理三件事：提出议案、发现问题、共识结论。

• 会议不仅仅要有议题，最好还有议案。
• 会议期间不解决问题，只发现问题，和跟踪问题。
• 会议必需要有共识和结论，如果不能达到共识和结论，那就当成问题处理，由问题的负责人跟进问题。

关于周会或是临时性的团队会议（私下讨论不属于会议），会议组织者需要在事前收集会议议题，其中包括如下分类：

• 项目类：需要事先有项目进度计划表（任何分项最好控制在1-2人周内）
• 方案类：需要事先写好相关的方案和设计才能讨论（参看 Design Review 章节）
• 问题类：需要事先写好相关的问题和解决提案（参看 Design Review 章节）
• 决策类：需要事先写好整事的前因后果以及利弊分析
• 信息类：需要事先写好相关的事宜说明

组织者需要在周五的时候发出会议议题收集，其中包括：

• 自己知道的项目的进度跟进（需要相相关的项目负责人准备相关的项目计划）
• 方案和问题类的需要各个项目负责人提出来，并有相关的设计文档可供Review
• 信息类和决策类的事宜可以写在Google Doc上，也可以写在 Team 的 Issue 里

其它负责人可以在会议上加入自己团队的东西，或是要求其他团队提供更多的信息。

9）1-2-3 Escalation

遇到问题的时候，自己一个人处理1小时内没有思路，请找他人小范围讨论，如果与他人2小时内没有结果，请上升到团队范围，如果在团队范围3小时内没有思路，我们就需要借助外部力量了。

A）3PS Update

每个人更新进度的时候，不要只是一个check-in，而是需要更 meaningful 的说一下工作内容，在工作告一段落的时候，希望简单的说一下工作总结。这里的practice是： 3PS – Plan，Proirity，Problem，Summary， – 你的计划是什么？优先级是什么？遇到了什么问题？当前的工作摘要 。

B) Disagree and Commitment

在我们开发的时候，团队的成员都会有自己风格，必然会对同一个问题产生较大的争议（Disagree），我们鼓励有争议，但是是在团队的决议作出之前。一旦团队形成决议，团队的成员就必须支持这个决议，并在这个方向上做出贡献。

但是关于决议的形成过程肯定充斥着各种的争论，对于这些争论，我们可以按照下面的Guidline 来处理争议：

• Owner要负责对重大的讨论推进，尽快形成结论。
• 在决议过程中，要有纪要，要更新到 Github 相关项目的 Issue 或 Pull Request 里，并且要让整个团队知道，信息平等很重要。
• 不要妥协，坚持高的标准。第一标准是工业标准，第二标准是国外的大公司标准（如：google, fb, github, aws…），第三标准才是国内的标准。
• 那怕再复杂，只要是标准，就可以说服用户。用户再无理，也不可能反对工业级的标准。
• Release出去的东西，只要被用户用上了，要改就难了，所以要谨慎而果敢。

小结

远程工作并不是目的，但是远程工作会逼迫管理者面对管理的本质问题。远程工作趋向于找到优秀自驱的人才，守护团队的共同目标，并打造精悍高能的团队，并要求我们在需要沟通和协作的地方使用更为科学和有效的手段，在各个环节中提升工作效率，降低组织内耗……你的团队管理模型是否最优，在远程工作下就会一览无余！远程工作只是一个手段，提升管理水平才是真正的目的！

（全文完）

我的思维方式中，使用数学逻辑的方式进行思考，通常来说，我会使用五步思考的方式：

第一步：信息数据可考证。如果一个观点或是一个见解的数据是错误的，那么就会造成后面的观点全是错的，所以，首要的是要进行数据的查证或考证。一般来说，如果一篇文章的作者足够严谨的话，他的需要给他的数据建立相关的引用或是可以考证的方法方式。如果一篇文章中出现的是，“有关专家表明”、“美国科学家证明”、“经济学家指出”，但是没有任出处，也没有点明这个专家或是科学家的名字，或是，也没有说明或引用让读者可以自己去验证的方法。那么，其引用的话或是数据是无法考证的，如果是无法考证的，那么，这篇文章的水份就非常大了。一般来说，当我读到一篇文章中的东西没有可考证的来源或是方法时，通常来说，我就不会再读了，因为这篇文章的价值已经不大了，如果我关心这篇文章中的东西，我会改为自己去查找的方式，虽然变“重”了，但是很安全。（所以，像Wikipedia这样的网站是我经常去获得信息的地方，因为信息可以被考证是其基本价值观）

第二步：处理集合和其包含关系。这是一个非常简单的人人都会的数学逻辑。比如：哲学家是人，柏拉图是哲学家，所以，柏拉图是人。就是一个在包含关系下的推理。你不要小看这个简单的逻辑，其实很多人并不会很好的应用，相反，当感情支配了他们以后，他们会以点代面，以特例代替普遍性。比如，地图炮就是一种，他们看到了多个案例，他们就开始把这个案例上升上更大的范围，比如：河南人新疆人都是小偷，上海人都是小市民。日本人都是变态和反人类……等等。除了这些地图炮外，还有否定整个人的，比如一个人犯了个错或是性格上有缺陷，就会把整个人全盘否定掉，员工抢个月饼就上升到其价值观有问题……。在数学的逻辑包含中，超集的定义可以适用于子集，通过子集的特征可以对超集进行探索，但是没法定义超集。另外，集合的大小也是一个很重要的事，幸存者偏差会是一个很容易让人掉下去的陷阱，因为可能会有很大的样本集可能在你的视线盲区。

第三步：处理逻辑因果关系。所谓因果关系，其实就是分辨充分条件、必要条件和充分必要条件，然后处理其中的逻辑是否有关联性，而且有非常强的因果关系。没有能力分辨充分必要条件处理因果关系是很多人的硬伤。就像我在《努力就会成功》中说的一样，“努力” 和 “成功”是否有因果关系？各种逻辑混淆、概念偷换、模糊因果、似是而非全是在这里。比如：掩耳盗铃、刻舟求剑就是因果关系混乱的表现。人们会经常地混淆两个看来一起发生，但是并没有关联在一起的事。因果关系是最容易被模糊和偷换的，比如：很多人都容易混淆“加班”就会有“产出”，混淆了“行动”就会有“结果”，混淆了“抵制”就会赢得“尊重”，混淆了“批评”等于“反对”……等等。除了这些以外，微信公众号里的很多时评文章，他们的文章中的结论和其论据是没有因果关系的，好多文章就是混淆、模糊、偷换……因果关系出问题的文章读多了是对大脑有损伤的，要尽量远离。

第四步：找到靠谱的基准线。就像我们写代码一样，我们都是会去找一些最佳实践或是业内标准，原因是因为，这样的东西都是经过长时间被这个世界上很多人Review过的，是值得依赖和靠谱的，他们会考虑到很多你没有考虑过的问题。所以，你也会看到很多时评都会找欧美发达国家的作参考的做法，因为毕竟人家的文化是相对比较文明、科学、开放和先进的。找到世界或是国际的通行标准，会更容易让人进步。比如：以开放包容加强沟通的心态，就会比封闭抵制敌对的心态要好得多得多，智者建桥，愚者建墙。当然，我们也开始发现，有一些事上，有利于自己的就对标，不利于自己的就不对标，而且，除了好的事，不好的事也在找欧美作对标，于是开始“多基准线”和“乱基准线”，这种方式需要我们小心分辨。

第五步：更为深入和高维的思考。如果一件事情只在表面上进行思考其实只是一种浅度思考，在Amazon，线上系统出现故障的时候，需要写一个Correction of Errors的报告，其中需要Ask 5 Whys（参看 Wikipedia 的 Five Whys 词条），这种思考方式可以让你不断追问到深层次的本质问题，会让你自己做大量的调查和研究，让你不会成为一个只会在表面上进行思考的简单动物。比如：当你看到有出乎你意料的事件发生时（比如负面的暴力事件），你需要问一下，为什么会发生，原因是什么？然后罗列尽可能全的原因，再不断地追问并拷证下去（这跟写程序一样，需要从正向案例和负向案例进行考虑分析，才可能写出健壮性很强的代码），我们才会得出一个比较健壮的答案或结构。

需要注意的是，在上述的这五种思维方式下，你的思考是不可能快得起来的，这是一个“慢思考”（注：如果读过《思考，快与慢》这本书的人就知道我在说什么），独立思考是需要使用大脑中的“慢系统”，慢系统是反人性的，所以，能真正做到独立思考的人很少。更多的人的“独立思考”其实只不过是毫无章法的乱思考罢了。

通过上述的这五点，我相信你是很容易识别或是分辨出哪些信息是靠谱的，哪些信息是很扯的，甚至会改善你自己的言论和思考。但是，请注意，这些方法并不能让你获得真理或是真相。但是这也够了，一个人如果拥有了能够分辨是非的能力，也是很不错的了。虽然不知道事实是什么，但是你也不会盲从和偏信，从而不会被人煽动，而成为幕后黑手的的一只“肉鸡”。

多说两句，下面是一些我个人的一些实践：

• 当新闻报道报道的不是客观事实，而是加入了很多观点，那么这篇新闻报道是不可信的。
• 对于评论性的文章，没有充足权威可信的论据时，不能完全相信。
• 不是当事人，不是见证人，还要装作自己是知情的……不知道这种人的自信怎么来的？
• 信息不公开的，并有意屏蔽信息的，不能作为可信的信息源。
• 当出现大是或是大非的事时，一定要非常小心，这个世界不存在完全的美和完全的丑，这样的观点通常来说都是危险的，此时要多看看不同角度的报道和评论，要多收集一些信息，还要多问问为什么。

欢迎你告诉我一些你的实践和思维方式。

（全文完）

几个故事

2019年年初，我面试了一个很年轻的小伙子（93/94年出生），这个小伙子特别有灵性，也很聪明，计算机专业出身，也很喜欢技术，基础和学习能力也很好。在我这20年来认识的人中，如果他能呆在北京、上海、深圳这样的城市，我保证不出三年，他会成为他们同龄人中非常出色的技术人员，如果有个好的舞台有一个好的团队带他，他的未来会非常成功。然而，这个小伙子有两大喜好：1）只愿（或是说被迫）呆在一个毫无IT的环境的三/四线城市，2）对技术有非常大的偏好，只喜欢Go语言，非常不喜欢其它的语言，比如：Java（离开Java的世界，基本上离开了做架构的世界（相关解释见文末））。

他的这两个喜好，足以让一个未来会很优秀的人毁掉，因为，这个时代没有限制他，他的能力也没有限制他，但是他的意识完完全全地限制了他。

• 他把自己最宝贵的青春放在了很烂的项目上，就算能用一些新的技术，他也只能算是自娱自乐，在实验室中玩玩具罢了。
• 他把自己的技术栈封闭起来，而直接放弃了这个时代最具工业化的技术Java，对于一个好的程序员来说，同时掌握几门语言和技术完全是没什么问题，但是自己封闭了自己的视野。

实在是非常可惜，我本来是可以为他介绍到一些很不错的公司的，但是他这样的习性，等于自己把自己未来的门给关上了，虽然我跟他长谈过，但是我也没有办法叫醒不想醒的人……

• 视野、环境和舞台，对一个人的限制是非常大的。井蛙不知道大海，被空间维度所限制；夏虫不知道冬天，是被时间维度所限制；圈养的动物没有斗志，是被自己意识所限制。
• 偏见和不开放，对一个人的限制是真正有毁灭性的。主动让自己成为一个瞎子和聋子，主动把自己的能力阉割掉，这是一件令人痛心的事。想想大清的闭关锁国是如何让亚洲第一的北洋水师给毁掉的……

我还有个同学，他的技术并不差，就算呆在昆明这种很落后的地方，他也非常地好学，学习英文，学习各种新技术，对技术没有任何的偏好，喜欢C/C++/Java/Python/Shell，同样喜欢前端Javascript，对基础知识非常地踏实，他在技术上没有限制自己的潜力，有什么就学什么。后来，我带他玩Docker/Go/K8S……分布式架构，他也上手的很快……像他这样的人，技术能力完全没得说，比我还大一岁，44岁了，还是一样的天天追代码细节，看Youtube的各种大会，翻github里的各种issue和pull request……

我同学这人，拥有了成为一个技术牛人几乎所有的条件：基础知识过硬，细节扎得深，面很广，学习能力强，有英文能力，逻辑思维能力不错，非常的自律，执行力也很强，抓得住重点……然而，只有一个小问题，就是没有到大公司历练过，我三番五次叫他从昆明出来，但是最终他都呆在昆明这个城市没有出来，因为有所谓的家庭约束。然而，我身边还有好些人，把自己家从北京搬到上海，从上海搬到深圳，从厦门搬到深圳……这样的人大有人在……像他这样的能力，在哪个公司都会是主力和骨干，对于一个公司的主力和骨干来说，家庭上的这些问题都是小问题都是有很多解的……

另外，我这个同学还是一个比较悲观的人，任何事情都是先想到不好的事，他关注负面的东西会胜于正面的东西，而且他还有一定的社交恐惧，怕与人相处和交流，时间越长越害怕，甚至有时候直接跟我说，“我就是不想改变”这样的话……其实，我以前也是一个很害怕与人交流的人，面试的时候，我根本不敢正眼看面试官一眼，也不知道与人怎么交流。但是，我与他不一样，我努力克服，不断地面试，与人面对面的交流，到一线技术客服接用户的电话，在公司里做分享，慢慢地到外面分享……3-5年就完全克服掉了。

其实，很多事情，完全是有解的，也没有必要担心，自己的心理障碍也是可以克服的，重点就是自己愿不愿意，只要愿意完成了一半，接下来就是不断的摸爬滚打坚持了。

• 不限制自己的人，会穷举各种方法来解决问题，限制自己的人，只会找各式各样的问题或借口。
• 不限制自己的人，会努力改变自己的问题和缺陷，限制自己的人，会放任自己。

另外几个故事

我还有另外几个故事（活到四十多，能看到好多人十几年的发展过程，感觉有点上帝视角了）

我还有一个以前团队里的一个小伙，人是很聪明，但就完全就是野路子，他对技术没有什么偏好，一个PHP程序员，做那个Discuz!论坛，公司被并购了，转成Java，开始研究Java的各种细节，对技术从来没有什么偏见，有什么就玩什么，每做一个项目，就算是一样的他都要用新的技术做一遍，然后跟着我做云计算，我教他TCP，教他C/C++，后来一起玩Docker/Go，等等，反正是一点就通，他是我见过学习能力最强的人。但是，有一个事他一直与我的想法不一样，就是我希望他先把软件设计好，再写代码，他非常不能理解，他习惯于直接动手开干，然后有什么问题就整什么问题，我也很难教育他。

有一天，他电话面了一下Facebook，电话面了15分钟后对方就放弃了，他受到了严重的打击。然后，他就开始找菲利宾人练英文口语了，我也让他做算法题，然后，他才发现，一道连算法都不是的纯编程题都提交几次都过不了，等他做完了Leetcode最初的那151道题后，整个人都改变了，写代码前认认真真地在纸上把程序的状态，处理时序以及可能遇到的一些条件先罗列出来，然后，进行逻辑设计后，再写，从此，他就开启他更大的天地了。我后来把他推荐给了微软，先在中国的Bing，在中国升好2-3级，然后去了美国的Azure，现在听说他准备要跟 k8s 的 co-founder Brendan Burns 混了（虽然，他现在还在印度人手下，但是，我真的不知道他未来能玩多大，因为今年他才33岁，而且非常聪明）

他以前是把自己封闭起来的，我叫他出来，他也不出来，后来因为一些办公室政治的原因不得不来找我，于是我就带着他玩了两年，跟他讲了很多外面的世界是怎么玩的，他这个人也是一个相当不善于社交的人，但是心是开放的，愿意接受新的东西，虽然对技术也有一定偏见，比如不喜欢Windows，但是也不会不喜欢到完全封闭。后来我跟他说，微软的技术相当的强的，你看到的技术只是表面，深层次的东西都是相通的，直到他到了微软后发现各种牛逼的东西，对微软系统的技术的态度也有了改变，而且我让他跟我说很多微软那边的事，我发现，他对技术了解的维度已经是越来越高级的了……

还是我以前团队的一个小伙，他是一个前端，他说前端的东西没什么意思，想来找我做后端，我也一点点带他……后来，我说，你如果想要玩得好，你必需来北京，无论现在你觉得过得有多好，你都要放弃掉，然后，尽最大可能出去经历一下世界最顶尖的公司，我甚至跟他说，如果他女朋友不跟来的话，就先分开一段时间，先自己立业，他来北京的时候，他之前的同事都等着看他的笑话，我说，那些人连想都不敢想，不必管他们。于是，他去了Amazon，再过了一年去了西雅图，我跟他说，接下来就是去AWS，然后，如果有足够的野心，用自己的年轻这个资本去硅谷创业公司赌一把……未来他怎么样我不知道，但至少他没有限制自己，他的未来不会有封顶……

也是我的同学，我跟他在大学是上下铺，后来他去了人民大学读计算机博士，大学的时候做国产数据库kingbase，然后去了一家外企，天天被派到用户那边做数据分析，后来，他想回科研单位做国产数据库，我说，别啊，你的技术比我好太多，还有博士理论加持，你不去国外顶尖公司玩玩，你不知道自己有多强的，于是他跟公司申请去了国外做核心，后来因为Hadoop的原因，公司的产品最终成为了历史，于是我说，你来了美国么，你一定要去AWS，于是他就去了AWS的Aurora团队，成为了AWS明星级产品的中坚力量，天天在改MySQL的核心源码，干了两年，正在晋升 Principal Software Engineer ……

这里我到不是说出国有多牛，也许你只关注能挣多少钱，但是我想说，他们之所以能有这样的际遇，除了他们本来就有实力，还更因为他们从来不给自己设制什么限制，就是那种“艺多不压身”，有什么就学什么，有更高的就去向更高的迈进，其它的像家庭什么的问题其实都是会有解的，真的不必担心太多……

 别限制了自己

上面的这些故事，也许你能看得懂，也许你看得不一定能懂，这里，让我来做个总结吧

• 做有价值的事。这个世界对计算机人才的要求是供不应求的，所以，不要让自己为自己找各式各样的借口，让自己活在“玩玩具”、“搬砖”和“使蛮力加班”的境地。其实，我发现这世界上有能力的人并不少，但是有品味的人的确很少。所谓的有价值，就是，别人愿付高价的，高技术门槛的，有创造力的，有颠覆性的……
• 扩大自己的眼界，开放自己的内心。人要变得开放，千万不要做一个狭隘的民族主义者，做一个开放的人，把目光放在全人类这个维度，不断地把自己融入到世界上，而不是把自己封闭起来，这里，你的英文语言能力对你能不能融入世界是起决定性的作用。开放自己的心态，正视自己的缺点，你才可能往前迈进。你的视野决定了你的知不知道要去哪，你的开放决定了你想不想去。
• 站在更高的维度。面的维度会超过点的维点，空间的维度会超过面的维度，在更高维度上思考和学习，你会获得更多。整天在焦虑那些低维度的事（比如自己的薪水、工作的地点、稳不稳定、有没有户口……），只会让你变得越来越平庸，只要你站在更高的维度（比如： 眼界有没有扩大、可能性是不是更多、竞争力是不是更强、能不能解决更大更难的问题、能创造多大的价值……），时间会让你明白那些低维度的东西全都不是事儿。技术学习上也一样，站在学习编程语法特性的维度和站在学习编程范式、设计模式的维度是两种完全不一样的学习方式。
• 精于计算得失。很多人其实不是很懂计算。绝大多数人都是在算计自己会失去多少，而不会算会得到多少。而一般的人也总是在算短期内会失去什么，优秀则总是会算我投入后未来会有什么样的回报，前者在算计今天，目光短浅，而后者则是舍在今天，得在明天，计算的是未来。精于计算得失的，就懂得什么是投资，不懂的只会投机。对于赚钱，你可以投机，但是对于自己最好还是投资。
• 勇于跳出传统的束缚。有时候，跳出传统并不是一件很容易的事，因为大多数人都会对未知有恐惧的心理。比如：我看到很多人才都被大公司垄断了，其实，有能力的人都不需要加入大公司，有能力的人是少数，这些少数的人应该是所有的公司share着用的，这样一来，对于所有的人都是利益最大化的。这样的事现在也有，比如：律师、设计师……。但是，绝大多数有能力的技术人员是不敢走出这步。我在2015年到2016年实践过一年半，有过这些实践，做“鸡”的比“二奶”好多了，收入也好很多很多（不好意思开车了）……

庄子说过几句话——

井蛙不可以语于海者，拘于虚也；//空间局限

夏虫不可以语于冰者，笃于时也；//时间局限

曲士不可以语于道者，束于教也。//认识局限

别自己墙了自己，人最可悲的就是自己限制自己，想都不敢想，共勉！

————————————————————

注：这篇文章就是要劝大家更为开放，让自己有更多的可能性，能到更高的层次，做更有价值的事，成为更强更好的人……当然，如果你觉得你只想做一个平凡人，也和本文并不冲突……另外你也不要觉得这篇文章是让你要成为一个精英，但你一定要去摸高……这篇文章是告诉你一种面对人生的思考方式，在这种思考方式下，你会有更多的可能性，更大的场景……而不是直接把自己归到“平常人”，把自己“墙”了！

注：我以为用Java适合做架构这事应该是常识了，但是评论中有很多人非常反对这个事。那我解释一下吧：首先，小型的项目用什么语言都行，爱用什么用什么。但是，真正的企业级架构就不一样了，其中并不仅仅只是RESTful API或RPC，还有各种配套设施和控制系统，比如：应用网关，服务发现、配置中心、健康检查、服务监控、服务治理（熔断、限流、幂等、重试、隔离、事务补偿）、Tracing监控、SOA/ESB、CQRS、EDA……这些东西在非Java的技术栈体系内，很难看到全貌，Java强大的生态环境，就是让你把注意力放到更高层次的架构和业务上来的。（千万不要觉得，整几个服务RPC一下，加个缓存，加个队列，就能叫架构，那只是系统集成罢了）

（全文完）

首先，要说的是Apollo 11导航的源代码，这些代码的设计负责人叫Margaret Heafield Hamilton ，是一个女程序员，专业是数学和哲学，1960年得到一个MIT麻省理工大学的临时的软件开发职位，负责在PDP-1和LGP-30上运行天气预报的软件（注：在计算机历史上，PDP系统机器被称为Hack文化的重要推手，PDP-11推了Unix操作系统，而Unix操作系统则是黑客文化的重要产品。参看《Unix传奇》）。然后，她又为美国空军编写探测知敌方飞行的软件，之后，于1965年的时候，她加入了MIT仪器实验室，并成为了这个实验室的主管，这个实验实就是Apollo计划的一部分，她负责编写全新的月球登录的导航软件，以及后来该软件在其他项目中的各个版本。

上图是Hamilton站在她和她的麻省理工团队为阿波罗项目制作的导航软件源代码旁边，在Github上的开源的代码 – Apollo-11 （2016年开源）。我们可以看到，有两个重要的目录，一个目录叫“Comanche055”，一个目录叫“Luminary099”，前者是指挥舱用的（英文为 Command Module ）后者为登月舱用的（英文为 Lunar Module），这里需要说明一下的是，指挥舱是把登录舱推到月球上，在返回的时候，登录舱是被抛弃掉的，而返回到地球的是指挥舱。如果你想看这两份源代码的纸版，你可以访问这两个链接：Comanche 55 AGC Program Listing 和 Luminary 99 REv.1 AGC Program Listing。其中的55 和 90 是各自的build 版本号。

我们细看一下，这些文件的日期是，1969年7月14日，而Apollo 11登月的日期是1969年7月16日起程，7月19日经过月球背面，7月20日下午8点登月。代码写好，两天后就直接上生产，然后就登月，还是导航代码，这代码写的的健壮性得有多强。

如果你仔细比较一下这两个目录中的文件，你会发现有些文件是一样的，不但文件名一样，而且内容也一样。这说明这两个模块中的一些东西是相似的。

这些代码应该是很难读了，因为当时写这些代码的时候，C语言都没有被发明，所以基本上来说都是汇编代码了，而且还可以发现，这些代码的源文件全是以agc后缀结尾的， 看来这还不是我们平时所了解的汇编，所谓的AGC代表了运行这些代码的计算机 – Apollo Guideance Computer 。沿着这个Wikipedia的链接，你可以看到AGC这个电脑的指令是什么样的，看懂那几条指令后，这些源代码也就能读懂了。当然，因为是写成汇编的，所以，读起来还是要费点神的。不过，其中有一个文件是 LUNAR_LANDING_GUIDANCE_EQUATIONS.agc 你会不会很好奇想去看看？

打开源文件，你还可以看到每个文件都有很多很多的注释，非常友好，但是也有一些注释比较有趣。这里有一组短视频带你读这些代码 – Exploring the Apollo Guidance Computer(AGC) Code，一供10个小视频，每个2分钟左右，如果你英文听边还行（我觉得很容易听懂），可以看看，了解一下AGC的工作方式，挺有趣意思的。

当时的AGC有32公斤，主频只有2MHz，2K的RAM，36K的ROM。嗯，当年就是这么一个小玩意，把人送上了月球，今天，一个聊天程序就占内存几GB……

下面是AGC在Apollo 1指挥舱里的样子（图片截自上面的视频），这个高质量的3D扫描来自 Simithsonian 3D: Apollo 11 Command Module （我觉得美国人干这些事干就是很漂亮啊，这种高清的3D扫描太牛了，如果你仔细看，这个舱里还有宇航员在舱壁上的手写）

这个AGC的操作界面又叫DSKY – Display 和 Keyboard的缩写，下图是一个 AGC 模拟器，其官方主页在 https://www.ibiblio.org/apollo/源代码在 Github/VirtualAGC。在这个界面上我们可以看到：下面的键盘上左边有两个键，一个是动词Verb一个是名词Noun，Verb指定操作类型，Noun指定要由Verb命令修改的数据。右边的显示器下面有三个5位的数字，这三个数值显示表示航天器姿态的矢量，以及所需速度变化的显示矢量。是的，当年的导航就靠这三个数字和里面的程序了。

如果你想了解AGC更多的细节，你可以看看 这篇 AGC for Dummies。这篇文章讲述了AGC这个嵌入式系统的背景和操作指令。一份详细的AGC 汇编语言手册可以让你了解更多的细节。

另外，我在Youtube上找到了一个讲当时Apollo电脑的纪录片 – Navigation Computer，太有趣了。比如：21分51秒开始讲存储用的 Rope Memory 绕线内存，Hamilton 也出来讲了一下在这种内存上编程，画面切到一个人用个比较长的金属针在一个像主板一样的东西上，左右穿梭，就像刺绣一样，但是绣的不是图案，而是程序……太硬核了，真正的通过“硬编织”的方式来写程序。

看完上面这个纪录篇，我是非常之惊叹，惊叹于50年前的工程能力，惊叹于50年前这些人面对技术的的一丝不苟，对技术的尊重和严谨的这种精神和方法，一点都不比较今天差。

不过，最牛的还不是这个，我在Hamilton的Wikipedia词条上找到了他说的一个事件—— 当年Apollo登陆雷达开关放在了错误的位置，导致AGC收到了不少错误的信号。结果就是AGC既得执行着陆必须的计算，又要接受这些占用其15%时间的额外数据。但是AGC的程序居然可以用高优先级的任务打断低优先级的任务，于是，AGC自动剔除了低级别的任务以保证了重要的任务完成。Hamilton 原话说—— 如果当时的程序不能识别错误并从错误中恢复，我怀疑阿波罗不能成功登月。if the computer hadn’t recognized this problem and taken recovery action, I doubt if Apollo 11 would have been the successful moon landing it was。

看到这里，你有没有觉得——“这个女程序员的一小步，是整个人类的一大步”？

Hamilton 的牛逼之外还在于，她是第一个将“软件工程”提出来的人，在MIT，她想让软件开发就像其它工程一样，有相应的工程纪律，给于相关的尊重，于是她创造了Software Engineering这个词。2018年，IEEE在纪念软件工程50周年的时候，他们把 Hamilton 请过去讲了一个叫 What the Errors Tell Us 的主题。她绝对可以称得上是程序员的Pioneer。

三年前，Apollo的源代码被开源时候，Twitter有个叫 Lin Clark 的人发了一条推：“我妈50年前的代码被放到Github上了”，虽然，她不是 Hamilton 的女儿，但她妈妈也是Apollo其中一个程序员，现在Lin Clark同样也是一个程序员，目前在 Mozilla工作，Staff Engineer，专长 WebAssembly, Rust, 和 JavaScript ，也是个非常厉害的程序，Youtube上各种演讲，也是一个跟他妈妈一样牛的人。

当她在Twitter上这么自豪地发了一条这样的推后，我不知道各位有什么想法？想不想你的后代在未来也会这样自豪的发条微博？

最后，尤其是想对那些到Apollo源代码的issue里发spam垃圾信息的人说一下，你看看人家，再看看你们自己，你们是不是想让你们的孩子在登月100周年纪念的时候说——50年前我爹那个傻叉在Apollo的github的issue列表时写了些垃圾，还以为自己多机灵？！

（全文完）

P.S. 这篇文章借鉴于《如何写出无法维护的代码》一文的风格……嘿嘿

相关技巧和最佳实践

要超过别人其实还是比较简单的，尤其在今天的中国，更是简单。因为，你只看看中国的互联网，你就会发现，他们基本上全部都是在消费大众，让大众变得更为地愚蠢和傻瓜。所以，在今天的中国，你基本上不用做什么，只需要不使用中国互联网，你就很自然地超过大多数人了。当然，如果你还想跟他们彻底拉开，甩他们几个身位，把别人打到底层，下面的这些“技巧”你要多多了解一下。

在信息获取上，你要不断地向大众鼓吹下面的这些事：

• 让大家都用百度搜索引擎查找信息，订阅微信公众号或是到知乎上学习知识……要做到这一步，你就需要把“百度一下”挂在嘴边，然后要经常在群或朋友圈中转发微信公众号的文章，并且转发知乎里的各种“如何看待……”这样的文章，让他们爱上八卦，爱上转发，爱上碎片。
• 让大家到微博或是知识星球上粉一些大咖，密切关注他们的言论和动向……是的，告诉大家，大咖的任何想法一言一行都可以在微博、朋友圈或是知识星球上获得，让大家相信，你的成长和大咖的见闻和闲扯非常有关系，你跟牛人在一个圈子里你也会变牛。
• 把今日头条和抖音这样的APP推荐给大家……你只需要让你有朋友成功地安装这两个APP，他们就会花大量的时间在上面，而不能自拔，要让他们安装其实还是很容易的，你要不信你就装一个试玩一会看看（嘿嘿嘿）。
• 让大家热爱八卦，八卦并不一定是明星的八卦，还可以是你身边的人，比如，公司的同事，自己的同学，职场见闻，社会热点，争议话题，……这些东西总有一些东西会让人心态有很多微妙的变化，甚至花大量的时间去搜索和阅读大量的观点，以及花大量时间与人辩论争论，这个过程会让人上瘾，让人欲罢不能，然而这些事却和自己没有半毛钱关系。你要做的事就是转发其中一些SB或是很极端的观点，造成大家的一睦讨论后，就早早离场……
• 利用爱国主义，让大家觉得不用学英文，不要出国，不要翻墙，咱们已经是强国了……这点其实还是很容易做到的，因为学习是比较逆人性的，所以，只要你鼓吹那些英文无用论，出国活得更惨，国家和民族都变得很强大，就算自己过得很底层，也有大国人民的感觉。

然后，在知识学习和技能训练上，让他们不得要领并产生幻觉

• 让他们混淆认识和知识，以为开阔认知就是学习，让他们有学习和成长的幻觉……
• 培养他们要学会使用碎片时间学习。等他们习惯利用碎片时间吃快餐后，他们就会失去精读一本书的耐性……
• 不断地给他们各种各样“有价值的学习资料”，让他们抓不住重点，成为一个微信公众号或电子书“收藏家”……
• 让他们看一些枯燥无味的基础知识和硬核知识，这样让他们只会用“死记硬背”的方式来学习，甚至直接让他们失去信心，直接放弃……
• 玩具手枪是易用的，重武器是难以操控的，多给他们一些玩具，这样他们就会对玩具玩地得心应手，觉得玩玩具就是自己的专业……
• 让他们喜欢直接得到答案的工作和学习方式，成为一个伸手党，从此学习再也不思考……
• 告诉他们东西做出来就好了，不要追求做漂亮，做优雅，这样他们就会慢慢地变成劳动密集型……
• 让他们觉得自己已经很努力了，剩下的就是运气，并说服他们去‘及时行乐’，然后再也找不到高阶和高效率学习的感觉……
• 让他们觉得“读完书”、“读过书”就行了，不需要对书中的东西进行思考，进行总结，或是实践，只要囫囵吞枣尽快读完就等同于学好了……

最后，在认知和格局上，彻底打垮他们，让他们变成韭菜。

• 让他们尽可能地用拼命和加班，尽可能的996，并告诉他们这就是通往成功的唯一路径。这样一来，他们必然会被永远困在低端成为最低的劳动力。
• 让他们不要看到大的形势，只看到眼前的一亩三分地，做好一个井底之蛙。其实这很简单，就是不要告诉他还有另外一种活法，不要扩大他的认识……
• 宣扬一夜暴富以及快速挣钱的案例，最好让他们进入“赌博类”或是“传销类”的地方，比如：股市、数字货币……要让他们相信各种财富神话，相信他们就是那个幸运儿，他们也可以成为巴菲特，可以成为马云……
• 告诉他们，一些看上去很难的事都是有捷径的，比如：21天就能学会机器学习，用区块链就能颠覆以及重构整个世界等等……
• 多跟他们讲一些小人物的励志的故事，这样让他们相信，不需要学习高级知识，不需要掌握高级技能，只需要用低等的知识和低级的技能，再加上持续不断拼命重复现有的工作，终有一天就会成功……
• 多让他们跟别人比较，人比人不会气死人，但是会让人变得浮躁，变得心急，变得焦虑，当一个人没有办法控制自己的情绪，没有办法让自己静下心来，人会失去耐性和坚持，开始好大喜欢功，开始装逼，开始歪门邪道剑走偏锋……
• 让他们到体制内的一些非常稳定的地方工作，这样他们拥有不思进取、怕承担责任、害怕犯错、喜欢偷懒、得过且过的素质……
• 让他们到体制外的那些喜欢拼命喜欢加班的地方工作，告诉他们爱拼才会赢，努力加班是一种福报，青春就是用来拼的，让他们喜欢上使蛮力的感觉……
• 告诉他们你的行业太累太辛苦，干不到30岁。让他们早点转行，不要耽误人生和青春……
• 当他们要做决定的时候，一定要让他们更多的关注自己会失去的东西，而不是会得到的东西。培养他们患得患失心态，让他们认识不到事物真正的价值，失去判断能力……（比如：让他们觉得跟对人拍领导的马屁忠于公司比自我的成长更有价值）
• 告诉他们，你现有的技能和知识不用更新，就能过好一辈子，新出来的东西没有生命力的……这样他们就会像我们再也不学习的父辈一样很快就会被时代所抛弃……
• 每个人都喜欢在一些自己做不到的事上找理由，这种能力不教就会，比如，事情太多没有时间，因为工作上没有用到，等等，你要做的就是帮他们为他们做不到的事找各种非常合理的理由，比如：没事的，一切都是最好的安排；你得不到的那个事没什么意思；你没有面好主要原因是那个面试官问的问题都是可以上网查得到的知识，而不没有问到你真正的能力上；这些东西学了不用很快会忘了，等有了环境再学也不迟……

最后友情提示一下，上述的这些“最佳实践”你要小心，是所谓，贩毒的人从来不吸毒，开赌场的人从来不赌博！所以，你要小心别自己也掉进去了！这就是“欲练神功，必先自宫”的道理。

相关原理和思维模型

对于上面的这些技巧还有很多很多，你自己也可以发明或是找到很多。所以，我来讲讲这其中的一些原理。

一般来说，超过别人一般来说就是两个维度：

1. 在认知、知识和技能上。这是一个人赖以立足社会的能力（参看《程序员的荒谬之言还是至理名言？》和《21天教你学会C++》）
2. 在领导力上。所谓领导力就是你跑在别人前面，你得要有比别人更好的能力更高的标准（参看《技术人员发展之路》）

首先，我们要明白，人的技能是从认识开始，然后通过学校、培训或是书本把“零碎的认知”转换成“系统的知识”，而有要把知识转换成技能，就需要训练和实践，这样才能完成从：认识 -> 知识 -> 技能 的转换。这个转换过程是需要耗费很多时间和精力的，而且其中还需要有强大的学习能力和动手能力，这条路径上有很多的“关卡”，每道关卡都会过滤掉一大部分人。比如：对于一些比较枯燥的硬核知识来说，90%的人基本上就倒下来，不是因为他们没有智商，而是他们没有耐心。

认知

要在认知上超过别人，就要在下面几个方面上做足功夫：

1）信息渠道。试想如果别人的信息源没有你的好，那么，这些看不见信息源的人，只能接触得到二手信息甚至三手信息，只能获得被别人解读过的信息，这些信息被三传两递后必定会有错误和失真，甚至会被传递信息的中间人hack其中的信息（也就是“中间人攻击”），而这些找不出信息源的人，只能“被人喂养”，于是，他们最终会被困在信息的底层，永世不得翻身。（比如：学习C语言，放着原作者K&R的不用，硬要用错误百出谭浩强的书，能有什么好呢？）

2）信息质量。信息质量主要表现在两个方面，一个是信息中的燥音，另一个是信息中的质量等级，我们都知道，在大数据处理中有一句名言，叫 garbage in garbage out，你天天看的都是垃圾，你的思想和认识也只有垃圾。所以，如果你的信息质量并不好的话，你的认知也不会好，而且你还要花大量的时间来进行有价值信息的挖掘和处理。

3）信息密度。优质的信息，密度一般都很大，因为这种信息会逼着你去干这么几件事，a）搜索并学习其关联的知识，b）沉思和反省，c）亲手去推理、验证和实践……一般来说，经验性的文章会比知识性的文章会更有这样的功效。比如，类似于像 Effiective C++/Java，设计模式，Unix编程艺术，算法导论等等这样的书就是属于这种密度很大的书，而像Netflix的官方blog和AWS CTO的blog等等地方也会经常有一些这样的文章。

知识

要在知识上超过别人，你就需要在下面几个方面上做足功夫：

1）知识树（图）。任何知识，只在点上学习不够的，需要在面上学习，这叫系统地学习，这需要我们去总结并归纳知识树或知识图，一个知识面会有多个知识板块组成，一个板块又有各种知识点，一个知识点会导出另外的知识点，各种知识点又会交叉和依赖起来，学习就是要系统地学习整个知识树（图）。而我们都知道，对于一棵树来说，“根基”是非常重要的，所以，学好基础知识也是非常重要的，对于一个陌生的地方，有一份地图是非常重要的，没有地图的你只会乱窜，只会迷路、练路、走冤枉路！

2）知识缘由。任何知识都是有缘由的，了解一个知识的来龙去脉和前世今生，会让你对这个知识有非常强的掌握，而不再只是靠记忆去学习。靠记忆去学习是一件非常糟糕的事。而对于一些操作性的知识（不需要了解由来的），我把其叫操作知识，就像一些函数库一样，这样的知识只要学会查文档就好了。能够知其然，知其所以然的人自然会比识知识到表皮的人段位要高很多。

3）方法套路。学习不是为了找到答案，而是找到方法。就像数学一样，你学的是方法，是解题思路，是套路，会用方程式解题的和不会用方程式解题的在解题效率上不可比较，而在微积分面前，其它的解题方法都变成了渣渣。你可以看到，掌握高级方法的人比别人的优势有多大，学习的目的就是为了掌握更为高级的方法和解题思路。

技能

要在技能上超过别人，你就需要在下面几个方面做足功夫：

1）精益求精。如果你想拥有专业的技能，你要做不仅仅是拼命地重复一遍又一遍的训练，而是在每一次重复训练时你都要找到更好的方法，总结经验，让新的一遍能够更好，更漂亮，更有效率，否则，用相同的方法重复，那你只不过在搬砖罢了。

2）让自己犯错。犯错是有利于成长的，这是因为出错会让人反思，反思更好的方法，反思更完美的方案，总结教训，寻求更好更完美的过程，是技能升级的最好的方式。尤其是当你在出错后，被人鄙视，被人嘲笑后，你会有更大的动力提升自己，这样的动力才是进步的源动力。当然，千万不要同一个错误重复地犯！

3）找高手切磋。下过棋，打个球的人都知道，你要想提升自己的技艺，你必需找高手切磋，在和高手切磋的过程中你会感受到高手的技能和方法，有时候你会情不自禁地哇地一下，我靠，还可以这么玩！

领导力

最后一个是领导力，要有领导力或是影响力这个事并不容易，这跟你的野心有多大，好胜心有多强 ，你愿意付出多少很有关系，因为一个人的领导力跟他的标准很有关系，因为有领导力的人的标准比绝大多数人都要高。

1）识别自己的特长和天赋。首先，每个人DNA都可能或多或少都会有一些比大多数人NB的东西（当然，也可能没有），如果你有了，那么在你过去的人生中就一定会表现出来了，就是那种大家遇到这个事会来请教你的寻求你帮助的现象。那种，别人要非常努力，而且毫不费劲的事。一旦你有了这样的特长或天赋，那你就要大力地扩大你的领先优势，千万不要进到那些会限制你优势的地方。你是一条鱼，你就一定要把别人拉到水里来玩，绝对不要去陆地上跟别人拼，不断地在自己的特长和天赋上扩大自己的领先优势，彻底一骑绝尘。

2）识别自己的兴趣和事业。没有天赋也没有问题，还有兴趣点，都说兴趣是最好的老师，当年，Linus就是在学校里对minx着迷了，于是整出个Linux来，这就是兴趣驱动出的东西，一般来说，兴趣驱动的事总是会比那些被动驱动的更好。但是，这里我想说明一下什么叫“真∙兴趣”，真正的兴趣不是那种三天热度的东西，而是那种，你愿意为之付出一辈子的事，是那种无论有多大困难有多难受你都要死磕的事，这才是“真∙兴趣”，这也就是你的“野心”和“好胜心”所在，其实上升到了你的事业。相信我，绝大多数人只有职业而没有事业的。

3）建立高级的习惯和方法。没有天赋没有野心，也还是可以跟别人拼习惯拼方法的，只要你有一些比较好的习惯和方法，那么你一样可以超过大多数人。对此，在习惯上你要做到比较大多数人更自律，更有计划性，更有目标性，比如，每年学习一门新的语言或技术，并可以参与相关的顶级开源项目，每个月训练一个类算法，掌握一种算法，每周阅读一篇英文论文，并把阅读笔记整理出来……自律的是非常可怕的。除此之外，你还需要在方法上超过别人，你需要满世界的找各种高级的方法，其中包括，思考的方法，学习的方法、时间管理的方法、沟通的方法这类软实力的，还有，解决问题的方法（trouble shooting 和 problem solving），设计的方法，工程的方法，代码的方法等等硬实力的，一开始照猫画虎，时间长了就可能会自己发明或推导新的方法。

4）勤奋努力执着坚持。如果上面三件事你都没有也没有能力，那还有最后一件事了，那就是勤奋努力了，就是所谓的“一万小时定律”了（参看《21天教你学会C++》中的十年学编程一节），我见过很多不聪明的人，悟性也不够（比如我就是一个），别人学一个东西，一个月就好了，而我需要1年甚至更长，但是很多东西都是死的，只要肯花时间就有一天你会搞懂的，耐不住我坚持十年二十年，聪明的人发明个飞机飞过去了，笨一点的人愚公移山也过得去，因为更多的人是懒人，我不用拼过聪明人，我只用拼过那些懒人就好了。

好了，就这么多，如果哪天你变得消极和不自信，你要来读读我的这篇文章，子曰：温故而知新。

（全文完）

首先，我们先来看一下之份报告的 Key Results：

• Python 成为了过去一年中成长最快的语言，把Java挤到了第二位，排在后面的是Rust语言。
• 有半数以上的被访者在是在16岁写下自己的第一行代码。
• DevOps Specialists 和 Site Reliability Engineers 是程序员中最有经验，技术最牛，薪资最好的职位。（这对应于国内的——系统架构师）
• 在几个头部的程序员大国中，中国的程序员最乐观的，他们相信在今天出生的人会有比他们父母更好的人生。对于欧洲的程序员来说，比较法国和德国的程序员，他们对未来并不太乐观。
• 对于最影响程序员生产力的事，不同的程序员有不同的想法。

第一部分，Developer Profile

在第一部分中，我们可以看到，中国程序员参与这个调查的并不多，程序员主要集中在美国、欧洲、印度这三个地方。所以，这份报告更偏国际上一些。这对于我们中国程序员也有很大的帮助，因为一方面可以看到世界发展的趋势，另一方面也可以了解我们和世界有什么不一样。

对于技术职业来说，整个世界的程序员开始趋于全栈和后端，有51.9%的人是全栈，50%的人是后端，32.8%的人是前端……在这些人中，很多程序员都选了多项，中位数是3项，最常见是前端、后端和全栈全选的。然后，接下来是选两项的，选两项目的包括：数据库管理员和系统管理员，DevOps Specialist 和 Site Reliablility Engineer， 学术研究者和科学家，设计师和前端工程师。

从这些数据中我们可以看见：前后端的界限越来越不明显，设计师和前端的界限也开始模糊。这应该说明，工具和框架的成熟，让后端程序员和设计师也可以进入到前端工程师的领域，或是前端工程师开始进入后端和设计的领域。总之，复合型人才越来越越成为主流，而前后端也趋于一个相互融合的态势。

在接下来的图表中，我们可以看到有80%以上的人是把编程当成自己的爱好（包括相关的女性）。

真是应了那句话——“Programmers who don’t code in their spare time for fun will never become as good as those that do”，是的，如果你对编程没有感到一种快乐，没有在你空闲的时候去以一种的兴趣爱好方式去面对，那么，无论是编程，还是运动，还是去旅游，都不会有太多成效的。

在接下来的编程经验上，有两组如下的数据：

学习编程的年限	编程的年限

我们可以看到无论是学习还是编程，随着时间的拉长，其人数占比越来越少。

下面我们再来看一个年龄图：

调查报告从20岁开始每隔5年划分一个年龄段，我们不难发现从25-29岁开始每个年龄段都比前一个年龄段人数急剧减少大约30-50%，比如25-29年龄段占总人数27.6%，而30-34则只有19.3%。以此类推，到60岁以上，就只剩1%。可以看出5年是大多数程序员的转型周期。这是合理的，因为5年时间足够一个人积累足够的经验技能为职业转型做准备。

我们也可以看到50岁以上的程序员只有4.2%，大约是参与调查人员的300多人，如果这些人20岁左右参加工作，那么说明他们在1990左右就开始写代码，事实上那个时间点别说是程序员了，连电脑用户都不多。电脑和互联网真正暴发的时间还是在1995年 – 2000年之间，不过，那个时间点程序员的总体人数也不多，而行业越来越火才会导致大量的人进入到这个行业中，这个转换过程基本上去需要3-5年，也就是从2000年后才开始有大量的人拥入程序员这个行业，程序员的人数在过去30年间也是呈增涨态势的，所以，我个人认为，所谓的“众多老程序员”的比例会被2005年以后大量拥入程序员行业的年青人所“稀释”。所以，上图的比例不能完全说明程序员是个青春饭。

但是，我们还是要正视老牌资深的程序员越来越少的这个事实，在这份报告第三部分中说了一些和程序员职业生涯相关的调查，如下：

• 在被问到有多少人对自己的职业满意的时。有40%的人觉得很满意，而有34.3%的人觉得一般满意，有10%的人说不清，还有15%的人是不满意的。可以看到有不少人是对这个职业生涯是有想法的。
• 在被问到有多少人想转管理而可以挣得更多时。有30%的人是说想转的，有51%的人是明确不转的，还有20%的人是说不知道。可见，想转管理的人最多可能会有一半的人。
• 在被问到有多少人想转管理时。有1/3的人是明确不想转的，而有1/4的人是明确是想转，而有36%的人则是不说，观望中。可见，的确是有很多想想转管理的。

我们可以看到，程序员中并不是所有的人都是可以坚持这么长时间的，这也挺正常的，对很大一部分人来说，对这个职业是有或多或少的不满意的，也有一部分人可能会随着技术的更新被淘汰，还有另外很大一部分人是想转管理的。所以，能够长时间地跟上形势长时间地喜欢写代码，并且对程序员这个的职业长期满意，不想转管理的，的确是为随时年龄的越大也越来越少。

但我们完全可以看出来，程序员的主力军在20-40岁这个区间，而30岁左右的程序员是年富力强（经验和能力都很好）的黄金时间。

老程序员在国外似乎不会存在多大的问题，但在国内会有一些问题，所以，对于像我一样喜欢写代码、打算长久做程序员的兄弟，这里分享一些相关的经验。

1. 持续高效地学习。软件行业的新技术层出不穷，旧的技术淘汰很快，所以我们更要多多学习基础技术和原理，那些都是很难改变的，并且基础扎实了后，学习新的技术也才会更快速。其间我们也不要乱学新技术，我们要关注那些有潜力的技术，也就看准了再学（参看酷壳的《Go语言、Docker和新技术》）。注意，而是跟上大时代已经比较不容易，引领时代的人还是少数，所以，还是要更为高效地学习。
2. 积极面对他人的不解。 很多时候，总是会有人说：“到了你这个年纪怎么还在做程序员？”，这句话感觉就是对程序员这个职业的一种羞辱，社会的价值观感觉容不下大龄程序员。这个时候，我一般会跟他们解释到，我40来岁了，我觉得自己的状态还很好，工作完成没什么问题，偶尔加班到凌晨也行，新知识和技术我学起来不比年轻人慢，我在这个年纪有的经验比他们都多，而且，我这个年纪还在写代码，说明我真的喜欢这个事，像我这样的人能够长时间坚持做一个职业的人这个世界已经不多了，你们应该珍惜……
3. 找到自己的定位。我们需要做好职业规划、财务和心理方面的准备。40岁的程序员，所能竞争的一定是自己的认识和经验，所以，40岁以后如果你还是很喜欢这一行业，你的社会阅历和经历以及对这个社会的理解，可以让你做一些有创新的事，除此之外，你还可以做一个教练、老师、咨询、专家……，用你的经验和能力帮助下一代和一些中小型的公司，这不但是他们的刚需，同时也会让重新焕发的。

第二部分，技术

首先，在这部分，主要是了解一些技术，这部分的技术可以给于程序员们一些指导。

最流行的语言	最热门的语言

我们可以看到，

• Javascript/HTML/CSS是很多人都会用到的，后面的是SQL，这个也没什么问题，无论前后端的人，或多或少都会要用到的，这些技术感觉已经成为了基础必会的技术了，就像数中的加减乘除一样。
• Python/Java/Shell 是后端开发主流语言的前三强，Python在今年超过了Java。这里让我比较好奇的是居然还有很多人用Shell，这估计跟运维有关，所以，Python的热可能也是通过运维和大数据相关。
• 流行语言后，第二梯队的是 C# / PHP / C++ / TypeScript / C ，接下来的是： Ruby / Go / Swift / Kotlin /WebAssembly / Rust… 。但在最被程序员喜欢的编程语言中：Rust / Python / TypeScript / Koltin / WebAssembly / Swift / Go… 都是排在前几名的。程序语言每隔一段时间就会整出一些新的语言来，我们一定要明白新出来的东西主要是为了解决什么样的问题，不然很容易迷失。
• 在后面还有一个编程语言的薪资图，我们可以看到，在上面被提过的这些个编程语言中，Go语言的薪资是最高的（这可能是因为Go语言写关键的系统级的中件间——因为Go语言正在成为云计算的第一编程语言），然后是Scala、Ruby、WebAssembly、Rust、Erlang、Shell、Python、Typescript……

通过这些个信息，我们可以看出主流技术、有潜力的技术，传统过气技术，以及相关薪资，对我们在选择编程语言上有一定的启示。

在后面，我们可以看到:

• 在 Web 开发框架上，主流使用还是 jQuery, React.js，Angular.js 为最前面的三个前端开发框架。而被程序员所喜欢的则是 React.js，Vue.js，Express, Spring，程序员非常不喜欢 Drupal，jQuery，Ruby on Rails 和Angular.js……
• 在其它开发框架/库/工具上，主流是Node.js、.NET、Pandas、Unity 3D、Tensorflow、Ansible、Cordova、Xamarin……而程序员比较喜欢的是.NET、Torch/PyTorch、Flutter、Pandas、Tensorflow、Node.js …
• 在操作系统上，主流使用Linux、Windows、Docker、Android、AWS……，而程序员最喜欢的是Linux、Docker、Kubernetes、Raspberry Pi、AWS、MacOS、iOS……
• 在数据库上，MySQL、PostgreSQL、MSSQL、SQLite、MongoDB、Redis、Elasticsearch是比较主流的，而程序员非常喜欢的是，Redis、PostgreSQL、Elasticsearch、Firebase、MongoDB……，程序员比较讨厌的是 Couchbase、Oracle、Cassandra、MySQL。

从这些个图表中，我们可以看到主流和有潜力的技术是什么，我们可以看到 Windows 的技术并没有过时，感觉似乎都有可能会卷土重来，但是，开源的技术来势凶凶，正在吞食整个软件业，不容小觑，Docker/Kubernetes无论是在主流应用上还是被程序员的喜好上都是非常猛的，而云平台的AWS开始成为标准平台技术……

接下来的开发工具中，我们可以看到：

• Visual Studio Code 成为了最流行的开发工具。让我没有想到的是跟在后面的是 Notepad++（好久没用这个工具了，我得找回来用用了），而IntelliJ、Vim、Sublime Text排以后面。 Eclipse 和 Atom 动力不足，Emacs 开始变得小众了。
• 程序员主要的开发平台还是Windows占了近1/2， MacOS和Linux随后，各占1/4。
• 有38%的人使用容器技术做开发，30%的人使用容器做测试，在生产线上使用容器的有26%

看样子编程开发工具还是Visual Studio 和 IntelliJ的天下，MacOS/Linux正在抢Windows的开发市场

接下来，StackOverflow给了一个技术圈的图

从上面这个图中，我们可以看以技术的几圈子：

• Microsoft圈 – Windows、.NET、ASP.NET、C#、Azure、SQL Server
• Java圈 – Java、Spring
• 手机圈 – Android、 iOS、Kotlin、Swift、Firebase
• 前端圈 – Javascript、React.js、Angular.js、PHP
• 大数据圈 – Python、TensorFlow、Torch/PyTorch
• 基础平台圈 – Linux、Shell、Vim、Docker、Kubernetes、Elasticsearch、Redis……
• 其它圈子 – C/C++/汇编圈子、Ruby圈子、Hadoop/Spark圈子、……

看到谁的圈子大了吧，圈子大的并不代表技术实力强或是有前途，不过可以代表在那个圈子相关的关联技术，一方面，可以给你一些相关的参考，另一方面，整体可以让你看到全部的目前比较主流的技术。

第三部份 工作

在第三部份工作中，我们可以看到如下的一些数据：

• 有3/4的程序员是全职的，10%左右的程序员是自由职业，6%左右的程序员是失业的，这个比例在北美、印度和欧洲都差不多。
• 有1/3的人在过去一年内换过工作，1/4的人在过去1-2年间换过工作，1/3的人在2-4年换过工作。
• 程序员找工作时，影响程序员的几个主要因素是：技术（编程语言、框架和使用的技术）、办公环境和公司文化、灵活的时间和安排、更专业的机会、远程工作……
• 影响程序员工作的几大因素是：有干扰的工作环境、开会、要干一些和开发无关的事、人手不够、管理不够、工具不够、通勤时间……
• 对于工程质量，有近70%的人有Code Review，而30%的则没有；有60%多的人有Unit Test，而不到40%的没有……

从工作中我们可以看到，程序员还是比较关心技术和公司文化的，换工作也是这个职业很正常的特性，他们并不喜欢被打扰，希望有足够的时间，而对于工程质量还是很有追求的。

最后用一张程序员的“每周工作时间” 来结束本文！

祝大家快乐！

（全文完）

所以对此，我是有点看不懂的，看不懂的是，为什么这么一群聪明的人，放着明亮宽敞的办公桌不用，硬要挤在一个又窄又小又吵又热的小空间里工作，而且要这么透支地写那么重要的很关键的系统级的代码……这就好像，一架在一个小作坊里被人加班加点赶工出来的飞机，谁敢坐啊？！老实说，这群工程师真是很优秀的工程师，他们完全是可以做得更好的……但是却做出了如此蹩脚和糟糕的系统……他们说，这样坐在一起可以做到快速沟通，然而，我觉得这恰恰是一种没有章法的表现。

也是在这家公司，在这个项目烂尾一年前，公司感到了危机，CEO号召全体996，举全公司之力从董事长到下面基层员工对抗外部所谓的威胁，有的部门为了表现，甚至997，然而，在一年后，做出了一个烂得不能再烂的软件，最终以失败告终，很多人包括CEO也因此下课……

这是最让我看不懂的一个事了，为什么这么如此成功的公司的高级管理层会做出这样的事情，而且还制定这样的政策……把这么优秀的员工以及公司大把把数以亿计的钞票投入到这种错误的路线上来，而且还拼命地加班…… 他们脑子里在想什么呢？难道他们真的以为，有足够多的钱，足够多的人，然后拼命加班，就能打败对手吗？……

你喜欢这句话吗？

“努力就会成功”，“加班就会有成就”，“勤劳就会致富”……是这样吗？仔细思考一些，这些话存在严重的逻辑问题，我们在高中的时候学过“充分条件”，“必要条件”和“充要条件”！“努力就会成功”这句话，把“努力”说成了“成功”的充要条件，这不就是错的吗？努力只是成功的必要条件之一。你在错误的方向或是格局很小的方向上努力，能有用么？你努力地要饭，你努力地当搬运工，你努力地打骚扰电话销卖保险…… 在错误和小格局的方向上努力，你还觉得努力还有用吗？

但是很多人是很喜欢“努力就会成功”这句话，这类人也很喜欢看很多小人物通过自己的努力变成成功人士的励志的故事，为什么这种故事会被很多人喜欢甚至感动。因为这很符合大众的心理诉求，这种诉求其实就是一种只要使力只要拼命了就可以成功的心理诉求，因为这类人基本上都是能力有限，不知道怎么提升自己的人，当他们看到只要拼命使力就可以成功的观点时，他们就会有共鸣，就会感到，不用学习那些晦涩难懂高级的知识，不用掌握和练习哪些高级技能，自己只需要在低级的事情上拼命和努力，加更多的班和干更多活，自己就会像电影中的那些小人物一样，总有一天会成功的……

“努力就会成功，勤劳就会致富”，不但符合那些低级管理者的利益诉求，同样符合那些能力不足不愿意学习和成长的人的诉求。因为，他们混淆了行动与进展，忙碌与多产，他们以为能靠蛮力可以弥补思维上的惰性，靠拼命可以弥补能力上的不足……

喜欢或认同这句话的人基本是能力上有问题的人，这类适合做劳动密集型的事。不信你可以试试看，当一件事的难度超过一定程度的时候，那些聪明的人会找到更省力的方法，而能力上有问题的，还是在那使蛮力。

我成长的过程

回想我的过去，我在2001年那年被外包到了某银行做开发，标准的9/10/6，封闭开发，就是用C语言在AIX系统里堆一些银行的交易逻辑，老实说，这个过程并没有让我学到什么东西，也没有什么成长，我每天想的就是我要离开这个地方，所以，我在晚上10点以后开始看书学习到11点半，并使用工作环境动手实践书上的代码，一年后，我精读了《TCP/IP详解》《Windows核心编程》《Java编程思想》等书。然后，我找到一份外企业的工作，月薪一下翻了三倍。

在外企不加班，但是当时的外企压力也很大，对代码的质量要求的也很高，来的第二个月，就因为代码写的太差，差点被开掉，所以，为了能够达到更高的标准，我自然也是很努力的，在周末甚至黄金周节假日我哪里都不去，我就去公司，但我不是在公司上班，因为我没有自己的电脑，所以，我只能蹭公司的电脑，这导致办公楼的管理人员经常打电话给我让我帮他在周末的时候管理物业…… 在这家公司是我成长最快的时候，然而，并不是因为我的努力，而是因为有很多比我牛逼的人在Code Review上给我大量的帮助，在项目上帮助我，我的努力学习虽然也有作用，但更多的是高手对我的帮助。

再回想一下我以前在职场上的很多关键点，不是因为我加班了，而是因为在某些关键问题上，我跳出来解决了其它人都解决不了的问题，我解决了一个网络通信莫名其妙的断掉的问题，我把性能优化了很多倍，我解决了一个不能重现的一个困扰团队3个星期的问题（其实就是大家没有认真读文档），我在入职一个公司的第一天里就为这个公司解决了一个历史遗留问题……在Platform，我每周解决了bug数是全公司的其它人的总和还要多（从不加班），在路透，我带团队优化的系统的性能是全球所有研发中心最高的，在亚马逊，两周打通美国和德国的订单和商品列表系统……我也有失败的时候，而我失败的时候，总是因为我搞不定事，即便是加班拼命努力也无济于事！是的，我的职业生涯的成长，最根本的不是你有多努力，有多勤奋，而是你能搞定很多人搞不定的事！

你不信你可以看看你们公司那些不用加班，就算什么也不干，公司也要花钱养的技术人员，他们的成功一定不是努力和加班加出来的，你会发现这些人拼的不是谁干的多，而是谁解决的问题更有难。

我加班996的时候，从来都不是我成长最快的时候，而我和一群牛人在解决难题的时才是我成长最快的时候。

Work Smart

2015年因为父亲病危要动手术，所以我不能工作在家照顾父亲。于是我就成为了一个自由职业者，帮很多公司解决一些技术问题，好多都是高并发和系统稳定性的问题，有一些是分布式架构的运维的问题，还有一些是工程管理和企业文化问题……有一些小公司的单体架构在业务上一推广就宕机了，于是把我叫过去，我在生产线上直接re-arch，用一些非常规的手段，1-2天就把性能救过来了…… 还有就是解决一些点状的技术问题，还帮用户做一些design/code review……，有70%工作是真正的按劳取酬，也就是先把问题解决了再谈要收多少钱，那段时间我出卖的不是我的劳动力，而是我的技能，所以，反而比打工挣得多多了，而且还比较轻闲……

有时候，我还调侃到，你在大公司里一天写上万行代码，拼命地加班，你信不信，我只用写几百行代码就挣得比你多？同样是一个简单的 for-loop 语句，有人写的就值1万元一行，而你写的则一文不值。关键不在于谁写的代码多，关键在于我们解决了什么样的问题。你千万不要以为只要付你足够的钱，你就可以996，让你干什么都可以，然而当你自己把自己当成劳动力的时候，你也就只是一个像牲口一样的行事了！

这就好像算法一样，你那个O(n^2)的递归穷举算法，再怎么样也干不过我的O(n)的动态规划的算法。

现在我拿了投资在创业，一开始帮助各大企业建高并发高可用云化架构的公司，现在还给企业提供金融和营销能力，我跟客户谈业务的时候，基本不是因为我有多加班多努力地做方案，而是我能一针见血地指出用户的问题，帮用户解决问题。我在很多地方都见到阿里、蚂蚁、华为、HP……，一个小创业公司跟他们竞争真的很难，但我知道，要能竞争过这些大公司，这根本就不是能够通过加班996或是拼命努力就能搞定的，我必需要使用更好的方式，所以，除了更好地站在用户的立场，能够给用户制定更符合用户的技术方案之外，我必需做到我的技术方案不比这些大公司的差，而这一点，完全不是加班、努力或是勤奋能出来的，这是需要靠自己的经验、学习能力、归纳思考、和与更多牛人交流才出的来的……当我给某银行CIO介绍完我的分布式系统的方案后，CIO给我微微鞠躬说：“过去一两年，我听过几乎所有国内外产商跟我讲的分布式的方案，你的是我听过的最好的方案！谢谢你！”，当我给某省电信行业公司讲了一下DevOps的方案后，老总对我说：“你们真的是做事的人！”，当用户来问我：“你们的API网关是怎么写的？为什么运行的这么稳定？”……这些话都是让我很心里很暖的话……当然，我也有被骂的时候，也有失败的时候，但基本上来说，我无法通过努力工作改善我思维的不足……

我们学计算机当程序员最大的福气不是可以到大公司里加班和996，而是我们生活在了第三次工业革命的信息化时代，这才是最大的福气，所以，我们应该努力地提升自己，而不是把自己当劳动力一样的卖了！在这样的一个时代，你要做的不是通过加班和拼命来跪着挣钱，而是通过技能来躺着挣钱……

（全文完）

注：本文由雷俊(Javaer/Emacser)和我一起编辑，所以文章版权归雷俊与我共同所有，转载者必需注明出处和我们两位作者。原文最早发于酷壳微信公众号，后来我又做了一些修改，再发到博客这边。

程序员是一个很懒的群体，总想着能够让代码为自己干活，他们不断地把工作生活中的一些事情用代码自动化了，从而让整个社会的效率运作地越来越高。所以，程序员在准备去优化这个世界的时候，都会先要优化自己的工作环境，是所谓“工欲善其事，必先利其器”。

我们每个程序员都应该打造一套让自己更为高效的工作环境。那怕就是让你少输入一次命令，少按一次键，少在鼠标和键盘间切换一次，都会让程序员的工作变得更为的高效。所以，程序员一般需要一台性能比较好，不会因为开了太多的网页或程序就卡得不行的电脑，还要配备多个显示器，一个显示器写代码，一个查文档，一个测试运行结果，而不必在各种窗口来来回回的切换……在大量的窗口间切换经常会迷路，而且也容易出错（分不清线上或测试环境）……

除了硬件上的装备，软件上也是能够提升程序员生产力的地方，在软件层面提升程序员生产力的东西有一个很重要的事就是命令行和脚本，使用鼠标和图形界面则会大大降低程序员的生产力。酷壳以前也写过一些，如《你可能不知道的Shell》和《 应该知道的Linux技巧》，但是Unix/Linux Shell就是一个大宝库，怎么写也写不完，不然，怎么会有“Where is the Shell, there is a way”。

命令行

在不同的操作系统下，都有着很不错的命令行工具，比如 Mac 下的 Iterm2，Linux 下的原生命令行，如果你是在 Windows 下工作，问题也不大，因为 Windows 下现在有了 WSL。WSL 提供了一个由微软开发的Linux兼容的内核接口（不包含Linux内核代码），然后可以在其上运行GNU用户空间，例如 Ubuntu，openSUSE，SUSE Linux Enterprise Server，Debian和Kali Linux。这样的用户空间可能包含 Bash shell 和命令语言，使用本机 GNU/Linux 命令行工具（sed，awk 等），编程语言解释器（Ruby，Python 等），甚至是图形应用程序（使用主机端的X窗口系统）。

使用命令行可以完成所有日常的操作，新建文件夹（mkdir）、新建文件（touch）、移动（mv）、复制（cp）、删除（rm）等等。而且使用 Linux/Unix 命令行最好的方式是可以用 awk、sed、grep、xargs、find、sort 等等这样的命令，然后用管道把其串起来，就可以完成一个你想要的功能，尤其是一些简单的数据统计功能。这是Linux命令行不可比拟的优势。比如：

• 查看连接你服务器 top10 用户端的 IP 地址：

netstat -nat | awk '{print $5}' | awk -F ':' '{print $1}' | sort | uniq -c | sort -rn | head -n 10

• 查看一下你最常用的10个命令：

cat .bash_history | sort | uniq -c | sort -rn | head -n 10 (or cat .zhistory | sort | uniq -c | sort -rn | head -n 10

（注：awk 和 sed 是两大神器，所以，我以前的也有两篇文章来介绍它们——《awk简明教程》和《sed简明教程》，你可以前往一读）

在命令行中使用 alias 可以将使用频率很高命令或者比较复杂的命令合并成一个命令，或者修改原生的命令。

下面这几个命令，可能是你天天都在敲的。所以，你应该设置成 alias 来提高效率

alias nis="npm install --save "
alias svim='sudo vim'
alias mkcd='foo(){ mkdir -p "$1"; cd "$1" }; foo '
alias install='sudo apt get install'
alias update='sudo apt-get update; sudo apt-get upgrade'
alias ..="cd .."
alias ...="cd ..; cd .."
alias www='python -m SimpleHTTPServer 8000'
alias sock5='ssh -D 8080 -q -C -N -f user@your.server'

你还可以参考如下的一些文章，看看别人是怎么用好 alias 的

• 30 Handy Bash Shell Aliases For Linux / Unix / Mac OS X
• What are your favorite bash aliases?
• 23 Handy Bash Shell Aliases For Unix, Linux, and Mac OS X
• A few more of my favorite Bash aliases

命令行中除了原生的命令之外，还有很多可以提升使用体验的工具。下面罗列一些很不错的命令，把原生的命令增强地很厉害:

• fasd 增强了 cd 命令 。
• bat 增强了 cat 命令 。如果你想要有语法高亮的 cat，可以试试 ccat 命令。
• exa 增强了 ls 命令，如果你需要在很多目录上浏览各种文件 ，ranger 命令可以比 cd 和 cat 更有效率，甚至可以在你的终端预览图片。
• fd 是一个比 find 更简单更快的命令，他还会自动地忽略掉一些你配置在 .gitignore 中的文件，以及 .git 下的文件。
• fzf 会是一个很好用的文件搜索神器，其主要是搜索当前目录以下的文件，还可以使用 fzf --preview 'cat {}'边搜索文件边浏览内容。
• grep 是一个上古神器，然而，ack、ag 和 rg 是更好的grep，和上面的 fd一样，在递归目录匹配的时候，会使用你配置在 .gitignore 中的规则。
• rm 是一个危险的命令，尤其是各种 rm -rf …，所以，trash 是一个更好的删除命令。
• man 命令是好读文档的命令，但是man的文档有时候太长了，所以，你可以试试 tldr 命令，把文档上的一些示例整出来给你看。
• 如果你想要一个图示化的ping，你可以试试 prettyping 。
• 如果你想搜索以前打过的命令，不要再用 Ctrl +R 了，你可以使用加强版的 hstr  。
• htop  是 top 的一个加强版。然而，还有很多的各式各样的top，比如：用于看IO负载的 iotop，网络负载的 iftop, 以及把这些top都集成在一起的 atop。
• ncdu  比 du 好用多了用。另一个选择是 nnn。
• 如果你想把你的命令行操作建录制成一个 SVG 动图，那么你可以尝试使用 asciinema 和 svg-trem 。
• httpie 是一个可以用来替代 curl 和 wget 的 http 客户端，httpie 支持 json 和语法高亮，可以使用简单的语法进行 http 访问: http -v github.com。
• tmux 在需要经常登录远程服务器工作的时候会很有用，可以保持远程登录的会话，还可以在一个窗口中查看多个 shell 的状态。
• Taskbook 是可以完全在命令行中使用的任务管理器 ，支持 ToDo 管理，还可以为每个任务加上优先级。
• sshrc 是个神器，在你登录远程服务器的时候也能使用本机的 shell 的 rc 文件中的配置。
• goaccess  这个是一个轻量级的分析统计日志文件的工具，主要是分析各种各样的 access log。

关于这些增加命令，主要是参考自下面的这些文章

1. 10 Tools To Power Up Your Command Line
2. 5 More Tools To Power Up Your Command Line (Part 2 Of Series)
3. Power Up Your Command Line, Part 3
4. Power Up Your Command Line
5. Hacker Tools

Shell 和脚本

shell 是可以与计算机进行高效交互的文本接口。shell 提供了一套交互式的编程语言（脚本），shell的种类很多，比如 sh、bash、zsh 等。

shell 的生命力很强，在各种高级编程语言大行其道的今天，很多的任务依然离不开 shell。比如可以使用 shell 来执行一些编译任务，或者做一些批处理任务，初始化数据、打包程序等等。

现在比较流行的是 zsh + oh-my-zsh + zsh-autosuggestions 的组合，你也可以试试看。其中 zsh 和 oh-my-zsh 算是常规操作了，但是 zsh-autosuggestions 特别有用，可以超级快速的帮你补全你输入过的命令，让命令行的操作更加高效。

另外，fish 也是另外一个牛逼的shell，比如：命令行自动完成（根据历史记录），命令行命令高亮，当你要输入命令行参数的时候，自动提示有哪些参数…… fish在很多地方也是用起来很爽的。和上面的 oh-my-zsh 有点不分伯仲了。

你也许会说，用 Python 脚本或 PHP 来写脚本会比 Shell 更好更没有 bug，但我要申辩一下:

• 其一，如果你有一天要维护线上机器的时候，或是到了银行用户的系统（与外网完全隔离，而且服务器上没有安装 Python/PHP 或是他们的的高级库，那么，你只有 Shell 可以用了）。
• 其二，而且，如果要跟命令行交互很多的话，Shell 是不二之选，试想一下，如果你要去 100 台远程的机器上查access.log 日志中有没有某个错误，完成这个工作你是用 PHP/Python 写脚本快还是用 Shell 写脚本快呢？

所以，我们还要学会只使用传统的grep/awk/sed等等这些POSIX的原生的系统默认安装的命令。

当然，要写好一个脚本并不容易，下面有一些小模板供你参考：

处理命令行参数的一个样例

while [ "$1" != "" ]; do
    case $1 in
        -s  )   shift	
		SERVER=$1 ;;  
        -d  )   shift
		DATE=$1 ;;
	--paramter|p ) shift
		PARAMETER=$1;;
        -h|help  )   usage # function call
                exit ;;
        * )     usage # All other parameters
                exit 1
    esac
    shift
done 

命令行菜单的一个样例

#!/bin/bash
# Bash Menu Script Example

PS3='Please enter your choice: '
options=("Option 1" "Option 2" "Option 3" "Quit")
select opt in "${options[@]}"
do
    case $opt in
        "Option 1")
            echo "you chose choice 1"
            ;;
        "Option 2")
            echo "you chose choice 2"
            ;;
        "Option 3")
            echo "you chose choice $REPLY which is $opt"
            ;;
        "Quit")
            break
            ;;
        *) echo "invalid option $REPLY";;
    esac
done

颜色定义，你可以使用 echo -e "${Blu}blue ${Red}red ${RCol}etc...." 进行有颜色文本的输出

RCol='\e[0m'    # Text Reset

# Regular           Bold                Underline           High Intensity      BoldHigh Intens     Background          High Intensity Backgrounds
Bla='\e[0;30m';     BBla='\e[1;30m';    UBla='\e[4;30m';    IBla='\e[0;90m';    BIBla='\e[1;90m';   On_Bla='\e[40m';    On_IBla='\e[0;100m';
Red='\e[0;31m';     BRed='\e[1;31m';    URed='\e[4;31m';    IRed='\e[0;91m';    BIRed='\e[1;91m';   On_Red='\e[41m';    On_IRed='\e[0;101m';
Gre='\e[0;32m';     BGre='\e[1;32m';    UGre='\e[4;32m';    IGre='\e[0;92m';    BIGre='\e[1;92m';   On_Gre='\e[42m';    On_IGre='\e[0;102m';
Yel='\e[0;33m';     BYel='\e[1;33m';    UYel='\e[4;33m';    IYel='\e[0;93m';    BIYel='\e[1;93m';   On_Yel='\e[43m';    On_IYel='\e[0;103m';
Blu='\e[0;34m';     BBlu='\e[1;34m';    UBlu='\e[4;34m';    IBlu='\e[0;94m';    BIBlu='\e[1;94m';   On_Blu='\e[44m';    On_IBlu='\e[0;104m';
Pur='\e[0;35m';     BPur='\e[1;35m';    UPur='\e[4;35m';    IPur='\e[0;95m';    BIPur='\e[1;95m';   On_Pur='\e[45m';    On_IPur='\e[0;105m';
Cya='\e[0;36m';     BCya='\e[1;36m';    UCya='\e[4;36m';    ICya='\e[0;96m';    BICya='\e[1;96m';   On_Cya='\e[46m';    On_ICya='\e[0;106m';
Whi='\e[0;37m';     BWhi='\e[1;37m';    UWhi='\e[4;37m';    IWhi='\e[0;97m';    BIWhi='\e[1;97m';   On_Whi='\e[47m';    On_IWhi='\e[0;107m';

取当前运行脚本绝对路径的示例：（注：Linux下可以用 dirname $(readlink -f $0) ）

FILE="$0"
while [[ -h ${FILE} ]]; do
    FILE="`readlink "${FILE}"`"
done
pushd "`dirname "${FILE}"`" > /dev/null
DIR=`pwd -P`
popd > /dev/null

如何在远程服务器运行一个本地脚本

#无参数
ssh user@server 'bash -s' < local.script.sh

#有参数
ssh user@server ARG1="arg1" ARG2="arg2" 'bash -s' < local_script.sh

如何检查一个命令是否存在，用 which 吗？最好不要用，因为很多操作系统的 which 命令没有设置退出状态码，这样你不知道是否是有那个命令。所以，你应该使用下面的方式。

# POSIX 兼容:
command -v [the_command]

# bash 环境:
hash [the_command]
type [the_command]

# 示例：
gnudate() {
    if hash gdate 2> /dev/null; then
        gdate "$@"
    else
        date "$@"
    fi
}

然后，如果要写出健壮性更好的脚本，下面是一些相关的技巧：

• 使用 -e 参数，如：set -e 或是 #!/bin/sh -e，这样设置会让你的脚本出错就会停止运行，这样一来可以防止你的脚本在出错的情况下还在拼拿地干活停不下来。
• 使用 -u 参数，如： set -eu，这意味着，如果你代码中有变量没有定义，就会退出。
• 对一些变理，你可以使用默认值。如：${FOO:-'default'}
• 处理你代码的退出码。这样方便你的脚本跟别的命令行或脚本集成。
• 尽量不要使用 ; 来执行多个命令，而是使用 &&，这样会在出错的时候停止运行后续的命令。
• 对于一些字符串变量，使用引号括起，避免其中有空格或是别的什么诡异字符。
• 如果你的脚有参数，你需要检查脚本运行是否带了你想要的参数，或是，你的脚本可以在没有参数的情况下安全的运行。
• 为你的脚本设置 -h 和 --help 来显示帮助信息。千万不要把这两个参数用做为的功能。
• 使用 $() 而不是 来获得命令行的输出，主要原因是易读。
• 小心不同的平台，尤其是 MacOS 和 Linux 的跨平台。
• 对于 rm -rf 这样的高危操作，需要检查后面的变量名是否为空，比如：rm -rf $MYDIDR/* 如果 $MYDIR为空，结果是灾难性的。
• 考虑使用 “find/while” 而不是 “for/find”。如：for F in $(find . -type f) ; do echo $F; done 写成 find . -type f | while read F ; do echo $F ; done 不但可以容忍空格，而且还更快。
• 防御式编程，在正式执行命令前，把相关的东西都检查好，比如，文件目录有没有存在。

你还可以使用ShellCheck 来帮助你检查你的脚本。

• https://www.shellcheck.net/

最后推荐一些 Shell 和脚本的参考资料。

各种有意思的命令拼装，一行命令走天涯:

• http://www.bashoneliners.com/
• http://www.shell-fu.org/
• http://www.commandlinefu.com/

下面是一些脚本集中营，你可以在里面淘到各种牛X的脚本：

• http://www.shelldorado.com/scripts/
• https://snippets.siftie.com/public/tag/bash/
• https://bash.cyberciti.biz/
• https://github.com/alexanderepstein/Bash-Snippets
• https://github.com/miguelgfierro/scripts
• https://github.com/epety/100-shell-script-examples
• https://github.com/ruanyf/simple-bash-scripts

甚至写脚本都可以使用框架:

• 写bash脚本的框架 https://github.com/Bash-it/bash-it

Google的Shell脚本的代码规范：

• https://google.github.io/styleguide/shell.xml

最后，别忘了几个和shell有关的索引资源：

• https://github.com/alebcay/awesome-shell
• https://github.com/awesome-lists/awesome-bash
• https://terminalsare.sexy/

最后，如果你还有什么别的更好的玩的东西，欢迎在评论区留言，或是到 coolshellx/ariticles @ github 修改本文。

（全文完）

三观是世界观、人生观和价值观，

• 世界观代表你是怎么看这个世界的。是左还是右，是激进还是保守，是理想还是现实，是乐观还是悲观……
• 人生观代表你要想成为什么样的人。是成为有钱人，还是成为人生的体验者，是成为老师，还是成为行业专家，是成为有思想的人，还是成为有创造力的人……
• 价值观则是你觉得什么对你来说更重要。是名是利，是过程还是结果，是付出还是索取，是国家还是自己，是家庭还是职业……

人的三观其实是会变的，回顾一下我的过去，我感觉我的三观至少有这么几比较明显的变化，学生时代、刚走上社会的年轻时代，三十岁后的时代，还有现在。估计人都差不多吧……

• 学生时代的三观更多的是学校给的，用各种标准答案给的，是又红又专的
• 刚走上社会后发现完全不是这么一回事，但学生时代的三观根深蒂固，三观开始分裂，内心开始挣扎
• 三十岁后，不如意的事越来越多，对社会越来越了解，有些人屈从现实，有些人不服输继续奋斗，而有些人展露才能开始影响社会，而分裂的三观开始收敛，我属于还在继续奋斗的人。
• 四十岁时，经历过的事太多，发现留给自己的时间不多，世界太复杂，而还有好多事没做，从而变得与世无争，也变得更为地自我。

面对世界

年轻的时候，抵制过日货，虽然没上过街，但是也激动过，一次是1999南斯拉夫大使馆被炸，一次是2005反日示威，以前，我也是一个爱国愤青。但是后来，有过各种机会出国长时间生活工作，加拿大、英国、美国、日本……随着自己的经历和眼界的开阔，自己的三观自己也随着有了很多的变化，发现有些事并不是自己一开始所认识的那样，而且还是截然相反的。我深深感觉到，要有一个好的世界观，你需要亲身去经历和体会这个世界，而不是听别人说。所以，当我看到身边的人情绪激动地要抵制这个国家，搞死那个民族的时候，我都会建议他去趟那个国家最好在在那个国家呆上一段时间，亲自感受一下。

再后来发现，要抵制的越来越多，小时候的美英帝国主义，然后是日本，再后面是法国、韩国、菲利宾、印度、德国、瑞典、加拿大……从小时候的台独到现在的港独、藏独、疆独……发现再这样下去，基本上来说，自己的人生也不用干别的事了……另外，随着自己的成长，越来越明白，抵制这个抵制那个只不过是幼稚和狭隘的爱国主义，真想强国，想别让他人看得起，就应该把时间和精力放在努力学习放在精益求精上，做出比他们更好的东西来。另外，感觉用对内的爱国主义解决对外的外交问题也有点驴唇不对马嘴，无非也就是转移一下内部的注意力罢了，另外还发现爱国主义还可以成为消费营销手段……不是我不爱国，是我觉得世道变复杂了，我只是一个普通的老百姓，能力有限，请不要赋予我那么大的使命，我只想在我的专业上精进，能力所能及地帮助身边的人，过一个简单纯粹安静友善的生活……

另外，为什么国与国之间硬要比个你高我低，硬要分个高下，硬要争出个输赢，我也不是太理解，世界都已经发展到全球化的阶段了，很多产品早就是你中有我，我中有你的情况了。举个例子，一部手机中的元件，可能来自全世界数十个国家，我们已经说不清楚一部手机是究竟是哪个国家生产的了。即然，整个世界都在以一种合作共赢全球化的姿态下运作，认准自己的位置，拥抱世界，持续向先进国家学习，互惠互利，不好吗？你可能会说，不是我们不想这样，是别人不容我们发展……老实说，大的层面我也感受不到，但就我在的互联网计算机行业方面，我觉得整个世界的开放性越来越好，开源项目空前地繁荣，世界上互联网文化也空前的开放，在计算机和互联网行业，我们享受了太多的开源和开放的红利，人家不开放，我们可能在很多领域还落后数十年。然而现在很多资源我们都访问不了，用个VPN也非法，你说是谁阻碍了发展？我只想能够流畅地访问互联网，让我的工作能够更有效率，然而，我在自己的家里却像做贼一样去学习新知识新技术，随时都有可能被抓进监狱……

随着自己的经历越多，发现这个世界越复杂，也发现自己越渺小，很多国家大事并不是我不关心，是我觉得那根本不是我这个平头老百姓可以操心的事，这个世界有这个世界运作的规律和方法，而还有很多事情超出了我能理解的范围，也超出了我能控制的范围，我关心不关心都一个样，这些大事都不会由我的意志所决定的。而所谓的关心，无非就是喊喊口号，跟人争论一下，试图改变其它老百姓的想法，然而，对事情的本身的帮助却没有多大意义。过上几天，生活照旧，人家该搞你还不是继续搞你，而你自己并不因为做这些事而过得更好。

我对国与国之间的关系的态度是，有礼有节，不卑不亢，对待外国人，有礼貌但也要有节气，既不卑躬屈膝，也不趾高气昂，整体上，我并不觉得我们比国外有多差，但我也不觉得我们比国外有多好，我们还在成长，还需要帮助和协作，四海之内皆兄弟，无论在哪个国家，在老百姓的世界里，哪有那么多矛盾。有机会多出去走走，多结交几个其它民族的朋友，你会觉得，在友善和包容的环境下，你的心情和生活可以更好。

我现在更多关心的是和我生活相关的东西，比如：上网、教育、医疗、食品、治安、税务、旅游、收入、物价、个人权益、个人隐私……这些东西对我的影响会更大一些，也更值得关注，可以看到过去的几十年，我们国家已经有了长足的进步，这点也让我让感到很开心和自豪的，在一些地方也不输别人。但是，依然有好些事的仍然没有达到我的预期，而且还很糟糕，这个也要承认。而对，未来的变数谁也不好说，我在这个国度里的安全感似乎还不足够，所以，我还是要继续努力，以便我可以有更多的选项。有选项总比没得选要好。所以，我想尽一切办法，努力让选项多起来，无法改变无法影响，那就只能提高自己有可选择的可能性。

面对社会

另外，在网上与别人对一些事或观点的争论，我觉得越来越无聊，以前被怼了，一定要怼回去，现在不会了，视而不见，不是怕了，是因为，网络上的争论在我看来大多数都是些没有章法，逻辑混乱的争论。

• 很多讨论不是说事，直接就是怼人骂人。随意就给人扣个帽子。
• 非黑即白的划分，你说这个不是黑的，他们就把你划到白的那边。
• 飘移观点，复杂化问题。东拉西扯，牵强附会，还扯出其它不相关的事来混淆。
• 杠精很多，不关心你的整体观点，抓住一个小辫子大作文章。

很明显，与其花时间教育这些人，不如花时间提升自己，让自己变得更优秀，这样就有更高的可能性去接触更聪明更成功更高层次的人。因为，一方面，你改变不了他们，另外，改变他们对你自己也没什么意义，改变自己，提升自己，让自己成长才有意义。时间是宝贵的，那些人根本不值得花时间，应该花时间去结交更有素质更聪明的人，做更有价值的事。

美国总统富兰克林·罗斯福妻子埃莉诺·罗斯福（Eleanor Roosevelt）说过下面的一句话。

Great minds discuss ideas;
Average minds discuss events;
Small minds discuss people

把时间多放在一些想法上，对自己对社会都是有意义的，把时间放在八卦别人，说长到短，你也不可能改善自己的生活，你批评这个批评那个，看不上这个看不起那个，不会让你有成长，也不会提升你的影响力，你的影响力不是你对别人说长道短的能力，而是别人信赖你并希望得到你的帮助的现象。多交一些有想法的朋友，多把自己的想法付诸实践，那怕没有成功，你的人生也会比别人过得有意义。

如果你看过我以前的文章，你会看到一些吐槽性质的文章，而后面就再也没有了。另外，我也不再没有针对具体的某个人做出评价，因为人太复杂的了，经历的越多，你就会发现你很难评价人，与其花时间在评论人和事上，不如把时间花在做一些力所能及的事来改善自己或身边的环境。所以，我建议大家少一些对人的指责和批评，通过对一件事来引发你的思考，想一想有什么可以改善，有什么方法可以做得更好，有哪些是自己可以添砖加瓦的？你会发现，只要你坚持这么做，你个人的提升和对社会的价值会越来越大，而你的影响力也会越来越大。

面对人生

现在的我，即不是左派也不是右派，我不喜欢爱国主义，我也不喜欢崇洋媚外，我更多的时候是一个自由派，哪边我都不站，我站我自己。因为，生活在这样的一个时代，能让自己过好都是一些比较奢望的事了。

《教父》里有这样的人生观：第一步要努力实现自我价值，第二步要全力照顾好家人，第三步要尽可能帮助善良的人，第四步为族群发声，第五步为国家争荣誉。事实上作为男人，前两步成功，人生已算得上圆满，做到第三步堪称伟大，而随意颠倒次序的那些人，一般不值得信任。这也是古人的“修身齐家治国平天下”！所以，在你我准备要开始要“平天下”的时候，也得先想想，自己的生活有没有过好了，家人照顾好了么，身边有哪些力所能及的事是可以去改善的……

穷则独善其身，达则兼济天下。提升自己，实现自我，照顾好自己的家人，帮助身边的人。这已经很不错了！

什么样的人干什么样的事，什么样的阶段做什么样的选择，有人的说，选择比努力更重要的，我深以为然，而且，我觉得选择和决定，比努力更难，努力是认准了一个事后不停地发力，而决定要去认准哪个事是自己该坚持努力的，则是令人彷徨和焦虑的（半途而废的人也很多）。面对人生，你每天都在作一个一个的决定，在做一个又一个的选择，有的决定大，有的决定小，你的人生的轨迹就是被这一个一个的决定和选择所走走出来的。

我在24岁放弃了一房子离开银行到小公司的时候，我就知道，人生的选择就是一个翘翘板，你要一头就没有另一头，选择是有代价的，你不选择的代价更大；选择是要冒险的，你不敢冒险的风险更大；选择是需要放弃的，因为无论怎么选你都会要放弃。想想你老了以后，回头一看，好多事情在年轻的时候都不敢做，而你再也没有机会，你就知道不敢选择不敢冒险的代价有多大了。选择就是一种 trade-off，这世上根本不会有什么完美，只要你想做事，你有雄心壮志，你的人生就是一个坑接着一个坑，你所能做的就是找到你喜欢的方向跳坑。

所以， 你要想清楚你要什么，不要什么，而且还不能要得太多，这样你才好做选择。否则，你影响你的因子太多，决定不好做，也做不好。

就像最前面说的一样，你是激进派还是保守派，你是喜欢领导还是喜欢跟从，你是注重长期还是注重短期，你是注重过程还是注重结果……等等，你对这些东西的坚持和守护，成为了你的“三观”，而你的三观则影响着你的选择，而你的选择影响着你的人生。

价值取向

下面是一些大家经常在说，可能也是大多数人关心的问题，就这些问题，我也谈谈我的价值取向。

挣钱。挣钱是一个大家都想做的事，但你得解决一个很核心的问题，那就是为什么别人愿意给你钱？对于挣钱的价值观从我大学毕业到现我就没怎么变过，那就是我更多关注的是怎么提高自己的能力，让自己值那个价钱，让别人愿意付钱。另外一方面，我发现，越是有能力的人，就越不计较一些短期得失，越计较短期得失的人往往都是很平庸的人。有能力的人不会关心自己的年终奖得拿多少，会不会晋升，他们更多的关心自己真正的实力有没有超过更多的人，更多的关注的是自己长远的成长，而不是一时的利益。聪明的人从来不关心眼前的得失，不会关心表面上的东西，他们更多关心的是长期利益，关心长期利益的人一定不是投机者，一定是投资者，投资会把自己的时间精力金钱投资在能让自己成长和提升的地方，那些让自己可以操更大的盘的地方，他们培养自己的领导力和影响力。而投机者在职场上会通过溜须拍马讨好领导，在学习上追求速成，在投资上使用跟随策略，在创业上甚至会不择手段，当风险来临时，投机者是几乎完全没有抗风险能力的，他们所谓的能力只不过因为形势好。

技术。对于计算机技术来说，要学的东西实在是太多，我并不害怕要学的东西很多，因为学习能力是一个好的工程师必需具备的事，我不惧怕困难和挑战。我觉得在语言和技术争论谁好谁坏是一种幼稚的表现， 没有完美的技术，Engineering 玩的是 Tradeoff。所以，我对没有完美的技术并不担心，但是我反而担心的是，当我们进入到一些公司后，这些公司会有一些技术上的沉淀也就是针对公司自己的专用技术，比如一些中间件，一些编程框架，lib库什么的。老实说，我比较害怕公司的专用技术，因为一旦失业，我建立在这些专用技术上的技能也会随之瓦解，有时候，我甚至害怕把我的技术建立在某一个平台上，小众的不用说了，大众的我也比较担扰，比如Windows或Unix/Linux上，因为一旦这个平台不流行或是被取代，那么我也会随之淘汰（过去的这20年已经发生过太多这样的事了）。为了应对这样的焦虑，我更愿意花时间在技术的原理和技术的本质上，这导致我需要了解各种各样的技术的设计方法，以及内在原理。所以，当国内的绝大多数程序员们更多的关注架构性能的今天，我则花更多的时间去了解编程范式，代码重构，软件设计，计算机系统原理，领域设计，工程方法……因为只有原理、本质和设计思想才可能让我不会被绑在某个专用技术或平台上，除非，我们人类的计算机这条路没走对。

职业。在过去20多年的职业生涯中，我从基层工程师做到管理，很多做技术的人都会转管理，但我却还是扎根技术，就算是在今天，还是会抠很多技术细节，包括写代码。因为我心里觉得，不写代码的人一定是做不好技术管理的，因为做技术管理有人要做技术决定，从不上手技术的人是做不好技术决定的，另一方面，我觉得管理是支持性的工作，不是产出性的工作，大多数的管理者无非是因为组织大了，所以需要管人管事，所以，必然要花大量的时间和精力处理各种问题，甚至办公室政治，然而，如果有一天失业了，大环境变得不好了，一个管理者和一个程序员要出去找工作，程序员会比管理者更能自食其力。所以，我并不觉得管理者这个职业有意思，我还是觉得程序员这个有创造性的职业更有趣。通常来说，管理者的技能力需要到公司和组织里才能展现，而有创造力的技能的人是可以自己独立的能力，所以，我觉得程序员的技能比管理者的技能能让我更稳定更自地活着。所以，我更喜欢“电影工作组”那样的团队和组织形式。

打工。对于打工，也就是加入一家公司工作，无论是在一家小公司还是一家大公司工作，都会有好的和不好的，任何公司都有其不完美的地方，这个需要承认。首先第一的肯定是完成公司交给你的任务（但我也不会是傻傻地完成工作，对于一些有问题的任务我也会提出我的看法），然后我会尽我所能在工作找到可以提高效率的地方进行改善。在推动公司/部门/团队在一技术和工程方面进步并不是一件很容易的事，因为进步是需要成本的，有时候，这种成本并不一定是公司和团队愿意接受的，而另外，从客观规律上来说，一件事的进步一定是会有和现状有一些摩擦的。有的人害怕有摩擦而忍了，而我则不是，我觉得与别人的摩擦并不可怕，因为大家的目标都是基本一致的，只是做事的标准和方式不一样，这是可能沟通的，始终是会相互理解的。而如果你没有去推动一个事，我觉得对于公司对于我个人来说，都是一种对人生的浪费，敬业也好，激情也好，其就是体现在你是否愿意冒险去推动一件于公于私都有利的事，而不是成为一个“听话”、“随大流”、“懒政”的人，即耽误了公司也耽误了自己。所以，我更信仰的是《做正确的事情，等着被开除》，这些东西，可参看《我看绩效考核》，以及我在Gitchat上的一些问答。

创业。前两天，有个小伙来跟我说，说他要离开BAT要去创业公司了，说在那些更自由一些，没有大公司的种种问题。我毫不犹豫地教育了他一下，我说，你选择这个创业公司的动机不对啊，你无非就是在逃避一些东西罢了，你把创业公司当做是一个避风港，这是不对的，创业公司的问题可能会更多，去创业公司的更好的心态是，这个创业公司在干的事业是不是你的事业？说白了，如果你是为了你的事业，为了解决个什么，为了改进个什么，那么，创业是适合你的，也只有在做自己事业的时候，你才能不惧困难，才会勇敢地面对一切。那种想找一个安稳的避风港呆着的心态是不会让你平静地，你要知道世界本来就是不平静的，找了自己的归宿和目标才可能让你真正的平静。所以，在我现的创业团队，我不要求大家加班，我也不鸡汤洗脑，对于想要加入的人，我会跟他讲我现在遇到的各种问题以及各种机遇，并一直在让他自己思考，我们在做的事是不是自己的事业诉求？还可不可以更好？每个人都应该为自己的事业为自己的理想去活一次，追逐自己的事业和理想并不容易，需要有很大的付出，而也只有你心底里的那个理想值得这么大的付出……

客户。基于上述的价值观，在我现在创业的时候，我在面对客户的时候，也是一样的，我并不会完全的迁就于客户，我的一些银行客户和互联网客户应该体会到我的做的方式了，我并不觉得迁就用户，用户要什么我就应该给什么，用户想听什么，我就说什么，虽然这样可以省着精力，更圆滑，但这都不是我喜欢的，我更愿意鲜明地表达我的观点，并拉着用户跟我一起成长，因为我并不觉得完成客户的项目有成就感，我的成就感来自客户的成长。所以，面对客户有些做得不对有问题有隐患的地方，或是有什么做错的事，我基本上都是直言不讳地说出来，因为我觉得把真实的相法说出来是对客户和对自己最基本的尊重，不管客户最终的选择是什么，我都要把利弊跟客户讲清楚。我并不是在这里装，因为，我也想做一些更高级更有技术含量的事，所以，对于一些还达到的客户，我如果不把他们拉上来，我也对不起自己。

在我“不惑之年”形成了这些价值观体系，也许未来还会变，也许还不成熟，总之，我不愿跟大多数人一样，因为大多数人都是随遇而安随大流的，因为这样风险最小，而我想走一条属于自己的路，做真正的自己，就像我24岁从银行里出来时想的那样，我选择对了一个正确的专业（计算机科学），呆在了一个正确的年代（信息化革命），这样的“狗屎运”几百年不遇，如果我还患得患失，那我岂不辜负活在这样一个刺激的时代？！我所要做的就是在这个时代中做有价值的事就好了！这个时代真的是太好了！

(全文完)