we loving Blog

2010/01/21

从零开始做项目

分类: ├ 项目总结作者：良良

1. 概述

从大学毕业到现在，从一开始的不知所措的代码小兵到现在的项目leader，已经有两年多的工作经验了。在此之中陆陆续续做了这么多项目，在怎么做项目，怎么做好项目方面自己也有一些感想和总结。从09年开始，自己也坚持每个项目完成后做项目总结，分析一些项目出现的问题，总结一些成功的经验。点这里查看项目总结存档

以下是一些怎么做项目和怎么做好项目的总结和感想。这里主要是对于项目的制造，代码review和测试而言。

2. 具体描述

2.1 做共通

代码制造阶段首先着手的应该是从总体上来看一下这个项目，有什么样的特殊需求，根据经验来分析这个项目在那儿会有难度，在那个地方会有技术难题，并生成一个待解决问题一览（※文档1）。在一览中有四栏，分别是“问题描述”，“解决方案”，“优先级”和“备注”。在以后的制造中可以往一览中添加问题，在解决的时候也不是以列表顺序，而是以优先级得顺序去解决问题。解决后把该一行背景色变灰即可。这个一览的文档应该维护到所有的编码结束，并把所有的问题都灰掉才算生命周期的结束。

其实一般的项目的共同代码，也就是基盘差不太多，差就差在编码语言的区分，和业务的特殊需求。在公司项目的积累上，可以形成每个语言的一套基盘代码，如果客户或者没有特殊的安全考虑的话，可以每个项目都利用这套基盘，并且一步一步的去完善，最终形成一个稳定的成熟的基盘。这样既可以减少项目的时间，减少成本，有增加了代码的可靠性，减少了风险。

基盘代码设计的一些方面：

a 错误处理：

（1）错误信息的管理方式（数据库或文件或硬代码）

（2）错误信息的显示方式（转向错误页面或者警告框）

（3）异常处理（需要自定义异常，异常做到什么程度）

b 入力检查（1）客户端检查（2）服务器端检查
c log （log格式，如何分级以及各级写log时点）
d DB连接（采取什么样的方式）
e 权限（如何分级，权限验证做到什么层级）
f 代码编写工程目录及层级关系（需要分几层）

2.2 做业务代码

前期的共通基盘的作用就是为了编写这部分代码的时候可以更省力，更省心。在编写业务代码之前，要做好编码规约（※文档2）的教育。在每个项目中，每个人的技术水平总是参差不齐，教育编码规约的目的就是让每个人都了解定好的代码风格，比如注释，异常，怎么缩进等等。这样到最后做成的代码才像一个人写的，后期换人维护的话也减少很多成本。做好编码规约的教育也很大的减少风险，比如到最后才发现一个没有解决的问题，在解决这个问题时，为了尽可能少的影响到现有的代码，所以尽量做共通去解决，这样如果大家的代码一致，才有做共通代码的可能性。

在做业务代码之前，最好是有前期作业，比如在做共通代码时，就需要有人去研究一本不大也不小的程序。并且着手编写。只有在编写的过程中，才能发现一些东西，并且和做共通的人协作，两者相互促进的进行。做完一本之后，一定要进行review，和简单的测试。在这个过程结束之后，编码规约，程序架构等等都已经定下来了，其他的代码参考事前作业，问题也就不大了。

在做每一本的时候肯定会有各自的问题出现，问题的解决可以按照项目的具体来看，如果进度比较正常，可以自己解决，并且反应给自己的上级，如果工期比较紧的话，可以设置一个或者两个人去专门解决问题。任何人发现问题可以反映他们，解决问题后全组展开。如果人手又不够的话，可以每天反映给SL，SL在调查之后，全组展开。这样既不不影响进度，又能最有效的解决问题。问题的记录放在”横展开一览“（※文档3）中，并在每个人完成后签上自己的名字。可以有效地控制是不是每一本都对应了。

2.3 review

review是项目过程中一个非常重要的环节，如果它做好了，可以很有效地去控制bug数的产生。如果他做不好，那么会在测试阶段发生很多浅层次的问题，而深层次的问题缺没有时间去发现。review之前应该对应完所有的横展开，做完self check list（※文档4），自己对照式样书一遍，不要让review者看出一些很低层次的问题，这对自己也是一个比较好的自我检查。review者应该是有经验的人去做，能尽可能的，并且尽早发现潜在的问题，尽早的发现问题所花费的成本总是最低的。review出来的问题记录在review票中（※文档5）。在review完一本之后，有必要的就要添加到横展开一览中去了，让其他的人或者后来的人避免这些已经意识到的问题。每一本review的时间不一定要有所规定，原则上是讲直到看不出问题来了，才算review结束。如果一本程序做的很差，那就要进行中间review，或者是二次review，甚至更多。在review完成，担当者改完之后，review者一定要做好确认工作，看看是不是没有问题了，是不是每一项都横展开了。

2.4 测试

测试没什么太要说的，写好了测试书，按照每一项去测试，有bug就填在bug票（※文档6）里就可以了。我个人认为谁写的程序就让谁测试。因为只有自己才是对于这本程序的人，只有自己才能发现深层次潜在的bug。只有单体测试时不够的，因为它太依赖单体测试书。单体测试书写的好坏直接影响到测试的密度和成败。在单体测试完之后，要有强化测试和结合测试。强化测试是有经验的人猜测bug会在那儿，去看看有没有其他项目中常见的错误，用乱跑的方式去测试。结合test即是整个系统结合起来测试，看看有没有理不通的部分或者程序。这两部分对于发现潜在的bug是很有效的。