踏入职场后写代码已经有 14 个年头，保守估计应该垒了有 50 万行的代码。尤其最近 1 年多从 0 开始写起 Bytebase，日常也会 review 同事的代码。趁着端午也总结了一些经验，这些经验聚焦在写代码的具体细节上，在道，法，术，技中更多归之于技。首先声明这些技是用来帮助写出更可维护的代码，而不是更快地写出代码，Enjoy。

命名篇

1. 字母使用小写。有些系统对大小写不敏感。

2. 名词使用单数。英文的复数规则比较复杂，尤其对于英语非母语程序员来说，用复数容易造成代码命名不一致。如果是表示数组的话，可以加上 List 后缀。

3. 动词使用一般时态。同样英文的动词被动时态规则也有好多种，使用被动时态容易造成命名不一致。

4. 使用 Reversed domain name notation (reverse-DNS) 来命名。比如在 Bytebase 里定义 issue 创建这个活动，我们可以用 bb.issue.create。而成员的创建可以用 bb.member.create。名字定义本身包含了结构，具备更好的可读性，同时搜索的时候也可以使用 bb.member 这样的前缀搜索。

范式篇

1. 使用 Command Pattern，把每一个变更的行为都包装成一个 Command，具体 Command 的名字定义使用前面提到的 reversed domain name notation。这样的好处是我们能提取出一个中央的组件来处理这些命令，像 undo/redo, logging 这些就变得相当容易。绝大多数应用框架其实都有 Command Pattern 的身影。

2. 考虑使用 Soft Delete 而不是 Hard Delete，通常在数据库表结构里加上一列 status, 其中一个值是 PENDING_DELETE，可以有效防止误操作，让 undo 的实现也变得简单。

3. 除非有必须的理由，尽量避免持久化状态。持久化状态会大大增加将来迁移和升级的复杂度。

架构设计篇

1. 先设计 Schema / 领域建模，再设计 API，再其他。

2. Schema / 领域建模设计的 4 个要点，对象本身，对象的行为，对象的约束以及对象间的关系。

3. 培养使用 namespace 的意识。namespace 能帮助更好地做模块设计，前面提到的 reversed domain name notation 就是 namespace 的一种运用。

4. 大型项目需要尽早采用 Plugin 架构，区分 Core 和 Plugin 部分。Linux 的 Core 其实不大，绝大多数都是 Driver 代码 (Plugin 的一种类型)。Bytebase 的代码也做了类似的拆分。

 

技术选型篇

‍

1. 使用 Restful 而不是 GraphQL。

1. RESTful 是更成熟的技术，有成熟的生态。

2. RESTful 帮助团队更早关注领域建模，因为需要识别出对象以及对象上的行为。

3. RESTful 帮助架构做更好的分层。RESTful 定义了更加克制的接口，界定了前后端的边界。而 GraphQL 很容易穿透界定的边界和抽象。

2. 使用关系型数据库而不是 NoSQL。

3. 想走得快用 MySQL，要走得远用 PostgreSQL。

4. 除非业务本身需要对接多种数据库，否则谨慎考虑使用 ORM。ORM 通常只支持所有数据库功能的最大公约数，一些特色功能要么不支持，要么要用晦涩的语法。而且你无法精确控制生成的 SQL，影响代码可读性。

5. 新的后端项目优先考虑使用 Go。

‍

最后

写代码，正确性是第一位的，可读性是第二位的，性能是最末位的。糟糕的程序员也能写出机器能执行的代码，合格的程序员要写别人能理解的代码。

代码写得好用处本身并不大。技术总是服务于业务的，要结合业务理解写代码。最好的解法是不加任何额外的代码就能解决业务问题，而能胜过这个解法的则是通过减少代码来解决问题。

Deleted code is debugged code.

---

上面提到的观点在 Bytebase 中也有不少实践，感兴趣可以翻阅我们的代码：

https://github.com/bytebase/bytebase