一本书和我的首个项目

2012-12-20

                                                                  

      先从这本书说起吧， 这是我在2011年9月买的， 前面三四个月，只是看懂了基础的准备篇和基础篇， 也就是知道一个完整的项目大概是经过几个步骤完成的， 各个步骤都有哪些基本的过程。 即使那时候还没有实际的项目经验， 但是，从这本书中仍是感觉到了做一个项目是一个有着规范的，只要照着既定的模型做下去， 就不至于把项目做坏掉。 我想，作者**想传达给我们的最重要的信息就是： “模式”这个来自西方的词汇，我们一定要加深对其的理解。不可重复发明轮子，一定要注重经验的积累和传承。如果我理解有误，那可是对作者的最不希望看到的事儿。若是你认为我说错了，请一定要“浪费”你几分钟时间给我留言。本人感激不尽，在此拜谢了。  

      我今年七月末开始在一家做Java后台开发的小公司实习，我们的项目基本上使用SSH框架，并且经过本公司的技术总监加以改造，以更方便的被组合使用。下面就来说说这一个半月的开发感悟。希望能以此与大家交流下开发经验。 我的第一个正式项目呢，是给一个国家军工部门做的数据处理。合同中的安全要求， 我不能对此多说什么了。在这里我不得不吐槽一下公司的项目管理了。年初开始的项目，等到年末才开始做， 等到客户急着要项目上线的时候自己才知道急了。早干嘛去了。 首先，人员组成。 我们公司属于半外包型公司。我的好友同期和我到此公司实习，同进入此项目。 我们两人是完全的新手（其实，我在学校中参与了两个小型Java WEB项目的开发，还算是有一点经验） 。其他有四位同事都有两、三个项目的开发经验。组长已毕业一年多，加上全职实习期共有两年多的开发经验。 还有一位技术总监指导我们这个项目的整体开发进度与人员调度。这就是我们的成员概况。  

      这里对这个项目开发做一个总结。 首先来说一下自己的收获， 毕竟是完整的参与了一个项目的开发， 心里还是非常激动的。收获呢， 有以下几点：

          1， 每个月有千把块钱的实习工资。虽然这点工资在北京屁点儿事都不能办， 但是就本人来说还是已经满足了。 毕竟我不是全职的员工， 也没有把自己的精力全部放在工作上 —- 我还有自己的学业要完成呢。 给多少钱，干多少事儿的想法还是相当普遍的。本人倒是不这样认为，实习生前半年基本上是不会给公司来效益这样的事儿我还是知道的，不要闯大祸就是最好了，并且，我觉得，努力的干活儿，收获的不只是公司吧！你的时间在那儿摆着，不好好干活儿只会使其白白浪费而已。若是觉得对公司不满意，不必委屈自己，随时说明情况，走人就是，大可不必浪费双方的时间。    

     2， 经验上的积累。 这两个多月的开发，还加班加点了， 收获还是蛮多的。先说一下团队协作。 虽然我们只有八个人， 代码冲突，功能重复， 需求理解不同等等问题，都给开发工作造成了时间上的浪费 – 虽然说，这是新手必经的一个过程，但是，我仍希望，通过一些经验总结，能尽量节省新手上手的时间。

     3， 认识了新的伙伴。在公司里待了有五个月了， 和大家也混熟了。 要说现在走的话，也还是挺舍不得的。 给我最大的体验就是，这个世界很大， 有许多和我的经历不一样的人存在着。 他们告诉了我很多很多不曾听到过的东西。

       但是， 正因为有这些收获， 才能稍微意识到这个过程中存在的一些问题。下面我也来说说这些问题。

     1， 开发模式。我们项目开工之前，技术总监给我们开发这个项目定下了开发模式为敏捷开发。刚听到这个，我就觉得这个是不是不靠谱，因为我们团队里基本上都是新人，还有俩完全的新手。敏捷开发，不是开玩笑吧？既然总监都这样说了，我总不可能比总监知道的还多吧，可能是我错了吧！应该还有很多东西我不知道的。就带着这样的疑问，我们开始了开发工作。敏捷的晨会我们只持续了一周多，就进行不下去了。为啥呢？就因为经过一周的开发工作，每天的任务贴条都有拖沓没有完成的，没有办法进行每周评审。我就说嘛，不成熟的团队采用敏捷开发，那不是找事儿吗？就这样，第一周的评审就带着诸多问题走过去了。第二周，我们的每日贴条就没再进行下去了，改用站立晨会说明情况即可。

     2， 开发人员不固定。 我们这个项目，前期经过了近半年的需求调研。 调研的人员都换了一批， 交到我们手上时，已基本上和前期的需求调研人员断了联系，只有一个需求分析文档，几份儿相关文档和一份客户认可的界面在我们手上。做开发时，不能确定需求时，只能跑到另外一个屋里找当时负责需求的组长。这样的不知客户需要什么的状况简直糟糕透了。第二周过了两三天，我们的组长因更紧急的任务被调走了，队里二把手升为组长。可是，他对需求的了解还没有队里另一个参加了两次需求讨论会的队员熟悉，他就成了“需求负责人”。结果就是开发过程中，我们不明白的地方问组长，组长就说“问需求负责人”去。我勒个去！这才是最致命的错误，我们组长对需求是最熟悉的，他一走，之前他为此做的准备、花费的时间都没有意义了，对整个开发打击最大。我认为，这个项目虽开发时间较紧，若是组长在，加班的话，按时保质量的完成应该是没有问题的。项目进行了两周后，有一个开发者中途离职了，虽说协议在那儿，人心已去，徒留无,益，公司也毫无办法。若你在看到这篇文章的时候还没有正式参加工作，我亲爱的同学，一定要树立起负责任的态度。绝对不要像这样在项目开发途中突然走掉。

     3， 没有完整的规范的开发流程。因为看过《Thinking in UML》的缘故，我一直认为不管项目再小，一些规范化的流程，经过实践的可行的做法，都要在开发之前让每个组员明确知道并采用。如项目中的命名惯例，通用的组件儿放在哪里，代码的注释、排版惯例等等。还有，组长必须要负责起开发过程的统筹安排，一些系统级常量、等等，组长必须要在开发开始的时候就写完。这样的话，就能给整个开发建立起一定的约束，不会任由没有太多经验的组员自由发挥而导致组员之间交流费时、后期维护费劲儿等不必要的困难。

     4， 公司对项目不够重视。年初定下的计划，到年底才来开始实施，早干嘛去了。 最后火急火燎的， 说客户催着要看成品了，就催我们尽快做出可用的版本出来。 这不是说句不好听的，这是你的公司，而我们是打工的，甚至 是临时打工的， 不要期望我们所有人都下足力气来干活儿。老板你都不把自己的产品放在心上，我们员工眼里看着，心里会怎么想呢？我们的劳动有那么大的意义吗？

     这是我参与的首个商业上项目， 想着它将来能够为别人产生效益， 我的心里还是有点激动的。 

     p.s. 在学校的时候我一直以为自己毕业后几年一定会做Java 后台开发的， 没想到，出来实习一个月之后，我的发展方向就发生了改变。在学校里自学的Python， Lisp，到八月份末接触到Erlang， 没有想到现在成为我寻找方向的一个选择。

 

[ 主页]