项目总结

 

      现在项目已经接近尾声，正在进行结合测试，因为时间还算充裕，所以趁这个时间将这个项目的情况总结一下。

      项目简介：F项目 该系统主要针对日本的公路管理局的库存物品进行管理。既然是库存管理，就不外乎是下面几个方面，物品的购入、借出，折损，丢失，修理等各种情况，当然，还有必不可少的盘点和各种报表的输出。这或许是公司目前为止所接手的为数不多的自由度较高的项目中的一个。毕竟是对日外包，多数情况下不但设计书已经写好，甚至连框架都已经在日本写好了，我们要做的只是将设计书用某种语言再翻译一遍，字面翻译就可以了，如果想优化，还要再跟日方进行协商，这无疑是相当繁琐的事情。而在这个项目中，拿到设计书的时候差点疯掉，连概要设计都算不上，只是SQL文的简单堆砌。语言竟然是早已过时的ASP。无意辩论哪种语言的优劣，但现在的时代崇尚的是快捷开发和便于维护，但一个400行的SQL还要用字符串拼接起来，想想以后的修改和维护不由得让人不寒而栗。在开发完几个小的页面之后，终于对语言有了定论，采用ASP.net，后台语言是C#。

    后面的开发还算顺利，因为功能相似度很高，不得已，代码的重复率也随之上升。我负责开发的前两本程序，第一本用去接近两个月的时间，而第二本只用了两天就完成了。但是现在想想，是不是可以重新设计后提取更多的共通呢？显然这是可行的，但因为项目进度问题，（更确切地说，是意识问题），这种臃肿的方格就一直保持到了项目的结束。

    还是分点来描述吧。

    教训有以下几点：

    1.设计缺陷。详细设计不是基本设计，它所关注的不仅仅是业务问题，还有编程细节问题。平台、构架、语言、接口这些方面都是应该加以考虑的。

    2.共通的抽取和重构。在平台和构架确定的情况下，分析业务和机能的重复点，重叠处，然后抽取共通，确定接口。接口应该形成完备的文档。

    3.性能问题。这或许不是代码实现的首要问题，但绝对应该是设计阶段的必选项。一个页面显示5000条记录，每条记录40个项目，每个项目都用文本框进行表示，这种规模着实考验了一下浏览器。但不幸的是IE6并没有经受住考验，立仆。更让人崩溃的是5000条的显示还是默认显示！相较而言，其它浏览器的表现都要好很多，但没有用，用户的浏览器都是IE6和IE7.没得选，改变可以改变的，接受不能改变的。另外，数据超过2万的几个表连接，我们就应该进行一下压力测试。改一下SQL的写法，也许就是几百倍的性能提升，这不是开玩笑，项目在后期，不得不将所有的查询语句全部重写了一遍。这不是有意思的事情，特别是那种几百行的SQL，简直就是噩梦。

    如果说有值得称道的地方，应该说管理还不错，工程化的优点也可以体现：虽然没有高手，但项目还是艰难地完成了。

 

    同事竟然搜索到了项目名称，不得已，删除之。