Open silent-tan opened 7 years ago
本文不是标准，只是一个在预售需求后的总结，也可以说是在产品迭代开发中的一些探索
author: @farzer
需求开始：02-06
本次产品迭代开发的功能是商品的预售
工作内容主要是根据某一个类型参数进入对应的业务场景，业务场景中主要的工作量如下：
时间筛选器
最初项目前端方面我的预计是four days的工作量，并且时间我大部分预估在第一点上面。
four days
由于最初自身排的需求优先级问题，MA重构我排的比较前，因此当后台进度快要完成的时间，我快要完成之前的重构需求开始介入到需求中去
尝试需求介入：02-24
另一个项目急着完成重构，于是预售的需求没有持续工作一天又急着转回之前的重构项目。
正式介入：03-02左右
终于将其他的事弄完，开始全身心投入到预售，首先开始的还是努力去继续深入到需求，发现预售比自己想象中的要难，所以毫无疑问，时间预估出现了问题。然而因为产品方面没有定下具体的上线日期，所以并没有感觉到急迫性，也就没有进一步去和产品沟通了。当然，对需求还是有继续深入了解。
原总结的工作内容加上需求影响范围：
先进行了Picker组件的封装，和团队提出了这个问题，稍微讨论了一下没有进行更深入的讨论便开始了快速编码，还是因为理解需求不够彻底，bshop项目用户也是可以通过PC端进行访问的，而封装的Picker是绑定了onTouch这类的事件，onTouch并不适用于PC，然后尝试类似绑定到onDrag事件上，不过过程并不顺利，绑定到onDrag上面产生未知的Bug。时间上不允许我还在这个组件上面浪费时间，和产品讨论后，决定PC端采取原select方式的UI，移动端采用新的Picker组件(PC端用户少，可以接受)
bshop
onTouch
onDrag
这个part完成后已经过去了将近3天左右，然后快速完成了需求影响范围的修改，这样又用了几天的时间，最后请求了测试的介入，于是噩梦开始了。
由于对于预售类型的时间配置的业务逻辑理解不够透彻，tapd上面一直存在10+ 的bug等待修复，修复后依然产生新的bug。最后只能老老实实继续咨询产品，慢慢听，然后做好相关笔记以及在草稿上面列好相关的条件控制，然后修修改改终于是bug的数量下降，然而也导致代码质量也越来越差，最后狠下心将之前修改的代码基本全部还原，然后利用周末赶工重新写了一下。
新的一周又用了一天进行测试，幸运的是测试过程中发现即使再次出现一两个Bug也能够快速修复。
发布：03-14
至此，项目历时已经过去了一个多月，即使是前端部分用时也用了13天左右，这远远超出了我的最初预期，也不是我当初想的不紧急类型需求。
一个多月
13天左右
在这个需求迭代开发的过程中，清晰感觉到了自己的手忙脚乱。也促使自己很有必要记录一下这次迭代开发的过程，从中发现并总结自身开发中的不足，避免再发生这种灾难式的开发模式。
我以敏捷开发这个我们或多或少听过的词将我们拉回《软件工程》中回顾一下
敏捷开发
《软件工程》
通常来说，一个软件过程是包含了以下五个框架活动：
每个框架是由一系列软件工程动作构成，没有软件工程动作是由任务集合来定义：将要完成的工作任务，产生的工作产品，质量保证点
此外还有一些普适性活动项目跟踪控制，风险管理，质量保证等等....
那么这五个框架活动是如何进行的呢？这就有了过程流的说法。
过程流
过程流描述了在执行顺序和执行时间上，如何组织框架活动，动作和任务。通用的过程流：
当然，单凭对框架活动和过程流的认识是无法解决问题的，他们只是描述了一个软件过程是怎么样的。为了解决问题，引入惯用过程模型。
惯用过程模型是对框架活动的描述，定义了不同的过程流以不同的方式执行每一个框架活动
此外，还有专用过程模型，但是专用过程模型使用的场景窄
最后是对现代软件开发影响最大的统一过程，统一过程重视敏捷开发的原则。
敏捷开发核心是适应变化，快速迭代，倡导可持续的开发速度。
敏捷开发优点很明显，能够快速迭代出符合利益相关者期望的功能，适合协作人员不多的团队。但是其缺点也是导致对于敏捷开发争论的主要原因，因为其快速迭代是以牺牲一定代码质量为代价的。
简单地回顾了一下软件过程，作为一个开发人员，编码部分就不赘述了，我们集中精力建模中的需求分析。
我认为需求分析可以分成两个层面：
当然，"理解问题的需求是软件工程师锁面对的最困难的任务之一"
但是，毫无疑问，就需求的第一个层面来说，对需求的正确深入分析可以让你的产品更加贴合利益相关者的期望。而第二个层面是我们更值得关注的，正确深入需求无疑可以减少我们软件开发人员的编码时间，并且可以更加确保编码成果符合产品经理的期望，避免无数个槽糕的熬夜，享受美好的人生
这里的质量，我们只谈代码健壮性。
从根本来说，代码健壮性这个界定点是模糊的，或者说代码的健壮性会因为网络发展得时间，开发人员的平均水平，软件开发时间等等因素的不同有不同的赋值。
举个简单地栗子，不断进步的你理解的健壮性和刚接触代码不久的你的理解不同，知识水平高的人和知识水平低的人理解不同。
所以代码的健壮性界定需要参照一定的编码规范，参照开发人员的水平，参照团队的能力等等。
代码健壮性影响：
对于代码健壮性的确保，目前我们团队采用发布测试+gitlab code review的形式进行
发布测试+gitlab code review
说了那么多理论，再让我们回到上面的需求迭代的过程看一下。
很明显可以看到一开始我的做法就错了，对于需求分析的重视程度严重不够，然后导致接下来一系列的问题。表现在对需求影响范围把握不足，错误评估时间拖延需求上线导致测试时间压缩从而影响到代码的健壮性。
其次由于时间紧迫性，对于项目质量这关也没有做好，代码质量低导致bug突发以及后续修复bug效率低，最终导致重新编码。
当然除了上述问题，就是一个个人编码能力的问题了。
先赞后看棒棒哒
rock-zhang
commented
7 years ago rock-zhang
commented
7 years ago
author: @farzer
1. 迭代开发回顾
本次产品迭代开发的功能是商品的预售
工作内容主要是根据某一个类型参数进入对应的业务场景，业务场景中主要的工作量如下：
时间筛选器的重新渲染(时间筛选器的时间范围变动)最初项目前端方面我的预计是
four days的工作量，并且时间我大部分预估在第一点上面。由于最初自身排的需求优先级问题，MA重构我排的比较前，因此当后台进度快要完成的时间，我快要完成之前的重构需求开始介入到需求中去
另一个项目急着完成重构，于是预售的需求没有持续工作一天又急着转回之前的重构项目。
终于将其他的事弄完，开始全身心投入到预售，首先开始的还是努力去继续深入到需求，发现预售比自己想象中的要难，所以毫无疑问，时间预估出现了问题。然而因为产品方面没有定下具体的上线日期，所以并没有感觉到急迫性，也就没有进一步去和产品沟通了。当然，对需求还是有继续深入了解。
原总结的工作内容加上需求影响范围：
阅读旧的代码并且修改部分旧的业务逻辑由已知的参数对 时间筛选器TimeSpan 进行初始化用户行为导致时间筛选器的重新渲染(时间筛选器的时间范围变动)先进行了Picker组件的封装，和团队提出了这个问题，稍微讨论了一下没有进行更深入的讨论便开始了快速编码，还是因为理解需求不够彻底，
bshop项目用户也是可以通过PC端进行访问的，而封装的Picker是绑定了onTouch这类的事件，onTouch并不适用于PC，然后尝试类似绑定到onDrag事件上，不过过程并不顺利，绑定到onDrag上面产生未知的Bug。时间上不允许我还在这个组件上面浪费时间，和产品讨论后，决定PC端采取原select方式的UI，移动端采用新的Picker组件(PC端用户少，可以接受)这个part完成后已经过去了将近3天左右，然后快速完成了需求影响范围的修改，这样又用了几天的时间，最后请求了测试的介入，于是噩梦开始了。
由于对于预售类型的时间配置的业务逻辑理解不够透彻，tapd上面一直存在10+ 的bug等待修复，修复后依然产生新的bug。最后只能老老实实继续咨询产品，慢慢听，然后做好相关笔记以及在草稿上面列好相关的条件控制，然后修修改改终于是bug的数量下降，然而也导致代码质量也越来越差，最后狠下心将之前修改的代码基本全部还原，然后利用周末赶工重新写了一下。
新的一周又用了一天进行测试，幸运的是测试过程中发现即使再次出现一两个Bug也能够快速修复。
至此，项目历时已经过去了
一个多月，即使是前端部分用时也用了13天左右，这远远超出了我的最初预期，也不是我当初想的不紧急类型需求。在这个需求迭代开发的过程中，清晰感觉到了自己的手忙脚乱。也促使自己很有必要记录一下这次迭代开发的过程，从中发现并总结自身开发中的不足，避免再发生这种灾难式的开发模式。
2. 重新理解敏捷开发
我以
敏捷开发这个我们或多或少听过的词将我们拉回《软件工程》中回顾一下框架活动
通常来说，一个软件过程是包含了以下五个框架活动：
每个框架是由一系列软件工程动作构成，没有软件工程动作是由任务集合来定义：将要完成的工作任务，产生的工作产品，质量保证点
此外还有一些普适性活动项目跟踪控制，风险管理，质量保证等等....
那么这五个框架活动是如何进行的呢？这就有了
过程流的说法。过程流
过程流描述了在执行顺序和执行时间上，如何组织框架活动，动作和任务。通用的过程流：
当然，单凭对框架活动和过程流的认识是无法解决问题的，他们只是描述了一个软件过程是怎么样的。为了解决问题，引入惯用过程模型。
过程模型
惯用过程模型是对框架活动的描述，定义了不同的过程流以不同的方式执行每一个框架活动
此外，还有专用过程模型，但是专用过程模型使用的场景窄
最后是对现代软件开发影响最大的统一过程，统一过程重视敏捷开发的原则。
敏捷开发
敏捷开发核心是适应变化，快速迭代，倡导可持续的开发速度。
敏捷开发优点很明显，能够快速迭代出符合利益相关者期望的功能，适合协作人员不多的团队。但是其缺点也是导致对于敏捷开发争论的主要原因，因为其快速迭代是以牺牲一定代码质量为代价的。
需求分析的重要性
简单地回顾了一下软件过程，作为一个开发人员，编码部分就不赘述了，我们集中精力建模中的需求分析。
我认为需求分析可以分成两个层面：
当然，"理解问题的需求是软件工程师锁面对的最困难的任务之一"
但是，毫无疑问，就需求的第一个层面来说，对需求的正确深入分析可以让你的产品更加贴合利益相关者的期望。而第二个层面是我们更值得关注的，正确深入需求无疑可以减少我们软件开发人员的编码时间，并且可以更加确保编码成果符合产品经理的期望，避免无数个槽糕的熬夜，享受美好的人生
质量管理
这里的质量，我们只谈代码健壮性。
从根本来说，代码健壮性这个界定点是模糊的，或者说代码的健壮性会因为网络发展得时间，开发人员的平均水平，软件开发时间等等因素的不同有不同的赋值。
举个简单地栗子，不断进步的你理解的健壮性和刚接触代码不久的你的理解不同，知识水平高的人和知识水平低的人理解不同。
所以代码的健壮性界定需要参照一定的编码规范，参照开发人员的水平，参照团队的能力等等。
代码健壮性影响：
对于代码健壮性的确保，目前我们团队采用
发布测试+gitlab code review的形式进行3. 项目反思
说了那么多理论，再让我们回到上面的需求迭代的过程看一下。
很明显可以看到一开始我的做法就错了，对于需求分析的重视程度严重不够，然后导致接下来一系列的问题。表现在对需求影响范围把握不足，错误评估时间拖延需求上线导致测试时间压缩从而影响到代码的健壮性。
其次由于时间紧迫性，对于项目质量这关也没有做好，代码质量低导致bug突发以及后续修复bug效率低，最终导致重新编码。
当然除了上述问题，就是一个个人编码能力的问题了。
4. 总结
5. 参考