最近一个项目编码完成后的感悟

    这个项目算我从java转.net的第一个项目。其中滋味复杂，短短不到两周的编码时间，却得到比平常一个月还要多的东西。项目任然在继续，但显然工作繁忙的峰值已经过去，上班之余我也有了一些时间来整理这些东西。稍微有意思一点的技术，将在后续的博客中，发新的文章来描述摸索的过程，而这篇将作为这些总结的契子。

    那是一个属于OA系统的模块——采购模块，客户是一家大型外企。由于前面有一些合作，所以沟通没有什么太大的问题，他们的DBA在我们与他们的采购部间沟通斡旋，需求将近谈了一个半月，终于我们的Demo获得他们的认可。有意思的是，准备进入编码期时，他们的采购部一直强调：要求做出来的系统必须跟我们展示的图片一个效果！后来那个DBA在每次的项目进度演示的会面上，每每都强调一遍这个要求。可见前面的一些模块给他们带来了多大的困扰！

    采购模块中，稍微复杂的部分应该算——工作流。但他们的业务并不算多复杂，几路并发顺序、分支、并发、循环、嵌套、多路选择与归并等的情况没有，顶多是双路并发、回档的需求。NetBPM没有太多必要，毕竟像我一样对它不了解的程序员占团队的一大部分，老大也没时间来先研究这东西。需求分析的时间已经挤占了预期的编码、测试的时间了。我们吸取了一些想法，打算做一个适合这个系统的工作流引擎。

    第一次了解到作为团队的leader需要考虑这么多东西，我在参与团队内部的会议后，感悟着。将用户一些特别的要求转化为功能、大致采用什么样式（这个要求是提给美工的）、项目有那些算难点、成员的分工、工作量的估计、编码规范、模块的复用，到实际编码过程中，团队成员的一些疑问......

    当我发现自己的进度有些拖团队的后腿时，压力也伴随而来，java转.net并不是一个很好的借口。公司两个平台上都有牛人都做过，而他们也不乏在之间转来转去。如果短时间不能.net的框架，只能说明你java的修养不到家，或者你的领悟能力存在问题。这种压力伴随到我负责部分的结束——最后一个上午做了差不多跟前一个星期同样的工作量，回想起来，不禁嘘唏。

    是的，工作并没有结束，编码只是很小的一个部分，当你框架定死，针对几个表格之间的操作，大约可以估算出所消费的时间。内部测试马上就要开始，而之后还要交给用户来测。我想，之后要改的工作同样重要而麻烦，令人压力倍增。

    很庆幸我走稳了这第一步，那么，接下来会更精彩吧！