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

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

 

一,项目背景:

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

二,项目简介:

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

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

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

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

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

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

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

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

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

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

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

    《项目总结(一)->项目的七宗罪》” /></span></p>
<p><span>    一个流程接着一个流程的演示, </span></p>
<p><span>    突然业务妹子又提了一个问题,咦,你们这些流程都是写好的,那如果中间要是流程的变动呢</span></p>
<p><span>    然后我的心情变成这样了</span></p>
<p><span><img layer-src=宗罪:不懂变通)

    —————————————–硬代码编码中—————————————–

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

    当时我的心情是这样的:

   《项目总结(一)->项目的七宗罪》” /></span></p>
<p><span>   突然业务妹子(你妹的能不能一次把话都说完呀!),提出一个问题,那这样的流程能不能实现分支流呢,就是满足什么样的条件,去什么样的流程,满足什么样的条件,去另外一种流程。。。然后我的心情变成这样了,</span></p>
<p><span>   <img layer-src=三,总结项目得与失:

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

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

       BreakDownApply.aspx -> 故障申请页面

       BreakDownCheck.aspx-> 故障初核页面

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

       ……(有多少流程,就有多少页面)

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

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

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

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

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

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

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

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

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

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

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

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

 

 

       

点赞

发表评论

电子邮件地址不会被公开。 必填项已用*标注