微型公司小团队对软件项目开发管理和规范化的思考

一、前言

        这里指的微型公司、小团队是指两个人，或三个人的情况。人虽少，但只要达到两个人或超过两个人，就必然面临沟通、配合协调的问题，这时候就得考虑管理的问题，软件工程、项目管理、开发标准等等。

        但这样的公司规模小，项目利润不大，都是干活的人，完整规范的软件工程管理体系是没法直接使用的，如果按标准管理来管理，那还得增加不少人，项目的费用还养不活这些人。

        所以很多时候就忽略了管理的问题，只顾得上应对需求、BUG、开发代码，处于野蛮、无管理的状态。

        这样随着维护周期变长，人员变动等，就产生很多问题，如记不清为何要开发这个需求，要改一个功能点时不知道怎么实现的，要读很多代码，而且代码还零乱，注释不清等问题，一头雾水，改了这儿引发那儿bug，最后不敢改代码 。

        本人所处的就是这样的情况，带着一两个、两三个人维护着一个产品和几个客户，面临着上述的问题。

二、变 革

        由于最初只有我一个人在开发维护，所以所有代码都是我本地存储开发，后来加人也没做SVN管理，都是要改那个模块就把代码复制过去，改完后再传给我，但后来各自都很忙，新版本就没传给我保存，最近，其中一个开发硬盘废了，导致他近几个月改的东西都丢了，损失有点大，全部重写。

        另外就是看看这几个大家维护的代码，零乱，互相交叉维护时，难读懂。基于这些原因，让我不得不把管理这个问题提高到和解决项目BUG一样的高度。

        虽然网上有不不开发规范、还有完整的软件工程管理模式，但很明显这些是不适合我们这样的团队的，我不得不思考和摸索一条适合我们的管理之路。

三、管理之路

3.1、SVN版本管理

        只要达到2个人，就一定要建SVN管理。前期是因为代码多，零散，觉得建SVN麻烦所以一直没建，最后吃亏了。亡羊补牢，就先把最近维护过的代码建进SVN，后面逐一加进去，这样即进行了SVN管理，也不至于造成一开始就把所有代码加入SVN需要很长时间。

3.2、关于开发规范

        只有适合自己的才是最好的，太多的规范学习成本高，如果没能践行也是摆设。我们就一点点的建，从命名、注释、类的封装、风格，大家根据自己的经验，把遇到的觉得有用的说出来，讨论下写上去，逐步完善，边写规范，边开发。

        就像对中文取英文变量名的小事，我们把常用的词汇都写上去，大家命名按这样命，这样统一风格，读代码效率更高

3.3、关于文档

        我们是处于几乎没有任何文档的状况下。没有需求文档，没有设计文档，就项目初期做了数据模型文档，但有时加了表或字段都还没同步，都是用户有需求了，想想就coding，编译发布上线完成，这对维护、人员变更造成的麻烦是相当大的。

        都知道有清晰的文档是好事，但实际情况一是写文档要成本，另一个是程序都不爱写文档，就像有个笑话说的“程序员最讨厌的就是写注释和骂其它程序员不写注释”。而且写文档也是个技术活，程序员大多是理工思维，文字工底不佳，心里知道是那么回也，但写不出来，写出来也没清晰、完整、准确的把事情描述清楚，所以就更不愿意写，觉得浪费时间。

        不过经过交流，大家还是意识到文档的重要性的，这是个好的开始，接下来是怎么写的问题。经过讨论，我们肯定不能按规范的软件工程那样把《需求分析》《概要设计》《详细设计》《操作手册》都写出来，要这样写，我们都要饿饭了。

        目前确定了写两份文档：《功能说明文档》《代码逻辑说明文档》

1、功能说明文档

        这个文档主要偏重业务和操作层的，是个四合一的文档，一个功能模块配一个文档，主要包括以下内容。

• 本功能具有的主要作用        便于新人了解功能用来干什么的
• 本功能的应用场景               述述该功能什么人用，在什么情况下使用
• 功能注意事项
• 需求描述                           为什么有这个功能（或功能点）是解决用户的什么业务问题
• 实现说明                           简要的写一下代码怎么实现这个需求的
• 操作说明                           基本操作、特殊操作、相关设置等，避免时间长了，自己都不知道怎么操作，或其它人接收时查看

2、代码逻辑说明文档

        这个文档供代码维护时使用。主要描述清两部份内容：

1、功能中主要的类和互相的关系

2、主要流程方法调用关系图

        描述各主要方法的作业，主要实现说明，调用的其它方法关系

3.4、注释

        写注释的时候，尽量多写为什么我们要这么做，而不是去描述这段代码干了些什么，干了什么在代码中已经写的很清楚了，不要试图用注释去掩盖糟糕的代码，请重构你的代码。

       有用的注释

        1、概述性注释：对类进行简要描述，解释类主要实现的功能（或方法的主要功能和实现步骤）

        2、代码标记：用于提醒开发者有哪些地方未完成，有哪些地方需要注意，但是请采用合理的，固定的标记

        3、代码意图说明：目的性代码用来说明一段代码的意图，它指出要解决的问题，而非解决的方法

        4、传达代码无法表述的信息：例如与代码设计相关的注意事项

3.5、执行

        目前新开发的任务，按上述要求进行执行。

        收到需求后，即开创建《功能说明文档》中的需求描述，然后按《代码开发规范》进行编码，在编码过程完善《功能说明文档》。

        功能开发好后，进行代码检查，优化重构，然后编写《代码逻辑说明文档》。

三、结束语

        在整理开发规范和文档期间，也发现管理成本确实高，在成本与收益上如何平衡，本次的尝试能否有效果，期待着看。也欢迎大家讨论，提出好的建议。