这两天跟 Cali 和 Rather 做了一个线上的 Podcast – Ep.5 一起聊聊团队协同。主要是从 IM 工具扩展开来聊了一下团队的协同和相应的工具，但是聊天不是深度思考，有一些东西我没有讲透讲好，所以，我需要把我更多更完整更结构化的想法形成文字。（注：聊天聊地比较详细，本文只是想表达我的主要想法）

国内外的企业 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 应该是什么 样的……

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

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

（全文完）

The post 聊聊团队协同和协同工具 first appeared on 酷 壳 - CoolShell.

写这篇文章的原因主要还是因为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）工作而已，优雅不能当饭吃

回应两点：

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

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

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

（全文完）

The post “一把梭：REST API 全用 POST” first appeared on 酷 壳 - CoolShell.

今天看到微博上有一个热点事件， 是一个关于某公司做的一个监控员工离职倾向的软件，从截图中可以看到员工访问招聘网站的次数，还有投递的简历以及搜索的关建词等等信息，通过这些信息分析员工的离职倾向。然后我发一个微博，说了一下，我以前工作过的公司无论外国公司还是中国公司都有这样的情况，收到一些人来问我相关的情况，所以，我想还是写篇文章详细地说一下，我对这种事情的看法。

本文分成下面个部分：

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

技术手段

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

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

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

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

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

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

公司监控的目的

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

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

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

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

外企与国企不同之处

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

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

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

我对此事的看法

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

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

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

（全文完）

The post 谈谈公司对员工的监控 first appeared on 酷 壳 - CoolShell.

分享信息并不难，大多数人都能做到，就算是不善言谈性格内向的技术人员，通过博客或社交媒体，或是不正式的交流，他们都能或多或少的做到。但是如果你想要做一个有质量有高度的分享，这个就难了，所谓的有质量和有高度，我心里面的定义有两点：1）分享内容的保鲜期是很长的，2）会被大范围的传递。我们团队内每周都在做技术分享，虽然分享的主题都很有价值，但是分享的质量参差不齐，所以，想写下这篇文章 。供大家参考。

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

• 把复杂的问题讲解的很简单也很清楚。比如我高中时期读到这本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.

（全文完）

The post 如何做一个有质量的技术分享 first appeared on 酷 壳 - CoolShell.