Update

Author: inetfuture

README.md

@@ -102,7 +102,7 @@
  - 自己的代码被别人 Review 时，如果觉得某段代码可能有问题或者不是最优方案，主动提出来讨论，而不是等待审查者询问。前者可以使 Review 更高效，更利于培养同事间的相互信任，后者一是效率低，同时也是一种不负责任的表现。
  - 进度存在风险时主动知会其他人，而不是默默拖到最后一刻连累大家加班。
  - 做变更时及时通知相关人员，否则可能会浪费队友的时间去排查问题。代码级别的问题可以通过在 GitLab 等代码管理工具上 at 对方。
-- 认真负责，关注细节，追求卓越：
+- 认真负责，关注细节，追求卓越，即做到[结果闭环](https://www.zhihu.com/question/37973833/answer/923803321)：
  - 每一份需求都要理解之后再动手，感觉需求不合理或不明确的要提出来讨论，对产品要有责任心，不仅仅是“按部就班”得做事情。
  - 提交前仔细测试自己实现的功能，检查代码细节，有交付高质量代码的责任心，而不是依赖其他成员帮你 Reivew 或者 QA 帮你发现 bug。
  - 代码仅仅可以工作是不够的，还要可读、易扩展、可维护、安全、高效，等等等等，要用高标准要求自己，写代码要“上心”，认真写好每一行，不要敷衍、随意。
@@ -448,7 +448,7 @@ $(description)
 
 目标是提高沟通效率，节省时间。
 
-- 别扭扭捏捏，放开声音好好说话。
+- 口头沟通时，别扭扭捏捏，放开声音好好说话。
 - 组织好语言，主语、谓语、宾语、状语要清晰，尽量少用“TA”、“这个”、"那个"等指称代词，话要说全。
 - 尽量提供完整的上下文，前因后果交代清楚，尤其是对话刚开时的时候，不要急于切入重点，先确保对方了解足够的背景，避免不必要的背景交代相关的往复提问和回答。
 
@@ -474,8 +474,8 @@ $(description)
  - 注意 IM 群组的主题，必要的话创建专门的新群组，不要在一个群组里讨论与这个群组主题或其中大部分人无关的事情。
 - 在邮件或 issue 上对某人发起请求后，不要再跑到 IM 上去提醒，尤其不要在公共 IM 群组提醒，这种提醒是纯粹的噪音，浪费屏幕空间，浪费其他人的时间。
  - 担心对方不看、不回怎么办？如果你有期望回复的最晚时间，那么直接写明，否则对方可能确实在忙，把你的往后排了；如果对方经常长时间甚至永远都不回复，非要等你通过其它渠道催，那么不管你有没有指明期望回复时间，都是对方的问题，响应其他人的请求是基本的职业素养，提醒 TA 注意处理，但是绝对不要容忍每次都要提醒，绝对不要默许这种费劲的沟通方式，这种人是在浪费大家的时间，甚至可能带坏其他人。
- - 理想情况下，每个人都会保证请求的及时响应，也就不需要无谓的担心和反复确认，沟通噪音就会少很多。事情太多，老是忘怎么办？你需要一个 TODO 管理工具，不能立即处理的先记下来，定期清理。
- - 怎么算及时？看情况，一般来说，请求方未明确期望回复时间的前提下，一工作日内能回复就算及时，明显不重要、不紧急的事务几个工作日内能回复即可。
+ - 每个人都应该保证请求的及时响应，即做到[沟通闭环](https://www.zhihu.com/question/37973833/answer/923803321)，也就不需要无谓的担心和反复确认，沟通噪音就会少很多。事情太多，老是忘怎么办？你需要一个 TODO 管理工具，不能立即处理的先记下来，定期清理。
+ - 怎么算及时？看情况，一般来说，请求方未明确期望回复时间的前提下，一工作日内能回复就算及时，明显不重要、不紧急的事务几个工作日内能回复也可。
 - 尽量不要使用微信沟通，推荐使用 [倍洽](https://bearychat.com/) 或自行搭建 [Rocket.Chat](https://rocket.chat/)，因为微信不适合工作场景：
  - 历史记录只保存在客户端，易丢失，不易搜索。
  - 新成员看不到历史消息，有时候沟通历史很重要，可以看到一件事情如何演变的，为什么是现在这个样子。