第一次开发软件个人总结

项目背景

该项目源自于实验室从政府所拉到的项目，所属软件类型为网管软件。

本项目的特点主要有：

1.项目时间短，需要在四个月之内完成从需求到交付的一切工作。

2.缺乏实际的测试平台，由于硬件设备等诸多方面的原因，软件的核心——监控部分得不到好的平台来测试，只能做一些模拟测试。

3.客户需求定义很不明确，经常随着时间的变化而更改（这点是从后来客户不断地变更之前已确定的需求中得知，并非事先能完全猜中，当然咯，需求变更是一件很难避免的事）

项目开发过程

 

在该项目的初始阶段，我负责需求规格说明（SRS）的编写，并基于SRS来讨论数据字典的攥写。这里有一个小插曲：本来我们组由于我这个新人只会C++而打算采用C++来实现这个系统，但由于C++复杂的框架构建和繁琐的语法，当然了，VS2008的IntelliSense基于C++的也实在是太弱了，最终由师兄采用了他所熟悉的C#语言来做架构。

 

这个时候老师列出了整个项目开发过程的时间表，我在下面列出以供大家各自思考和分析：需求：20天；设计和实现：2个月；集成测试：1个月。这个时间安排方面老师肯定会故意安排的很紧。

 

接着在导师的要求下，我编写了概要设计文档，师兄曾说这个文档完全没有必要，因为没有不变的需求，设计肯定会根据需求而变化的，这种设计根本没法确定，这可能也是现在很多软件开发提倡更多的敏捷的原因吧。后来的事实也证明这个举措对项目来说没有任何意义，这个项目直到进入维护期了都没有用到过该文档。在项目总结中我会提及对于软件开发文档个人的理解。

 

在需求“确定”下来后，（这个时候已经延期了将近两个星期），我们根据需求把要开发的软件分成了许多模块，在这里要注意模块的粒度，过粗则会复杂，过细则会繁琐。然后画出甘特图来做出初步的开发顺序和任务计划，并且要求开发人员在开发完模块后必须要做单元测试。（这点很有必要）我们的架构考虑到项目特点1故只分为四层，而没有做更复杂更灵活的架构，Common层提供基础服务，Repository层提供MySQL数据库的访问，Service层提供各种业务逻辑方面的服务，UI层提供界面。（在这里感谢师兄，他真的教会了我很多。。。）

 

接着我描述下我具体的开发工作：设备部分的配置、全部设备的监控和设备状态的查看。考虑这一块是个紧密相连的部分所以就交给我一个人了，刚开始我有点担心工作量会很大，事后发现，错误的项目管理和松散无序的开发对软件的开发所造成的损害要远远超过了更多的工作量所带来的损害。

 

我利用了SnmpSharpNet这个开发包来做SNMP协议下的监控。在网上没有人讲这个开发包的具体经验，明天我将专门写一篇博文来讲解自己的经验，不一定对，但绝对经过了N遍的尝试。。。在刚开始的多线程监控中，我错误的设计了监控部分的修改直接去读取数据库，造成了不可避免的线程间冲突现象（可能一些大牛处理好的话能够解决，但不必要的读取数据库的操作所造成的耗时对网管软件来说难以接受），直到后面被建议用缓存才解决这个问题。多线程我对数据的冲突的处理经验就是加锁，当然咯基本类型的话是加volatile。对volatile的详解可以看本人的另一篇博文，这里。在监控的地方我做了多次，基本上每次都是全盘否决之前的做法。。。网管软件的开发确实有一些特点，建议大家以后开发之前一定要去多问问别人的实践经验。我的错误经验也会在下一篇博文中详细说明。o(╯□╰)o

 

我个人部分的模块开发在此就不多说，没什么技术含量，我监控得到的信息要提供给图像的界面处理部分，所以我利用了观察者模式来实现另一个同学要去的接口。以下分别为接口和观察者，另一个同学只需要在它的类的构造函数中加上Observers.Observer= this;并且继承接口INotifiable就可以定义接口函数Notify(A a)了。

namespace Services
{
    public interface INotifiable
    {
        void Notify(A a);  //另一个同学要求的接口
    }
}
namespace Services
{
    public class Observers
    {
        public static INotifiable Observer { get; set; }
    }
}

就这么开发完第一个版本后，比原计划只延期了一个星期，可后来的集成测试和需求的变化导致这一切看来都是表面的美好。在后面的时间中，我不断地根据新的现场测试情况（项目特点2）来调试监控部分，并不断地修改底层代码来应对需求的变化，项目管理的错误在这个时候逐渐显露，做的很多事情没有道理，只是无意义地强调表面现象，而错误地管理下的松散无序地开发也造成了代码质量的低下。最终就这么拖啊拖地应付了一个个版本。客户的不满度也越来越高，所带来的压力也导致管理者不敢去实施代码的重构，很多冗余的代码就一直存活着，大家就开始在沙滩上建房。。。（见代码大全2关于软件开发的比喻）软件开发就这么进入了恶性循环。。。

项目总结

在这个不太令人满意的项目中，我深切体会到了几点，现在跟大家分享一下我血的教训O(∩_∩)O。

1.一个有经验的项目经理实在是太重要了。不然每个人都感觉不到信心而失去认真度。兵将熊的典故我就不说了。

2.开发代码需要用全身心，每一个提交到SVN的代码一定要认真核实并加上注释，而我却因为某些事情敷衍和消极开发，结果就是现在越来越难挽回。

3.自动化单元测试很重要，可能之前会浪费一些时间，可对于软件开发的成熟来说十分必要，磨刀不误砍柴工。请您这么做吧。

4.小组互审代码很必要，互相抽查核心代码对于我们这种在校的小开发团队来说很必要，尤其是没有自动化单元测试的情况下。

5.永远不要怀疑重构。可能短期内会出现问题（这个概率很低），但是长远考虑换回的是代码的精简和设计的清晰。

6.开发团队的互相协作和沟通是必须的，决不能因为接口的确定就互相不沟通了，结对编程的重要类似于此，旁观者清。

附注：之前提到要走总结中写关于项目的文档的理解，昨晚走的比较急，就落下了，现在补上。

个人建议：软件开发中，软件需求规格说明、数据字典、架构说明和模块设计说明（概要设计得看具体情况）、测试用例和问题报告是必须要的。用户可能还会需要帮助手册和源码说明。注意：文档有时候比代码更重要。

--------------------------------------------------------------------------------

版权声明
本博客所有的原创文章，作者皆保留版权。转载必须包含本声明，保持本文完整，并以超链接形式注明作者s5279551 和本文原始地址：
http://www.cnblogs.com/s5279551/archive/2010/09/19/1831260.html