经验谈:如何快速应对项目需求中的变化

版权声明:本文为博主原创文章,遵循 CC 4.0 by-sa 版权协议,转载请附上原文出处链接和本声明。
本文链接:https://blog.csdn.net/iteye_17246/article/details/82489497

大家在项目中,印象最深的估计就是“需求变更”了,这个词无时无刻让coder们紧绷着。祈祷着没有变更,但是总是事与愿为,不管是进行中的,还是结束后。总会有这种那种的变更、优化等着你去支持。

那么如何应对这种变更的需求呢?笔者有以下几点个人观点跟大家分享和探讨。

一、项目开始阶段

在项目开始阶段,不要急于去写你的代码,不要为一开始拿到需求就想到时间进度问题。当你拿到需求的时候更重要的是先消化好需求,从中间挖掘出今后可能会存在的发展方向。

消化需求主要为以下几个方面:

1、  先整体了解项目的背景,项目生存的环境是什么?

2、  仔细了解整体的交互过程,挖掘出你的代码框架要如何设计?

3、  对上面2点消化后,开始选择你的主框架或主库;在没有合适框架情况开始规划你的库结构。

4、  思考项目部署问题。如何规划你的文件分布以及目录结构,方面日后的维护。

5、  评估时间时预留风险(可能会发生)时间,可以参考一下三点估算法来评估。

三点估算公式:Te=(To+4Tm+Tp)/6

To:基于活动的最好情况,所得到的活动持续时间

Tm:基于活动最有可能活动持续时间

Tp:基于活动的最差情况,所得到的活动持续时间

Te:预期活动持续时间

二、项目进行阶段

这个阶段估计是最头痛的阶段,有时候基于各种因素。经常听到的是“XX,这里需要调整一下”、“XX,这个流程这里因为XX原需求调整一下”等等类似的情况。然而,没有圣人,这种情况不管前期考虑的多完善,在执行过程是不可避免的。我们唯一能做的是——用最小的代价支持变化的需求。

这里分享以下几点经验:

1、  底层公用接口设计要功能单一,不局限调用方式,方面业务层二次封装。

2、  在业务层规划好公共接口。

3、  做好底层接口的二次开发,方便在业务层的灵活运用。

4、  解耦代码,各模块独立,尽可能降低交叉引用

5、  做到UI与逻辑分离,减少对UI的依赖

6、  经常回顾你设计的代码。看看有啥不适之症,即时做好调整。

7、  确定关键路径(花费最多时间的路径,也就是项目的最后完成期限时间),优先保障关键路径的开发;原则就是先修主线,后修剪枝叶

三、项目上线后的优化阶段

这是一个长期的作战过程,除非你的项目“Game Over”了。而且一些变化会让你始料未及,那么如何去快速支持呢?这里大部分依赖于上两个环节是否设计的合理了。

建议如下:

1、  同项目启动阶段一样,先拿到需求,仔细阅读需求,不要急于下手。

2、  了解交互的差异性,看看新的交互与之前的具体变化是什么,这里需要确认出来的信息是:a)是否需要完全重构;b)是否只是参数调整;c)是否只需要屏蔽现在接口的调用。

3、  如果涉及交互大调整,需要重构的。这里就需要重新思考重构方案,不要急于直接重写你的代码。

四、两个示例

1、  接口的设计

v  设计整体结构


v  对单个接口调用和实现进行思考


 v  接口剖析:多样化的调用实现以及二次封装接口预留

事件注册句柄代码示例



 
接口方法实现代码示例


以PageLoader接口为例:

底层接口为loadPage()

1、  HASH加载请求处理:loadHash() -> loadPage()

2、  用绑定节点的方式处理:bind() -> call() -> loadPage()

3、  用事件委托绑定节点的方式处理:all() -> call() -> loadPage()

4、  一个快速响应交互流程调整的优化需求

需求:流程优化,产品的两个流程原来都只有一个页面实现;优化为将流程折分成2个页面来完。

现状:原来2个页面都是用的同一个模块代码来实现。

分析过程:

1、  初步印象,需要对代码模块拆分,需要把原来的业务逻辑重新调整。这将耗费大量的时间来处理。

2、  重新审视新的交互流程和原有流程的差异性。进行新旧页面文件的对比,努力寻找与原来页面的共同点以及差异性。

3、  通过两者之间的对比,发现A拆分成的(A1、A2)只是对表单元素的分步处理,其它都一样的,虽然表单被拆分,但是逻辑实现调整不大。

