新版中心工作总结

  1.针对原型(根本)
  结论:对于订单部分的原型必须要提前给开发人员,然后开发人员逐字逐句,逐个按钮输入框进行思考分析,提出疑问和建议.如果版本迭代内容多,那么需要给研发至少半天以上到一天的时间去分析原型.
  为何至少半天以上呢?如果开发人员思考不足,那么就会导致开发过程中问题不断,导致研发人员和产品人员频繁对产品需求进行沟通,不断增加两者的时间成本.
  本次对新版中心原型,我做的分析是十分粗略的,导致代理人订单分组,增加小项和分类,支付情景,交官订单等等预估发生失误,订单列表各个问题都出现超出预期200%的工作量,本质上是在需求解说前对原型分析不足导致,从而对开发时间估计造成失误.

  2.分析内容
  对产品开发的库难度分析,找出原因.当然很多时候说不清楚原因,只是根据以往经验来判断困难.此时可以参考开发中封装变化角度来分析,产品哪里的变化是没有规律的,产品哪些捋不顺思路的,这些让人说不明白,而这些通常是进行重点分析内容,业务处理的重点问题.所以要划定产品变化的范围来分析.

  3.针对产品
  如果技术难以上线某个业务,要么将产品实现难度降低,要么技术硬扛去实现.通常技术难以实现的业务都可以通过优化业务去降低技术实现难度,比如12306网站如果在某个时段将全部的票放出,那么必定被中国上亿人流量踩死,当12306从业务上做优化分时段放票,就可以轻易将流量高峰进行削减,完成技术不能实现的业务.如果在收到原型进行评估时,难度过大,思考和开发难以承受,先和技术人员评估,若依旧难度很大,此时就需要和产品人员协调.

  4.针对复杂度
  面向对象原则有单一职责原则,每个类引起变化的原因只有一个.对于产品来说,如果产品某个功能处理过多非该功能的相关内容,那么就会增加开发难度.并且复杂度都是指数级别的,而不是简单的相加或者相乘的问题.处理某个功能相关数据,就不会有存在太大的技术难度.比如新版订单列表,当有可提现tab项,它和订单本身相关性比较低.如果抛出该项的开发难度是5,那么加上该tab项开发难度就会变成7,8,而在可提现功能中出现该列表,那么就是难度3,难度越高越耗费人精力和心力.增加难度的开发时间不是加和关系,而是乘积或指数关系,其具体表现在需要捋顺各种业务关系,考虑维度越多,思考难度越大.费力不讨好的同时,开发结果是比较脆弱,开发人员实在没有谁能细心到面面俱到.
  技术比较推崇小而美的类或方法,那么业务需求同样以小而美,降低开发难度的同时,当人员流失其他人比较容易接手,否则问题会十分严重的.

  5.关于开发时间
  高难度的业务,理不顺的思路,本身就是情绪发起挑战.此时所需的开发时间,加上平复精神压力的时间;理解复杂业务出现偏差,造成的失效时间.业务越复杂越发需要将复杂业务进行拆分肢解!如果不熟悉业务,增加开发人员就落入到人月神话的困境中,只能用熟悉业务的开发人员处理,其他人员是无法帮忙的.此时更加需要降低业务难度,
  估算时间 = 开发时间 + 抵压时间 + 允许理解业务失误时间 + 分析业务时间 + 沟通时间 + 其他事情打断时间.
  开发难度预估时间,正常的开发时间等于估算时间 * (1.5 ~ 2), 业务难度复杂的开发时间等于估算时间 * (2.5 ~ 3).

  6.关于开发时
  精神烦躁的根本原因在于没有将变化范围做出圈定,同时面对复杂的业务没有切入点.此时需要用纸和笔尝试分析问题找到解决问题的切入点,此时不必分析全部的问题,自己尝试寻找解决问题的切入点,比如代理人或用户订单列表每个tab选项都很复杂,刚入手是无法将3,4个tab项整理出来,可以从对某个tab切入,边开发边设计边重构代码,还得需要压制内心些许烦躁,更不能以为可以一劳永逸地处理业务问题,因为这个和验证某种技术类似,只是实验性业务处理验证而已,需要反复思考设计重构的.烦躁时不可以不断地思考在思考,此时思考的价值小,反对的是无法做出有效分析后的思考,应该做的是以开发某个某个功能作为切入点后边做边思考边重构.

  7.关于订单列表
  订单列表难点体现:不同情景关联表多且不同,查询条件组合复杂,不同订单返回值不同,因此没法统一处理不同的订单.
  处理方式:
  1.对pc端传递的参数进行封装处理,对参数进行初步处理
  2.tab项分页数据查询:全部订单,待分类,待处理,已完成
  3.根据tabl项选择不同的分页查询sql查询第三方总单.
  4.根据第三方总单Id来判断总单的技术分析类型:非保姆式订单,待分组无子单保姆式订单,已分组有子单保姆式订单,无分组有子单保姆式订单.
  5.根据每种类型的订单组合不同的数据表查询方式查询特殊数据
  6.不同订单类型最终返回值内容各自不同,从而减少pc界面解析难度,那么统一返回值信息.
     
  如果开发前始终做全局分析已经内心烦躁不堪,看到这些看法就会毫无头绪,根本无法兼顾各种情景,如果分开来做将会导致工作量倍增.因此以全部订单作为突破,新增的问题是查询模式是无法满足这种查询的,重点和烦点是在各种情景下的sql编写,且无法在配置文件中处理,因为当前主要的变化是sql的复杂多变,所以sql只能在java源文件中进行动态变化,而配置文件作为无法做到,此时需要在java源文件中做sql适配处理.

  对全部订单进行分析思考,此时手脑并用,思考完就在纸上勾画,此时可以减轻精神压力,化压力为行动.完成开发后,不断进行重构设计,开发,测试,重构时间比例基本上是1:1:1.将所有的变化抽象出来,确定变化领域和开发流程后,完成全部订单只剩下开发没有压力的开发而已,最后设计框架完全满足待分类,待处理,已完成tab项.
  对于全部订单设计开发的时间分配:思考分析50%的时间,开发重构时间再50%以上,然后待分类,待处理,已完成所有的难度已经现在在sql编写上,水到渠成的事情.
  开始时没有切入点,在于各个tab项各种复杂,摸不着头脑,找不到处理路径,此时拿起笔来记性各种分析设计.开发完后发现无法满足更复杂情景,推倒后继续重构,再抽象再重构,继续抽象继续重构.没有头绪没有切入点时精神压力是最大的.

  8.关于查询效率
  目前数据库的表关联属于业务逻辑关联,而不存在物理上主外键关联,因此数据上没有物理主外键上的索引关系,查询效率比较慢.此时可以手动地在业务逻辑关联字段上添加上索引,这可以大幅度提交查询效率.比如代理人中心订单列表和个人中心订单列表最开始每个查询需要4,5秒时间或更多,在对关联字段添加索引后,查询时间不超过1秒,速度飞快.

  9.关于语言特性
  如果处理复杂的业务,那么设计模式的作用将会十分明显,同时使用简单业务的处理方式是跟不上复杂业务的节奏,好比儿童只会耍耍玩具车,而无法骑自行车或摩托,因为后者需要更多更复杂的处理技巧和方案.
  语言本身提供的高级特性可以得心应手地处理复杂业务,高级特性本身就意味拥有处理复杂业务的能力.
  比如在处理订单列表过程中使用构造者模式,模板模式,工厂模式,java8的特性,mybatis特性.