离职了，项目经理要求我写项目开发总结。我那个郁闷啊。

0 0

离职了，项目经理要求我写项目开发总结。我那个郁闷啊。0

我一怒之下，写了以下内容
4经验与教训
经过这次开发，感悟颇多。但总结起来，就是沟通问题。沟通的力度远远不够。不过要写经验和教训，还得从头开始写起。一下仅仅是我对此次开发的看法。

1、前期准备不足。其中包括了需求不详细、架构搭建不完善。
至于需求是否详细，该写多长篇幅才算详细。这个或许大家的意见并不统一。但如果你参考其他书籍，就会发现，详细的需求分析有一个特点，就是详细的输入和输出，并对特殊的输出进行标记。可是，很遗憾。该文档似乎没有做到。这也是为什么软件做出来后还要改动那么多的原因。原因就是和需求不符。

其实，这和建筑是一个道理。我们好比普通的建筑工人，只会累砖，如果你的图纸不够详细，很多东西没有标注。那么我们在施工的过程中，对于那些图纸不是明确指出的，往往会根据自己的经验去做，造成位置、大小或者样式就会有所偏差那就在所难免了。可是更加致命的是，这我们的施工过程中，画图纸的设计师没有及时指出来矫正，当做好的时候，设计师才说，这不符合要求，拆了从新建。My good。难以想象，这得需要多少人力物力？当然，软件的修改的代价不会像建筑的代价那么大，但也是不可忽视的。

在这里举一个需求不详细的例子。培训计划，列表是现在全部的培训计划，包括审批的，没有审批的，结束报名的。可是，当报名的时候选择，只显示，已经审批并且报名没有结束的计划列表。可是需求并没有写明。虽然，这修改量不大，我只给列表页传递一个参数加以区分就行。假如，需求中写明要加以区别，这样的错误情况就不会发生了。

团队刚成立，大家都需要磨合，我个人觉得把需求写详细点很有必要。

至于架构。没有清晰的分层和责任。也没有规定该怎么写。写得太过于随意。Hibernate的工具类没有经过审核，手动管理事务，事务在action层就结束了，不能延迟到jsp页面，导致了不能延迟查询。解决的办法是把延迟加载取消。这样查询的效率就降低了。我把hibernate的事务改为了使用过滤器来控制。只有当jsp页面渲染完成之后自动关闭事务和session。泰龙提出了异议，使用Filter控制事务，能不能保证事务完整性和一致性。并写了代码推翻了。泰龙真的很不错，起码他思考了。当时泰龙演示的是，原来想插入两条数据，但在插入第一条数据之后，特意抛出空指针异常。希望是第二条数据不能正常插入，第一条也不能插入，结果是插入了一条数据。其实这个很好解析。对于事务，好像只有运行时异常才回回滚。插入第一条之后，抛出空指针异常，然后跳转到异常页面，页面就渲染完毕了，所以事务提交了，才会插入数据。这个时候，应该保证我们的代码不要抛出空指针异常。对一些数据进行必要的判断。如果，第一条插入成功之后，在插入第二条数据，是在操作数据库时候出错的，数据就会回滚。所以我觉得filter控制事务和session是可行的，但很遗憾没有得到大家的认可。所以大家的代码都要在action层全部查询出来，然后通过request发送到页面去。代码不是那么整洁了。

2、缺乏沟通
真的，非常缺乏沟通。程序员之间，程序员和需求分析师之间，领导和员工下属之间都缺少交流。这才是问题的关键所在。像上面提到的，如果我当时问需求分析师，报名的时候培训计划的选择用不用过滤一下。可是我没有问。这是我的失误。但是，我当时的心理是这样的。因为有几次提问，就被压了回来，说是程序员内部讨论的。可是，我们几个写代码的都摸不着头脑。当然，一个人不断地问问题，这是太考验对象的耐力了。所以，我选择了不问了，因为我害怕再被压回来。其实，我更喜欢选择用email沟通的方式。因为我看不到人的表情和说话的语气。即使，我给需求分析师发封email询问，报名的时候培训计划的选择用不用过滤一下。当需求分析师收到我的email的时候，心里怒骂，狗日的这还用问。我是看不到需求分析师表情的。但我收到回复是“需要”，我就会很开心。当然，我这里是假设。需求分析师的人还是不错的。虽然我的简历写着善于沟通，但简历并不代表真实的情况。

3、领导者的风范
作为领导者，应该具有一定的内涵。我心里明白，人非圣人，不要求做得多美完美。但轻易地把员工的意见压回去，轻易地跟员工拍桌子。这完全没有具备一个领导者的度量。这些问题说明了，一个人的固执，易怒。可是这些都无法解决问题。领导者希望自己的员工能很好配合自己的工作，为自己冲锋陷阵。但是达到这个目的，必须去领导员工的心声。当你失去了属下对你的信任的时候，你就处于非常危险的境地，极有可能变成了光杆司令。领导者有所为有所不为。不用事事俱到，几个人的团队，不用框框条条去管理。

以上的总结是针对事，而不是针对人。

2013年4月09日 17:33