实现:

页面A –> A1 + A2

1、  将A1和A2的表单名称,事件触发的节点selector设置成一样。

2、  在A1的表单新增自定义属性data-step=”1”,在A2类似(data-step=”2”)


 
3、  OK,页面结构调整完了后开始调整JS的业务逻辑;

a)       根据data-step来给节点绑定不同的回调

 

 b)       缓存data-step为1的表单,在data-step=”2”的页面进行合并后整体提交。



 
很简单是不是,这里的时间花费分配大概时:思考(6h左右)+执行(1h左右)

五、总结:

云淡风清的去对待你所面对的需求,移位思考;

必要时可以做一些假设性的场景调用;

多参考他人的实现方式,吸收他人的实现思想。

原文链接:http://tid.tenpay.com/?p=4459

展开阅读全文

应对大数据上SQL的需求:Apache Drill

08-25

[size=14px][align=center]应对大数据上SQL的需求:Apache Drill[/align][/size]rnSQL已经相当流行——为什么呢?客户正在寻求交互式的大数据解决方案,这些解决方案需要流线型工作流和选择便利性。能够在Hadoop和其他大数据系统上使用SQL,已经朝着这一目标迈了一大步。rnrn产生这种需求的一个原因是,这些大数据工具可以与SQL交互,但是以往的大数据解决方案并不能。上世纪70年代IBM研究院Ted Codd开发了SQL,因为人们需要一个标准方式来访问和使用关系型数据库中的数据。这需求仍然存在,它甚至比以前更重要,因为目前很多系统已经实现生成标准的SQL。然而,对于Hadoop这样的现代可扩展系统和非关系型数据库,标准事务型SQL不再适用,所以,系统分离了。这种不当的搭配可能意味着冗余、昂贵和复杂的工作区,来满足SQL兼容基于Hadoop大数据系统的低成本优势的广泛需求。rnrnMapR技术通过多种方式解决这些问题。它通过自己的大数据平台和对开源项目Apache Drill的贡献来提供广泛的支持。rnrn多达30种新产品和开源项目试图解决Hadoop上SQL和类SQL的需求,包括Apache Hive,Cloudera的Impala,开源Apache Drill,通过Cascading开发的MapReduce和Hadoop的开源SQL解决方案Lingual。rnrn[b]Apache Drill是什么?为何MapR对它投入如此之多?[/b]rnrn客户想要很广泛的功能,而在引入新技术的时候,Apache Drill的设计使得它能够很容易就连接到大范围的分析工具和数据源。rnrn很多Hadoop项目上的SQL都是把小数据集上开发的功能再次开发,尽力让它们满足大数据的需求。虽然它们解决了很多真实的需求,但是它们根本上还是后视镜型项目。相反,Apache Drill作为一个媒介,将新技术引入这个问题域。Apache Drill受到google的Dremel项目的影响,达到了更高的要求,并且正在设计新的功能。rnrnApache Drill提供了访问大数据存储的交互式特定查询功能。Drill的一个重要特征就是速度,它被设计在低延迟响应下处理P字节的数据。Drill很重要的一个方面是,它不解决过去5-10年的问题,而是向前建立一个新的技术,解决当前和未来5年内的需求。rnrnDrill高灵活度的架构设计主要提供如下关键技术:rn1模式可选rn2处理嵌套数据的能力(例如JSON,Protobuf,Parpuet)rn3柱形内存存储和执行rn4全标准的ANSI SQL:2003查询能力rn5先进的低成本优化器rn6为多个社区提供广泛好处的高可扩展的架构(例如,向非SQL PIG的扩展能力,或者建立机器学习原语,能够集成到Drill为Mahout提供先进执行引擎)rn7YARN整合rnrnApache Drill开源项目的社区驱动方面相当重要。除了MapR的支持,Apache Drill的贡献者来自不同的地区和公司,包括Pentaho,Oracle和VMVare等。Drill开发者一直合作产生大量的代码,准备alpha版本的发布。随着这些新技术将传统工具和现代基于Hadoop的系统连接起来,我们正在进入一个大数据分析和大规模机器学习的令人激动的时期。rnrn来自[url=https://www.mapr.com/blog/responding-to-the-need-for-sql-on-big-data-apache-drill#.U_shFXWSzCI]Responding to the Need for SQL on Big Data: Apache Drill[/url] 论坛

没有更多推荐了,返回首页