不准访问
- 积分
- 1553
- 大米
- 颗
- 鳄梨
- 个
- 水井
- 尺
- 蓝莓
- 颗
- 萝卜
- 根
- 小米
- 粒
- 学分
- 个
- 注册时间
- 2011-7-30
- 最后登录
- 1970-1-1
|
本帖最后由 puncsky 于 2019-11-24 16:21 编辑
谷歌的软件工程：软件开发
本文首发于硅谷io
业界公认，谷歌是一家工程能力超强的公司。它有哪些好的工程实践？我们可以在里面得到哪些启发？其中又有哪些地方是被人诟病的？这些内容比较细致我们慢慢讲，本篇主要是讲开发。
![]()
代码库
- 截止15年有 20 亿行代码存在少量的 Monorepo 单一代码库中，绝大部分代码对所有人是可见的。谷歌鼓励工程师见到有问题就可以改，只要所有人审核通过，就能进库。
- 几乎所有的开发都是在代码库的头部 (head) 进行的，而不是在分枝上，避免 merge 时候遇到问题，安全修复也更方便。
- 每个改动都会触发测试，有错几分钟内就能通知作者和审查者。
- 代码库的每个子树至少有两个所有人，其他开发者可以提交修改，但是所有人批准才能进库。
构建系统
- 分布式构建系统 Blaze 让编译、链接、测试轻松快速。
- 成百上千台机器。
- 可靠性高，确定的依赖输入导致确定的结果输出，不会出现奇怪的不确定的抖动。
- 快。一个构建结果缓存了，依赖它的构建会直接采用缓存，不必重新勾结。只会重新构建改动的部分。
- 提交前自检 (pre-submit checks)。一些快速的测试可以在提交前先执行。
代码审查
- 有代码审查工具
- 所有改动必须有审查
- 发现 bug 之后可以去之前的那个审查上指出问题，相关人员会被邮件通知到
- 实验性质的代码不用强制审查，但是生产环境下的代码一定会被审查
- 鼓励每个改动尽量小。百行以内是“小”，三百行以内是“中”，一千行以内是“大”，超过一千行是“超tm大”。
测试
- 单元测试
- 集成测试、回归测试
- 提交前检查
- 自动生成测试覆盖率
- 部署之前做压力测试，并产生相应的关键指标，尤其是延迟、错误率随着负载的变化
Bug 追踪工具
Bugs, feature requests, customer issues, process 等等都记录起来，需要时常 triage 以确认优先级然后分配给相应的工程师。
编程语言
- 限制有五个官方语言 C++, Java, Python, Go, JavaScript，以便代码重用和开发协作。每种语言有风格指南。
- 工程师要经历代码可读性培训。
- 当然某些场合的 DSL (Domain-specific language) 也不可避免。
- 这些语言之间的数据交互主要是通过 protocol buffers。
- 通用流程很重要，不同的语言，同样的工作流程
Debug 和分析工具
- 服务器崩溃时，崩溃信息会自动记录下来。
- 内存泄漏会附带上当前的 heap 对象。
- 有大量的 web 工具帮你检测 RPC 的请求、改变设置、资源消耗等等。
发布
- 大多数的发布工作是普通的工程师自己做的
- 及时发布很重要，因为快速的发布节奏能够极大地激励工程师多干活、更快地得到反馈
- 典型的发布过程：
- 找最新的稳定 build ，做一个 release branch，可能再附带 cherry-pick 一些小改动
- 跑测试与构建、打包
- 发布到 staging 服务器上内部测试，这时候可以 shadow 一下线上的流量，看看有没有问题
- 发布到 canary 上承接少量的流量公开测试
- 逐渐发布给所有的用户
对发布的审查
用户可见的、或者是重大的发布必须有相关的法务、隐私、安全、可靠性、业务需求相关的审查批准，确保相关人员被通知到。有专门的工具来辅助这个流程。
尸检报告
有重大的 outage 事故发生之后，相关责任人必须写尸检报告，内容包括
- 事件标题
- 总结
- 影响：发生了多久、影响了多少流量、损害了多少利润
- 时间轴：记录时间的发生、诊断和消弭
- root causes
- 做的好的地方，做的不好的地方：有什么经验能够帮助他人在下一次更快更准地找到并解决问题？
- 接下来的可行动作：有什么接下来可以做的事情能够避免将来类似的事情发生？
对事不对人，这里的关键是理解问题本身、以及将来如何避免类似问题。
重写代码
大量的软件每隔几年就会被重写一次。坏处是确实成本高，好处是
- 保持敏捷。市场在变，软件的需求也一直在变，代码也需要随之变化以应对不时之需。
- 降低复杂度。
- 传承知识给新人，让他们有拥有感。
- 提高工程师的移动性，促进跨领域创新。
- 采用最新的技术栈和方法论。
我的评论
谷歌的单一代码库和强大的构建系统是小公司不可学的，毕竟小公司没有资源和能力让构建系统快到敏捷可用；保持小、简单、快速会让小公司跑得更顺畅，更加专注于核心业务逻辑。
构建系统通常是定制化的，你的知识无法迁移和衍生。强大的构建系统对新手甚至是有害的，因为提高了新手俯瞰全局的成本。
知识无法迁移和衍生也是完善的内部工具 (in-house tools) 的问题。我在职业生涯中会尽量避免使用不会开源的内部工具，比如 Uber 的 Schemaless，只针对特定的场景且没打开放出来算做大做强 ；而相反的， Linkedin 的 Kafka 则是一个有开放性和衍生性的知识的好产品。
在公开市场，这整个开发、测试、集成、发布的流程都有非常好的工具帮你来做，举个 JS 社区的例子：
[td]| 流程 | 工具 | | 代码库 | Github, Gitlab, Bitbucket, gitolite | | 代码审查 | Github Pull Requests, Phabricator | | 提交前自检、测试与 Lint | husky, ava, istanbul, eslint, prettier | | Bug Tracking | Github Issues, Phabricator | | 测试与持续集成 | CircleCI, TravisCI, TeamCity | | 部署 | 发布在线服务的 Heroku, Netifly, 发布移动 App 的 Fastlane, 发布库的 NPM |
最后，我可能有一个洞见，不注重这些工程流程自动化的细节的公司，在工程上会损失巨大的竞争力。我甚至为了良好的工程实践自己配了一个 JS 全栈开发框架 OneFx。快节奏与慢节奏、高质量与低质量差别，通常是指数级别的，因为 —— 通常，快会让你更快更多，差会让你更差更少。
如果这篇文章对你有帮助，请在 github 上 follow 我
|
|
楼主: puncsky
狗仔卡
楼主
