软件开发二三事：Git、软件设计和文档评审

现在大家逐渐都认识到Git的好处，并在工作中使用了。这为工作提供了不少的方便。

在软件开发初期，新手经常会折腾代码，比如不知何故软件无法编译了，不知何故软件无法运行了，从而不得不重建工程：新建一个目录，重新创建一个工程，把文件复制过去，看能不能编译、运行。这也这是不用Git的后果：在无意识间改动了代码或工程配置，导致工程不能正常运转，但没有办法找出来到底改动了哪里。

但随着开发的深入，这种折腾的代价会越来越高，风险也越来越大，很有必要用Git来保驾护航。利用Git管理，使改动精确可见，从而使软件开发步步为营，稳步推进。

Git的使用也使大家不一定挤在一个屏幕上看代码，代码的获取更加容易，因而可以把代码拉到自己的电脑上慢慢品味。也使代码共享变得唾手可得，协作开发变为现实。

再说软件设计，这里存在一个小小的悖论：对于新手，大家希望软件实现之前好好设计，这样可以使软件实现更容易一点，从而也降低了风险和不确定性；但对于新手来说，软件设计恰恰是最薄弱的一环。想想也是，他都没做过软件，何来设计呢？设计，应该是对有一定的开发经验的人来说的。由于有了一定的开发经验，从而知道有哪些工具、模块、库可用，也知道哪些是软件能做的，也知道哪些是容易实现的，在此基础上，合理地设计一个软件。这恰恰是新手缺乏的。

所以，对于新手来说，可能有两个途径。一是采用演化的方式，边学边设计：能理解到什么地步、能看到什么功能，就先做什么，让软件逐步成长。随着理解的深入，同时也随着软件技术的进步，再逐步重构软件，使架构更加合理。二是由经验丰富的人进行设计，然后有新手进行实现。

这称之为培养的代价。

进行了一次设计文档的内部评审会，效果并不很好。如果要找三个原因的话，我想一是会前准备不充分，没有认真看要评审的文档。这样导致效率略低；二是没有采用最新的文档，从而阻止了有效的评审；三是对会议的组织和会议进程的主导缺乏经验。

对于设计文档来说，可能会下的小范围讨论或许更好一些，比如可以边讨论边改，可以慢慢地去琢磨，而不耽误大家的时间。

这也是一个可练习项，需要不断的琢磨练习。