席卷初感

      好长时间没写东西了，今天敲起来感觉有些陌生，加上天生的作文憋脚，就记记流水帐吧。

       我是6月初开始上班,到今天差不多3个月，podcast项目已上线,项目的架构师也已经是第3任(之前有没有我不知道)，可以算一阶段了，其实现在每个人都有想法的,要说没有，那是骗人。不过现在我的思想已经没有什么革新的地方,来时的锐气早已被时间和环境磨掉。

       初进公司，困难挺多，但公司领导、**江以及公司其他同事都给了我技术、业务上很多帮助，这让我迅速融入到podcast这个项目中来。

 

       先说说对项目架构的看法吧。

podcast项目是采用spring+hibernate+webwork这样一种架构, 这种架构开发效率高,具有很多优点,这点勿庸置疑。尤其是hibernate,当前的轻量级框架中功能最强大的，把人从传统的sql语句中解放出来，大大提高了生产效率,其它的优点我也不必多说，网上的说法也是多如牛毛。

但是podcast项目具有周期短、进度快的特点，个人认为这些特点并不是hibernate的优势所在。项目中对象关系映射配置过多，控制复杂，尤其是现在项目的最终定位是个大型网站，要求能支持很多人同时在线，并且要消耗资源少、响应速度快。现在为了提高性能，使用原生sql就是最好的证明。(当然这是后话,我说这些绝不是说我有多牛气，只是我的一些个人想法）。我是个实用主义者，哪种技术实用又比较现实可行，就用哪种，绝不会为了赶时髦使用一些比较花哨、很新的技术，毕竟，技术永远要服从于商业价值！如果真是那样的话，就成了一个纯粹的技术主义者。

      

       说完了系统架构,再说需求吧。其实应该先说需求的，系统架构是很重要，但它也得先服从于任务需求的。

       需求分析是项目开发的基础，基础打的牢不牢直接关系到后面所有的工作，是项目实施成败的关键。总体上说，我们的需求分析是做了，但是做得还不够，我们做的需求只解决了我们能做出这样的项目，但是没有解决这样的项目是不是真的就是客户想要的(就拿方总当我我的假想客户吧)。造成这种状况的原因主要是下面几个情况：

       第一是客户本身说不清楚。其实这不能怪客户的,毕竟客户在软件知识方面不是太多，可能心里只有一个软件的轮廓，于是可能会要求我们去替他来完整这个轮廓的细节，而我们的能力、我们能真正站在客观的角度去思考和整理这些需求，就决定了这个需求的完整性和有效性。

       再就是分析人员或者客户理解有误，未能把真正的需求转化成软件功能。毕竟，不是每个分析人员都是专业而合理的，为避免这种情况情况的发生，需求分析必须要有审核制度。公司人手不足时，要充分的思考和群策群力共同完成这件事情。

       也许我们的需求原先是很有创意的，但还是有些盲目照搬同行的嫌疑，我也其实并不反对借鉴同行的做法，只是这种拿来主义到了我们这里有点变质了，现在感觉有点儿邯郸学步的味道。可能很多地方已经偏离了张波原先的设计。（也许他老人家有更好的方案放在心里说不定呢）

总之 , 需求分析过于笼统或者根本就没有，只关注到面上，没有关注到点上。或者只考虑一个纵截面，没有考虑横截面。有些界面是画出来了，但是到最后某些按钮到底是做什么的画按钮的人自己都不知道了。我说这些决不是指责谁做的不好，只是就事论事 ( 我自己也经常  

犯些低级错误)。另一点需求分析在技术和产品功能这样统一高度的评审上做的还不够，造成一些已经在页面上画出来的功能说取消就取消，或者没有的功能说加就加，有些随意了。需求的不足，已经注定这个项目会有较多不必要的浪费，这包括时间、人力和物力和其它的。需求分析就是要做到全面、详细、准确，违背了它，在后期开发和维护的成本就会成倍增加。

      

       啰嗦半天了，细节的东西太多，一时半会儿也说不清，有些是当时发生时记得。不过，个人认为系统架构和需求分析的不足足以决定很多的细节，就像前面需求分析不足，造成这个月以来反复的修改，以至于就像重新来过一样。（如果我的同事看到了这里，你是不是也这样认为呢）

不能不提的就是时间了。

其它人我不太清楚，我自己吧，像webwork对我来说是新东西，一个项目下来了， 我也有些掌握,很高兴自己又掌握一个新东西。但是假设之前我能熟练用它，毫不夸张的说,可以节省一半时间。如果说我花在webwork一共有两周，那么现在一周也许就能搞定。

       再提一个，就是项目文件以及文件夹的创建了。以前张波在的时候，还管一管，现在基本上全乱了，夹子是想建就建，文件也是乱放(现在我自己也是这样),

说开发工具，人不多，但用的工具绝对五花八门，有jb的，有用ec的,版本控制有用插件的，也有独立软件的,套用前一阵子流行的话说,“I 服了YOU!”,我不是说用某个工具不好，但我想经常发生的发布版本跟自己的checkin对不上号的问题，在现在还不能完全确定原因的情况下还不能完全排除工具的因素。如果用同一个工具，如果发现有bug或者有问题，大家也可以一起来对付，大家的力量总比一个人单独面对一个陌生的环境要好些吧。

 

 

       上面说了些都不爱听的东东，其实我们的优点也不少。没有系分了，还是能够紧密的团结在项目经理的旗帜下，能够很好的沟通，坚忍不拔，任劳任怨，加班加点的，有问题大家还是互相帮助，共同度过难关。

      

       我的遗憾：首先因为是半道出家，我没有参与过早期的系统设计，也没有这个机会锻炼自己，在这方面我欠缺的挺多，跟大家有差距，今后需要努力学习学习再学习。

       我在linux系统、以及开发部署方面我一窍不通，更要加一把劲。有时我不太注意跟大家沟通，这方面需要改进。其它的缺点也有一堆，就不再讲了。

以上只是我的一些个人想法或者感想,如果有讲的不对或者冒犯了阅读到这些文字的领导或者同事，还请多多原谅。

完稿2006.08.30完稿