第一次项目总结

从7月7号开始，到9月3号，在公司作了一个日本的.net项目，两个月的开发实践，学到了一些新鲜的东西，写出来，留作以后的参考。

一：项目开发流程中的一点体会

1：项目的前期准备

从7月7号开始，基本是到了7月20号才真正的进入状态，7月7号到9号，是日本那边的合作伙伴向我们讲解项目的大概流程和开发规约，感觉上日本对这种规范性的要求要比我们国内的项目要求高很多，因为上半年在学校参与了学院开发的一个国内项目（只待了不几天就来公司），虽然在设计上我们做的比日本好很多，不管是数据库还是安全性，但是我们的开发规约做的没有他们好，可能这个也是我们要向日本软件学习的吧（我对日本唯一的一点好感就是他们做事很细心），设计上他们也是订的很死的，基本的处理逻辑和页面要求都已经做好了，我们只要按照他们的设计要求，把逻辑功能实现就可以，这个有有利的一个方面，那就是整体的开发比较规范，最终的效果也很好，但是这也给详细设计带来了麻烦，这个项目中感触最深，因为那边的设计人员对.net也不是很了解，所以有些设计还是按照老的设计思路来的，在有些地方反而制约了asp.net的优越性，这里我想说的就是做设计虽然不能局限于实现技术，但是如果对实现技术了解很透的话，那设计出来的东西不管是对于实现人员还是最终效率而言，都会有很好的效果。另一个方面，是对于这种面向对象开发来说，一定会牵涉到很多公用类，公用控件(日本的开发规约中定义为“共通函数”“共通控件”)，这个项目是由上海，杭州，大连三地共同开发的，所以，为了保证项目的一致性，这些共通的东西也是有必要事先定义好的，这就带来了一个问题，“共通的东西必须要正确，而且要符合我们的要求“，但是事实往往不是我们想象中的那样，实际做的过程中，有很多的时间都是浪费在等正确的共通上，而且日本项目有个特点，不会一次把需要的东西给你，所以这个过程中浪费了很多的时间去写一些我们要求的东西，但是突然有一天来了一个共通的东西，把你的代码实现的那部分功能实现了，你还得必须改你的代码，适应整个项目规范的要求，开发中有大概两个多的星期，项目组都是处在这种状态之中，所以，我想如果能在项目开始的时候就把这些东西确定的话，可能整个项目可以做的更加好一些（呵呵，只是想法而已，实际中总会有这样或者那样的问题出现的，这个过程中，也锻炼解决问题的能力，所以以后还得做好准备继续郁闷）。这些东西做好以后，项目经理就开始做schedule了，关于schedule，我觉得这个东西的实际作用不在于一定要把你的时间定的死死的，必须按照日期一天天的定点完成，这次项目感受更是深刻，因为项目组成员大多数是新手，大家都在很努力的在做，但是有时遇到的技术问题的确让人痛苦欲绝，在项目快要结束时，才真正的明白了schedule的作用，“明白要干什么，做一个参照”，因为在没有实际做时，很难能真正的把握要做的东西的难易程度和可能遇到的技术问题，虽然理论上没有实现不了的东西，但是这个解决过程的确让人有点头疼，你不知道什么时候可以想出解决方案，这时如果在想着schedule中规定的时间，那我觉得这种压力真是让人受不了，所以我觉得并不用完全的在脑子里时时想着那个schedule，可能这个问题解决用的时间比较长，两天或者三天，但是下次再遇到相似的问题，只需要用一个小时就可以解决的，那么这次超出schedule的那部分时间可以在下次补回来，最终仍然可以按期完成。在制定schedule的过程中，我觉得这个也要求一个项目的管理者必须对整个项目流程，项目组成员情况，对合作伙伴的态度，在一个项目最开始的时候就做到了如指掌，这个可能也是一种理想情况吧，我想我们这个项目组经历了这次的开发训练，在下次的合作中一定可以有更好的成绩，毕竟我们还是第一次合作，也都是第一次接触实际项目，经过这个磨合期，我想以后的配合与沟通会更好。

2：开发进行时

