项目总结(一)->项目的七宗罪

大半夜来这一份总结，心中夹杂着各种各样的心情，酸甜苦辣都有，今天为止，整个项目终于完结了，对于这样一个本可以正而八经吃吃薯片，看看毛片就可以完成项目，最后演变成一个一月之内连续加班105个小时的项目，有自己经验的不足，也有能力不足，写下这样的一份总结，让自己沉下心来反思在一下自己的足与不足，也希望大家可以借鉴和探讨 。

一，项目背景:

我一年工作经验小菜鸟，同事四年工作经验,入驻客户办公室三个月开发周期......

二，项目简介：

常用的办公系统，结合工作流，可惜当时我自己没有看到其中的亮点是某什么内容，一直以为就这样随意的处理，无非就是增删改查，新增表单，自己定义一些常用的工作类来处理就可以了，Ok，那出一个悲剧一号版本

功能点例子:故障相关，可以完成故障单的申请，故障单的处理，故障单的结案。

比如故障申请页面(BreakDown)(一宗罪:思维定势)，无非是这样做就可以了：

Add.aspx->故障申请页面，完成故障单的新增内容

Update.aspx->故障单状态变更页面，完成故障单的状态的变更 。

Close.aspx-> 故障单状态的流程终结，完成故障单的生命周期结束。

一个页面各种动作相应的处理简就可以了，同事这样做的，这多么简单，看来我这吃吃薯片，看看毛片，不用加班，就可以把这个project轻轻松松的copy edit处理完就可以了，OK ,拿出代码生成器，你不是五个功能点么，实体层，写出一个内容，直接设计五张表，一下流畅的处理，后面的几个月时间都可以玩过去了，想想都有点小激动的样子。

和同事分配任何后，一个星期过去了..........

正当高高兴兴的提交代码后，我正想着今晚去哪看电影来着，客户业务人员过来问了一下情况，我立马和同事乐呵乐呵的演示代码，业务人员惊叹声中，哇，你们写代码的速度的好快呀，不愧为有经验的人员，可是，我自这个故障单要有不同的角色人员的才能处理，不是任何人都可以这样的做的呀。我冷汗一冒- -!，当时压根就没有考虑这个问题(一宗罪：自以为是。)，要不然我改好之后给你看新增的功能。

五个功能点，各种单据的状态对应的人员角色不同，处理的流程不同，那相应的改代码量就是^&*&&*#@$_%$()...........，当时只想着无非就是改代码嘛，大家分工又一个星期过去，Ok，改完了，咱硬编码嘛，无非就是if else 多一点处理.(一宗罪:不知悔改.)，就这样处理完结。

终于又可以给业务妹妹演示了，当时的演示的样子我是这样的：

一个流程接着一个流程的演示，

突然业务妹子又提了一个问题，咦，你们这些流程都是写好的，那如果中间要是流程的变动呢

然后我的心情变成这样了

这个.......灵机一动，貌似以前的级联操作就是可以通过节点的操作达到效果，通过下一节点，下一节点就可以达到循环的处理，oh yeah~~~~~无非就是表单设计来进行处理这个流程的变动嘛。(一宗罪:不懂变通)

-----------------------------------------硬代码编码中-----------------------------------------

经过自己和同事的辛苦配置后，终于实现一个类似工作流的小型可配置的流程处理系统了，怀着激动的心情，终于又可以演示了：

当时我的心情是这样的:

突然业务妹子(你妹的能不能一次把话都说完呀!),提出一个问题，那这样的流程能不能实现分支流呢，就是满足什么样的条件，去什么样的流程，满足什么样的条件，去另外一种流程。。。然后我的心情变成这样了,

当时我的表结构如下

Nodeid(节点ID)

PreNodeId(上一节点ID)

NextNodeId(下一节点ID)

NodeName(节点名)

NodeRoleID(当前节点的角色持有人)

以现有的表结构在我现有的基础上无法达到条件的选择和角色的待办和已办功能，我直接&*(%^&%^&%*(**&(&(&(0,,,,,,,,.....

后来加入客户这边的工作流，关于分支流，角色的功能全都可以实现了。。。。

三，总结项目得与失：

1.绝对不要指望同事能承担所有的事情，自己一定要做到充足准备，即使你们之间协调了任务，你也要对他做的东西有所了解。

项目刚开始一个功能点我最初的打算就是一个页面处理:根据传入不同的参数来处理不同的操作行为。而同事的做法一个功能点对应一个文件夹，一个文件夹内对应的就是各种行为下的页面，比如故障功能点:

BreakDownApply.aspx -> 故障申请页面

BreakDownCheck.aspx-> 故障初核页面

BreakDownAccept.aspx-> 故障审核通过页面

......(有多少流程，就有多少页面)

这样做非常不得当，可耻的是我竟然同意他的这种代码，没有在一开始就明确的反对。

在开始写代码之前，一定要明确代码风格，一个项目里面绝对不可以有两种不同的风格存在，又或者自成一派的行为,就是这种看似很小的细节，导致我和他的风格都参杂在一个项目里面，没有任何的代码约束与规范，项目改动难度大，而且冗余代码看的简直要人吐血，有的时候，容忍就是在给自己挖坑!

2.经不住逻辑推演之前的功能和表的设计，就不要写一行代码

在设置这个自己的工作流的时候，发现自己写实现的起来是多么的巧妙，多么的好，疏不知自己设计的类似工作流的东西根本就是功能有限，解决当时的需求是可以的，但是当有更高的拓展性的时候根本就是无解的。(这是导致我的不停加班的重要原因之一.....)

3.任何代码尽量不要做到硬编码，做到可配置

比如文件夹的上传路径，你没有看错，之间我都是写在固定的文件夹之下的。像很多种的代码请遵循能配置就在配置里面的原则，虽然当时看起来有点麻烦，可是事后还是能省下你不少的功夫的，比如如果我在第二次的流程做到可配置 就不会第三的次的返工了。

4.一定要时刻和客户需求人员沟通，不合理的需求都一概否决，决不让步。

一般来说，很多时候自己一些变态的功能设计都是被们程序员给惯出来的，都是自已一步一步的让步导致自己一步一步的无路可走，有些功能在合理的时间内是可以完成的，超出了自己的能力范围或者压根就不合理，没必要自己绞尽脑汁的去实现，也许，业务上的小小变动一下，可以节省你更多的宝贵时间 ，当然，对于合理的需求，一定要深度的挖掘，这样可以有效的避免二次，三次，又或者四五六次的返工。

5.项目建立之初，一定要确定一个统一的风格

风格不仅仅局限于文件夹的摆放习惯，类的命名，以及前台的一些命令，这样的命名方式可以提高整体的阅读性，至少看起来不会凌乱，注释，等等就不一一的阐述了。

6.对于项目的周期一定不要硬着头皮硬上

项目有既定的周期，如果超出周期那加班就成了理所当然的事情了，那反过来，为什么加班是一件理所当然的事情？是因为自己本身的不足导致的，还是说因为需求变更所导致的，如果是因为需求变更所导致，那不要自己憋在心里，一定要拿出来进行说明。