现代化开发守则不完整归纳

2018-07-21 17:23:38

  • 容器化

    现在是 2018 年，你不应该直接在物理机上运行你的代码。容器化决定了你基础的架构和部署方式，为下面要提到的各种自动化奠定了基础。如果你是一个只有十几台服务器的初创公司，你甚至不需要面对 Kubernetes，调度引擎这些有点唬人的词，Docker Swarm 很可能就够你用了，而且你不需要花太多时间就能学会和实践它。

  • 关于 CI/CD

    相信我，这个肯定花不了你多少时间，不论是 Gitlab 还是 Github 都有很棒的 CI/CD 方案，配合容器化的基础部署结构，你可以很轻松的构造一个适合你的 CI/CD pipeline。

  • lint, lint, lint

    你如果是在做一个产品，不是一个演示，这几乎是必不可少的。而且这也应该是自动化的，你没有任何理由对它说不。Don't let 💩 slip into your code base。

  • 关于 Code Review(CR)

    任何时候都需要 CR，哪怕你的技术团队就是你一个人，你也应该在每次合并前自我 CR。你一定会在 CR 时发现一些缺陷，而在 CR 阶段修正这些问题的成本是代码上线后的十分之一。这很有可能是你的团队天天加班改 bug 的主要原因。

  • staging环境

    自动化测试可以没有，但不能没有自动更新的 staging 环境：你可以没有单元测试和自动化测试，但至少从一开始你就应该有一个可以自动更新并完全集成的 staging 环境，我承认 Test-Driven Development (TDD)是很花时间的，这可能只有成熟的大公司才能负担的起，在产品迭代如此之快，市场机会稍纵即逝的早期项目里你可能承担不了这个成本。不过如果结合容器化部署以及 CI/CD，你只需要很少的成本便可以构建一个和 live 几乎完全一致，能够自动将每次合并更新运行，并集成你的所有子系统的 staging 环境。如果你做不到每个提交都有自动化测试覆盖，至少让你的每次提交都能集成运行吧。

  • 随时接入的工作环境

    构建一个可以从任何地方接入并工作的开发环境：好的工程师会像艺术家一样工作，他们的灵感有时出现在咖啡店喝咖啡时，也可能是在家里蹲马桶的时候，所以你不应该让你的工程师只能到办公室了才能工作，他们有时甚至不想来办公室而愿意在家里工作一天，这是绝对合理的。你的代码仓库，CI/CD，staging 环境等研发设施应该都能够从互联网接入，如果你认为这不安全，构建一个 VPN 环境，并让所有工程师有权限接入。如果你觉得你不能信任你的工程师，那可能是其他地方出了问题，比如下一条

  • 靠谱的员工

    只招聘杰出和有潜力成为杰出的工程师：我们在成立团队阶段面试了 100 多名候选人，最后只招聘了 3 名工程师。我认为招聘环节是打造一个好的技术团队中最重要的一环，如果你能用两倍的预算招聘一个工程师，千万别用同样的预算去招聘两个工程师。好的工程师可以 10 倍于普通工程师的效率，这不是什么唬人的鬼话。

  • 绝不996

    不要给你的技术团队设立 996 这种荒谬的固定加班政策：你应该花时间去分析你的团队效率低下的根本原因，并开始着手去解决这些问题。你的团队需要休息充分才能产生高质量的输出，不要进入不停加班修复恶性 bug 的恶性循环。最要命的是这种愚蠢的加班政策会带来很多负面情绪，让人们觉得他只是来上班，而不是来做自己的事业。

  • 总结

    简单的总结起来就是两个原则：

  1. 机器可以做的事情千万别让人做；你的团队肯定不是活多的忙不过来，他们很有可能是在忙着做本该机器做的事情，并承担种种因为不够自动化而带来的恶果。你的技术架构应该朝着可以尽可能多的自动化演进。机器可以 24 小时工作，你不能。
  2. 让最好的工程师打造自己的产品，而不是来『上班』；好的工程师是一群有理想的人，他们没有自己去创业而是和你一起来做产品是因为他们认同和喜爱这个产品。把你的团队文化打造成一个孵化器，而不是一间办公室。