Fireman Report (1)

原创
2013/12/19 00:58
阅读数 143

2013-12-17 开始的第四次当Fireman。

主要工作就实现股权融资投资的议价流程:

融资方和投资方通过中间委托人,在线上完成议价,达成一致买卖价格后,卖方委托人将客户的股份转移给买方委托人,买方委托人再将股份分配给客户。

期间遇到的问题主要有:

  1. 对业务熟悉程度不够(不够理解需求和原型)

  2. 前端架构不稳定、可用性差、几乎无代码规范(未采用行业标准框架,出现框架级别错误,模块化设计思想不够,可维护性差)

  3. 前后端数据接口不够稳定(调用接口,接口出错或者是接口返回参数缺失)

  4. 页面逻辑耦合度高(带有流程控制的弹窗内容不能单独调试,并极其依赖上一个流程的数据)

我大概设想了对应的解决办法:

   1.  对于业务不熟,我是特殊情况,我觉得根本原因是我没有跟相关人员有足够的沟通,这个完全是个人原因。但是如果是自己团队内出现这样的问题,那可以让开发人员参与整个需求设计的过程中来,从而加深对业务的理解。

   2.  前端架构的问题,首先需要使用行业标准的、成熟的架构,sea.js 就是很棒的异步模块加载器。我觉得要好好实施起来,不仅要靠一个好的框架,也需要有好的模块设计的代码规范,模块化设计和可维护性不是靠 sea.js 就能保证的。我大概构想了一种方法,利用 nodejs 和 grunt 对 js 代码进行代码规范检查,但是这种检查只是 suggestion,并不修改代码本身,就如 JsHint 之类,下面是粗略的构想:

  • 模块最开始定义变量

  • 模块最末暴露接口

  • 暴露接口的代码之前放置事件绑定(多使用 on 绑定),事件响应方法函数体独立成单独的模块私有方法,而不是匿名函数(处理逻辑小于四行的可以写匿名函数),此方法将事件绑定集中放置,方便管理。

  • 方法抽离为功能单一、职责单一的模块私有方法,尽量使用函数式,尽量少使用作用域为整个模块的“全局”变量。

  • More ....

   3.  前后端数据接口不稳定是由于被需求追赶着而导致的,没有足够的时间进行联调,而一旦联调,此时前端的工作并不会单纯的只处理数据接口,而是结合页面交互,在需要用到数据时才会与后端发生联调,导致前后端的耦合紧密(联调层面上),付出 Double 的调试时间,劳民伤财,设想了一下解决方法:

  • 利用 nodejs 提供自动化工具,通过 Java 类方法上的标准化注释生成前端数据接口,从而为前端抽离出数据接口模块,数据接口模块提供类似 DTO 的扁平化数据,尽量降低前端对业务的理解深度。

  • 利用 nodejs 模拟前端请求,提供可视化、自动化测试界面,模拟各种业务数据类型,可配置输入参数的数据类型正则,可监控后端返回参数的执行状态、接口消耗时间等。

  • 利用前面两个步骤,使数据接口模块支持(符合业务逻辑的)Fake Data ,以帮助前端对数据接口的解耦。

  • 后端人员可不提供 DTO,但是上面三个步骤后端人员需要在强大的自动化工具下完成。

   4.  页面模块耦合度高,一个很明显的问题就是带有流程控制的 dialog ,dialog 需要处理各种状态,还要从第 n 步跳到第 n+1/n-1 步,每一步还有明显的数据依赖(下一步需要上一步的数据作为输入),最要命的问题就是,所有的dialog流程步骤都是在一个页面中完成,html 模版代码都是在当前页面,然后通过 display:none/display:block 来完成步骤切换,而且每一步都是无发保持状态的,第 n 步完成的状态无法保持,也无法从整个流程中抽离单独调试(从 UI 和 相互调用的层面上都无法做到)。解决办法:

  • 采用 iframe 来作为 dialog 的 content,每个步骤都是一个单独的 html 页面。

  • 对 iframe 与 parent 之间提供良好的 I/O 接口,并对其进行模块化设计, iframe 和 parent 之间做到尽可能的独立。

  • 每个步骤最好设计成有状态的,根据传入的参数(前端路由/Http Get传递的参数)保持状态,降低前后步骤的耦合度,从而可单独调试。

以上包含了很多吐槽和粗略的解决方案,需要跟团队磨合和协调才能正真地改善甚至是解决问题...



展开阅读全文
加载中
点击加入讨论🔥(1) 发布并加入讨论🔥
打赏
1 评论
0 收藏
3
分享
返回顶部
顶部