项目开发心得1

刚刚工作不久，还没有开始从头到尾开发过一个项目，而是负责对一个开发到后期的项目进行维护和后期开发。本以为这些工作没有什么技术含量，比较枯燥，然而出我所料的是，经过两个多月的维护工作，却领会到了很多软件或项目开发领域中的学问，虽然这些东西的字眼和概念原来在大学的时候遇见过n多次，但是从来理解不了是怎么回事。
1.说说需求挖掘，定义和管理吧。我本来就是刚入行，觉得谈这些上流话题有点不自量力。不过在这里我倒也不打算去网上找些资料把有关需求的内容拿来啰嗦一顿，而是说说自己的体会，知识和经验都是慢慢体会和积累的嘛。这个项目负责开发的人不多，需求一直都是通过和客户之间电话会议来确定的，即客户那边有什么要求经过双方讨论确定再有开发人员实现，完了后再转给测试跑跑看有没有问题。这样一直快要到交付的前一个月，老板以为接下来的就是些简单活，就叫我这个新手去锻炼锻炼，顺便看看人家是怎么开发一个项目的。可是就这个时候，众多严重的问题出现了：因为系统即将要交付使用，客户多少会积极一点去试用。结果经常出现错误或者莫名其妙的故障。比如开发的时候当初压根就没有考虑到多用户的情况，所以整个系统的多个地方都只是以单个用户的方式来编写的，比如一个货品的数量在进入一个页面的时候就取出来缓存并显示，然后这个用户在这个页面上逗留了十来分钟，再对这个货品数量进行修改，如果只有一个用户在使用这个系统的话，数据永远都是一致的，没有问题。但是如果多用户的话，结果就可想而知了。这个项目的测试人员也只有一个，当然没有考虑到在多台机上试试系统运行情况。还有，对真正要试用该系统的用户的场景没有事先了解，所以开发人员照着惯用思维进行开发，结果当然是用户提出异议了。还有，在系统开发前期的时候，没有很好考察定义系统的平均或一般负载，性能要求之类的关键指标，即没有考虑到压力测试。用户那边系统后，发现到了快速大量输入数据时，系统会慢得不可使用。除了这些典型的问题之外，还有客户在快要交付前突然要大范围更改和添加需求，弄得我们手忙脚乱也完不成任务。具体情况就不在赘述了。这些经历给我的体会是：需求果然是很难作的，所以要花心思，动脑筋，甚至花体力去尽量做好（比如可以到客户公司去考察考察，呵呵，不知道这个想法实不实际，个人想法而已）。切记一种姿态就是，客户扔了一个需求过来，讨论讨论过了，然后动手，弄完叫客户大概看看，没事就OK了，而是要多Push客户那边多搞搞，不断跟进（好像客户大部分都不是很积极的，所以项目公司这边要积极和客户联络）。不然开发到后期出了前期没有发现的大问题再修改代价就很高了。

2.第二个体会，可以说就是“切肤之痛”吧。写代码比较辛苦吧，看代码好像也很辛苦，但是看一些几乎没有注释且比较乱的代码，并且这些代码还比较多，会不会很辛苦呢？答案是肯定的！大学时候学的一门课程，叫项目管理。那时候学那门课觉得简直就是浪费时间，很难领会到一些要工作后才能领会的知识，好像学来没用。比如书上说，开发一个项目，一般开发时间只占20%-30%，其余都是维护时间。出来工作后才发现维护时间还真的是很长，如果在这段时间里，一直都是由系统开发的那帮人来维护，到也罢，反正代码写的怎么样，他们自己看。但是万一项目的开发人员离职或者调到别的项目组从而原来的项目叫别人去维护的时候，就会发现优良的编码习惯是多么重要啊。我有时候实在觉得摸不透，就去问原来开发这个系统的人，结果有时候他看了之后自个也不知道怎么回事，还责怪我这样写是有问题的，还不时误会是我写的代码。我心里说，原来你刚不理它一个半月就都会不记得啊，呵呵。这些经历给我的启发就是：写代码的时候，想想以后。该写注释的地方，就算简短，加两句以后别人维护起来也省 了好多脑细胞去想那段代码到底是干啥的。

3.哎，太晚了，明天还要上班，有时间再加上。都是自个感受，写出来备个案。