经过前期的准备，到了实际的开发，这个过程也是真正的体会“痛并快乐着”的生活的时候，这个过程，有被一个技术问题折磨得死去活来的忧郁之时，也有问题解决后的欣然自得的狂欢之时，好比每天都是在从地狱到天堂，在从天堂到地狱的循环旅游，个中情怀，也许只有我们这些平凡的程序员可以体会。这个过程中，真正学到的，不只是一项技术，我感受最深的是一种解决问题的态度与心态，一个好得工作习惯，这些都是以后受用无穷的珍宝，因为知识永远都是学习不完的，关键问题是怎么去学习它们，并把这些东西用到实践中去，解决实际问题，整个开发过程中，遇到了很多很多的问题，不管是技术上还是语言沟通上。业务的不理解，导致程序逻辑本身的错误；技术的不明白，导致很多的实现不知道如何下手，这些都曾经一度的让我心灰意冷。公司和学校毕竟有很多的不同，学校可以随便的放弃，公司不可以，要做的必须要做好，这个是一个责任问题，出来的这将近两个月，的确是体会到了“责任“两个字的份量，可能这也是一种做人的态度吧，初入社会，我想有很多的东西都是要我们好好的观察，用心的去想，努力的去做，这个是我决心出来的初衷，所以更要好好的去做。开发中，经历最多，感受最深的可能就是阅读那些如天书般的日文外部设计书，和看着那些稀奇古怪的界面时脑子一塌糊涂的情形，两个月的开发中，也有了一些编程体会，和一些不能称上经验的“经验“，在拿到一本新的设计书时，首先要做的就是静下心好好的去理解，这个项目中走的很多弯路，很大一部分都是这个原因，太心急，往往在没有清楚地理解需求时就开始编码，在写了很多的代码之后才明白原来从根本上就已经出错了，这个过程其实是在白白的浪费很多的时间，如果能在开始画上一段时间好好的理解清楚需求，可能在实现时就不会那么的盲目，反而可以缩短开发时间。另一个体会就是在遇到难题时如何去面对，真正的开始去做时，会遇到很多的技术难题，如何去思考这些丝毫没有头绪的难题？这两个月的体会就是，首先，好好的想想自己以前做过的程序代码，是不是有相似的问题，那时是怎么解决的，和这次的问题有什么相似之处，不同之处，可能立即得不到正确的解法，但是可以给与一点点启发，就如这次关于修改时用到的javascript代码，其实其本质上都是一致的，只不过在不同的地方有着不同的表现方式罢了。再者，看看同事有没有做过相似的功能，这个就有点代码重用的意思了，可能自己钻研了好几天的实现方法，别人已经在好久之前就已经实现了，在项目开发中这个尤为重要，毕竟有个时间要求，不像在学校那样纯粹的为了学而学，项目中就是要求按时保质保量的完成客户的要求，这个就是目标。如果这两种手段都已经用过了，仍然没有找到解决方法，那就该借助“帮助“文件和网上资源了，这个是学习新知识的一个重要途径，自己知识在多也不会够用的，必须借助很多人的力量来完成一项任务，网络正好可以提供这个条件，所以能好好的利用支援也是一个很大的优点，特别是在项目开发遇到极端困难的难题时。现在觉得书本上的知识虽然系统，但是他面对的是最广大的学习者，所以在某个问题上不会阐述太多，但是我们遇到难题的地方往往就是这些特殊的地方（在做了两个星期以后，一般得问题如果也成为了技术难题，哪该好好的去反省一下了），所以对于书本，当作入门的东西还行，项目中的问题还是很大一部分借助网络的。如果这还是找不到需要的答案的话，那只好拿出杀手锏了：问这个方面的高手。之所以把这个放在最后，是因为项目中每个人都有自己的一部分职责，高手也有自己的任务，如果不到万不得已，不要去麻烦他们，到了问他们的时候，真的该好好的去反省一下了，实在是找不到方法了么？如果是的话，那么在问他们的过程中一定要好好的领会高手是怎么思考这个问题的，为什么他们可以想到要这样解决，而我就不能想到，是经验问题，还是技术上根本没有掌握好，下次遇到问题时，不妨也按照他们的思路来考虑一下问题该怎么解决。如果经过了这些步骤还是不能解决这些问题，那么就只有一种可能了，人品问题，老天看不上你了，要绝你路，呵呵，不过这样的时候不会很多，真是到了这种地步，就该和设计人员好好的沟通一下，拿出我们可以解决的方案来。总之，没有不能解决的问题，只有暂时没有思路的问题。一步步的来，总会找到一种解决方案的。另一个重要的方面，测试，现在我觉得我最欠缺的就是测试，可能与细心程度有关，总是忽略一些细小的地方，测试的步骤虽然了解，但是往往并没有按照正确的流程走下来，可能这是在头一次做真正项目中的浮躁心理造成的，在以后的项目中该好好的重视一下测试这一环，不一定完全照搬书本上的步骤，形成自己的一套行之有效的测试方法，（可能主要是针对自身弱点的方法）。总之一句话，开发过程中一定不能有浮躁心理，按部就班的去完成任务。这个本身也是一个培养好习惯的过程。不管以后从事哪个方面的工作，一个好习惯总会带来好的效果的。另一个问题也是上面说到得Schedule,开发过程中，有一段时间，由于种种原因，基本已经脱离了Schedule的控制，对遇到的问题估计不足，自身技术水平的有待提高，设计上的问题，共通的问题，林林总总，总之，能完全的按照Schedule去开发，真的是“人月神话”，总之一个原则，不能影响整个项目的完工，实在解决不了的问题，可以稍微的放一放，也许在下一本的进行过程中突然就来了灵感，问题就应刃而解。所以千万不能在一棵树上吊死。在有一个问题就是版本的问题，这次我们用的是VSS版本控制,初期对这个工具了解不是很清楚，开发了一段时间才明白了它的好处，项目结束后一定要好好的熟悉以下。另外一定要明白版本控制在项目开发中的一些规定，版本控制在项目开发中是一个很重要的组成部分，版本一旦乱了的话，将个整个项目的开发带来不可估量的损失。（--Continue--）