度量模块开发经验总结

出现的问题:

1. 不能按时完成个人任务。
2. 反复被open了一些bug。
3. 不敏捷。

[@more@]

总结:

1. 未能预见到页面部分会有如此大的改动，因为刚开始做页面原型的时候，所做的原型完全考虑到和后台数据的交互，没有能多想一些，在没有考虑清楚的情况下，就动手写了代码，事实上证明这些代码完全是会被推翻的。一定要在大脑中想的比较清楚的时候才开始写代码。
2. 接口一定要定义的非常明确，宽泛，否则单独给每个所需要的很小的功能所写的方法，最后会出现好多地方都不能服用这个方法，因此在最开始的时候，定义方法要把接口定义的宽泛一些，这样才能带来灵活性。重复的代码是不允许的。我所总结的消除的方法是：抽象；宽泛。
3. 交流在软件开发过程中是非常重要的，如何和需求人员有效的沟通，可以把一些bug避免在最早的时期，这样就能把后期的改动量减小；如何和测试人员有效的沟通，可以减少一些对bug的误解。
4. 工作的软件，即实现的功能点是决定首要的进度度量标准。在开始的时候做的很多仅仅停留在页面上的东西必须和最后的完整的功能联系起来，才能实现持续交付，不然的话，风险是留在的最后，这样是不能达到敏捷的目的的。经常交付可以工作的软件，这样才是比较敏捷的做法。这次的开发其实有个很好的契机，因为需求人员，测试人员，开发人员是在一起封闭开发的。但是由于没有能做出经常可以交付工作的软件，所以形成了恶性循环。
5. 代码的设计一定要用最简单的方法，最容易理解的设计。在团队协作的情况下，首先是简单明了，其次是效率。多加一些注释和坚持使用最简单的实现逻辑将会给修改和重构的时候带来很大的便捷。我觉得任何一个方法如果超过了100行的代码应该都是难以理解的，松散耦合的，有特定含义方法名称的小方法比长篇累牍的裹脚布好多了:)而当重构的时候，裹脚布只能全部脱下才能换上轻快的短袜，这样会有巨大的重复性劳动！！！
6. 单元自测，在写代码的时候能够使得自己对所写代码有相应的测试代码，这样能够保证在以后代码重构后，一方面在修改过后代码运行测试代码，观测是否通过；另一方面，保证修改过后和其余代码的契约仍然能够不变。
7. 分解--估算。当分到度量报告这个模块的时候，乍看上去，觉得就是4个或者5个主要的页面来回的切换。但是这个估算是致命的!当对一任务要完成的工作产品的功能进行越细粒度的划分的时候，那么对于这样一个工作产品的度量也就越准确。首先:我粗划了一下，就第一个页面而言，从页面原型上，它包括：度量报告基本信息；度量指标基本信息；系统基线选择；图形区显示；问题建议与分析；相关文档管理；保存；打印；退出；继续细分，从功能上： 以文档管理为例，它包括：文档的上传，下载，删除，保存。上传又可以细分为：在界面上显示上传的文档，转化文档为字节流，使用webService把字节流在服务器端恢复，更新数据库。这样4个基本点，如果能把每个大的功能细分到这样粒度的小功能，然后从中挑出一个最难的点，一个最容易的点，一个中等难度的点，来实现，这样就能得出自己的效率，从而对整个工作的产品的实现时间做出评估。逐渐养成这样的习惯，就能提高自己的设计能力和对软件过程的控制能力。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/9829210/viewspace-914217/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/9829210/viewspace-914217/