今天看到江宏的博客，他加入你们了。

wow!

@AoEiuV020JP #3 取决于怎么看待。抛开各种硬性、软性的好处。或许也可以参考一下另一种看法，即：技术文档是团队工程实践的记录，并且属于团队知识的一部分（而不是个人知识）。团队内的资深工程师和 Tech Lead 有责任维护它并进行更广泛的传播。

这些文档尽量不要等到交接的时候再去写，而是应该在日常工作中去完成。同时也应该把这些文档当成项目或者仓库的一部分，放在 仓库 wiki 里随着项目更新而修改。这样不管是对新人还是工作交接都更有利于。

以下是我们团队的一些实践：
1.新手教程。
2.架构说明。各个组件的作用，核心依赖以及非核心依赖。国内、海外，主、备等。
3.组件介绍。每个组件的核心逻辑、核心目录等介绍，可以根据重要程度详细或者简略介绍。
4.编码实践。如何搭建本地环境、分支管理策略、issue/PR 规范、代码审核规范、单元测试规范。
5.运维实践-开发篇。如何预发布、灰度、发布、重启、回滚等，以及 CI/CD 。
6.运维实践-运维篇。云服务商依赖、基础设施依赖简介。监控：业务监控、基础设施监控，报警：业务报警、其他报警。
7.测试。 如何单元测试、本地集成测试、预发布环境测试。
8.日志。日志规范、如何使用日志。
9.故障与问题。历史故障复盘、常见问题如何处理。
10.非预期。限流、降级、预案等，最小集功能。
11.账号与 license 。 各种依赖的账号、license 应该去那里找。
12.其他：核心功能的设计讨论文档链接等等。


等到交接的时候再去写上面的这些内容，细节早就遗失了。

阿里业务部门的测试基本只做测试相关的工作，开发工作基本不涉及的。记忆里在阿里三年多接触到的测试大部分时间都花在业务测试上了，开发相关的工作好像也就是极少写写链路压测脚本之类的。

@4kingRAS #9 不太可能是应用级的问题，应用级的问题回滚一下就好了，再差顶多几十分钟一个小时也就处理完成了。

@vanityfairn 这些人大概率都还在大公司里全职呢，估计连融资都还没拿到，也不愿意花时间去写这个 side project 。想白嫖一把做出 demo 去骗融资。

真是中国人就坑中国人啊

@moonrailgun https://www.webpagetest.org 和 https://ping.chinaz.com

墙内的好处就是访问可能快些。

我的 https://www.linnana.me 墙外测首页加载完基本 600 ms 内，而墙内 3 s 左右，有些省份还是 5 s 。

你这种结论有点片面了，国内也有不少这样的人和公司。

@seres 我平常读英文书籍一般都是读要义，能理解整体意思就满足了。我英语四级多一点的渣渣水平，但读《 Philosophy of Science: A Very Short Introduction 》对应中译：《科学哲学》，其实还好，能读得懂。

或许需要加一下词汇量？

@lowend 哦，又学到一个知识点。

忽然想不起来自己为什么能理解中国的古诗了。

蹭流量的时候到了

https://www.linnana.me

这两件事情并不冲突。

在你没有人事管理权之前（比如开除某个人的权利，给某个人打绩效），以 lead 为主，把自己的位置放的低一些，看看自己能不能把一小群人聚起来做事情。这时候可以多考虑技术管理上的事情，多帮助团队内同事，把技术和项目上的事情理顺。有难题冲在前面，没难题拆解了分给其他同事做（再次，把自己的位置放低一些）。发挥团队的力量是一个慢慢来的过程，可能需要一到两个月才能甚至更长时间才能体现出效果来。

如果你有人事管理权，你觉得纯做技术、项目、团队这三方面的管理对团队利益是最大化的，那就按照你的想法来做。比如觉得 2023 年最后的几个月，你只做团队管理可以给团队利益最大化，那就这么做。有了人事管理权才称得上是管理者，自然你权利越大责任越大。

已加。https://www.linnana.me