开发规范

本章介绍开发规范,阐述了一些规范性的思想及原则,这些规范将贯穿于整个开发过程中, 以期望团队成员能够通过应用与实践来提高代码质量,增强代码交付能力;

这一章同时也规定了数据库表及其字段的命名规范等。团队成员应以此作为参考。

原则

  1. 软件工程化
  2. 模块化
  3. 能简单不复杂
  4. 强调团队协作

关于版本管理工具的使用

出于以下考虑,本项目所使用的版本管理工具为 Git。

实际上,工具神马的都是浮云

Git 之类的分布式版本管理系统 (DVCS) 就是神器吗?不,充其量也只是另一个 VCS 或 SCM, 所谓的分布式、轻量级分支神马的在某些人看来或许是扯蛋的玩意,人家可能用 SVN 用得不知有多爽多出神入化呢。 如果仅仅是因为要推广一种新工具而去推广 Git,那一定会得不偿失。

真正重要的,是驾驭在工具上面的灵魂(思想),有些人虽然用着 Git,但只把 Git 当作备份工具用; 有些人尽管还用着古老的抢占式的 VSS,但提交的守则却是规规范范,标签打得清晰有条有理! 前者不管用什么版本管理工具,都是 YAST(Yet Another Scm Toolkit), 而后者不管用什么管理工具,都能把代码版本管理得齐齐整整。

不要把版本管理工具当作代码备份工具用!否则,需要的只是 Dropbox。

既然工具是浮云,那为什么还选择 Git?

当团队开始有了强有力的版本管理意识支持后,就会下意识地选择方便趁手的工具, Git 实际就是这么一种工具,适合各种各样有洁癖的人、提交狂人等。

规范地使用 SCM 才是正经事

如果团队已经习惯把 SCM 当备份工具用,那么这就是一个推广 Git 足够好的切入点。 那么如何判断一个团队是否把 SCM 当作备份工具了,有大概以下几个可供参考的现象:

  1. 一古脑儿的提交文件,有时一个文件,有时十几个文件,多个功能点一齐提交;
  2. 提交备注信息的特征有:“略”,“提交一些代码”,“fix 一个 Bug”,“今天的代码”等;
  3. 从来不给代码打上版本号,程序从头到尾只有唯一一个版本,就是 Now;
  4. 遇见冲突就慌张,不懂处理,等等。

使用 Git,目的不是为了炫耀什么,说这是一个很潮的东西,大家就跟着用吧。 使用 Git 目的是要彻底改变团队把 SCM 当备份工具用的习惯,是为产品代码质量负责。

代码版本管理,最终目的是要实现代码版本的可控性,不仅包括大至版本级的重取,还包括功能级别的增减, 甚至是小至 commit 级别的回滚。用以达到这种可控性的其实是一些规范,而非 Git 本身 (当然 Git 及它的扩展 git-flow 立功不小)。

写在最后

如果对这部分内容感兴趣,可参考这篇文章:一次优秀的代码提交应该包含什么?

results matching ""

    No results matching ""