打印

一本你可能用得着的书

[复制链接]
751|1
手机看帖
扫描二维码
随时随地手机跟帖
跳转到指定楼层
楼主
红蛋大叔|  楼主 | 2017-10-23 21:54 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式
   这几天看了一本名为《高效程序员的45个习惯》,虽然讲的是PC端软件敏捷开发方法,但是里面一些思想还是值得我们学习学习的。
先了解一下什么是敏捷开发方法,作者的描述是“一种把以人为本、团队合作、快速响应变化和可工作的软件作为宗旨的开发方法”。说白了就是保证产品的服务目标不变,根据实际情况不断调整包括项目进度以及产品的功能需求最终做出让客户满意的产品。

敏捷开发之道-欲速则不达
我们可能会经常遇到一个情况,代码出现问题并且急需解决,你可能在不是很清楚整个程序的情况就快速的解决这个问题。但是,如果所有代码是自己写的可能是没什么问题,你也许凭直觉就能安全的解决你面临的问题。但是,很多时候我们编程要么是多人合作的大型项目,要么是基于第三方SDK的项目,整个软件通常都非常复杂。如果不能对自己所用的功能有一个整体的认识,那么即使你解决这个问题也只停留在表面,整个程序依然存在风险。
风险一
代码质量可读性变得越来越差,要知道软件的维护时间要远远大于研发时间。
风险二
如果不能把根本问题找到,说不定什么时候又在别的地方蹦出个致命故障让你夜不能寐。
敏捷开发之道-对事不对人
当你听到有人对你说 “这么简单都搞出了这么多问题”、“这么简单你都要花这么多时间”、“你个弱智,这么简单都搞不定”之类的话你会有啥感受呢?如果别人这么说你的话可能你打他的心都有了,然后你可能也陷入情绪之中,最后不是针对问题去解决问题,而是针对人去解决问题。

敏捷开发之道跟踪变化
做为程序员,你估计有过这样的经历。项目已经立项了,产品定义书也出来了,你觉得你也可以安心实现功能了。但是,某天正在编程的时候一个领导跑过来跟你说要增加某个需求或者要改变那个功能的时候对于程序员来说意味着什么我想程序员们都有体会的。
没有哪个程序员希望自己刚写好的代码删掉再重写另一个功能。但是,事实是产品的需求并非一成不变,可能是产品定义之初并没有考虑到,也可能是后期客户有新需求等等。做为为客户服务的我们发发牢骚后还是只能该干嘛干嘛。
但是在认命的同时要注意两点
(1)保持开发节奏,总不能一天一个需求吧。
[size=18.6667px](2)问问自己为什么要增加这个功能修改那个功能,他要解决什么问题?

敏捷开发之道把握开发节奏
作者有两条建议倒是可以借鉴一下。第一条是下班之前保证今天所写的代码经过测试且没有问题。如果下班之后某个功能只完成了一部分且没有经过测试那就把这部分代码全部删除,明天重写。当然,看上去有些极端。另外一条就是控制好自己的开发时间,不要在一个问题上耗费过多精力耽误项目进度,也不要一味求快做出不满足需求的产品。

敏捷开发之道-提早集成,频繁集成
作者的原意是针对PC端的多人合作的大型软件,这样做可以让问题及时暴露并解决,不能等到代码全部完成了再集成测试。

虽然是针对PC端大型软件,对于我们而言依然有借鉴意义,写完一个可运行的功能模块时要及时测试,不要等到相关功能都完成了才开始测试自己的程序。

敏捷开发之道-使用迭代,增量发布
作者的原意是针对PC端的大型软件或者互联网产品。根据用户对产品的反馈来迭代软件同时增加一部分新功能后发布给客户使用,然后客户再提供反馈,软件再次迭代同时增加新功能直到软件项目最终完成。
在电子行业中,很难做到像互联网产品那样直接通过互联网以及电脑就能让客户使用并提供有价值的反馈。但是于我们而言依然有可借鉴之处。比如,对于做大型软件的电子产品,虽然不能像互联网产品那样收集用户反馈,但是可以借鉴作者的迭代+增量的思想来完善产品。对于大型软件,我们可以以2-3周完成一个可用功能然后发布给使用者,当然这里的使用者更多是测试人员以及产品相关的负责人。通过他们的使用发现产品的不足以及需要改进之处,根据反馈修改功能并增加新功能以便进行下一个迭代周期。但是要注意改进意见不能脱离产品的目标以及基于我们的条件是否可以做到,否则再有价值的意见都没有什么用。

敏捷开发之道-记录解决问题的日志
把遇到的问题简要的写在一个文档中,并写好日期、遇到的问题、以及解决方法。其实就算自己以后再也不会看这个文档了至少自己通过写的问题总结也会对这个问题有更深的认识,**也更为深刻。
敏捷开发之道-对问题各个击破
当程序出现问题时,一时找不到问题,可以把程序分离,通过去掉一部分功能来逐渐缩小问题范围。但是,要很好的做到这一点前提是尽量使自己的程序模块化,能方便的把某些功能隔离出去。
敏捷开发之道定期安排会面时间
作者的原意是对于大型软件的PC项目中由于完成软件的程序员众多,需要经常在一起碰个头暴露出自己遇到的问题,以及通报自己的进展。

这条建议对电子产品的开发人员也同样有借鉴意义,只不过完成的项目成员则是外观+结构+硬件+软件+项目负责人等等。

敏捷开发之道及时通报进展与问题

不要等到产品要交付之前才把问题给暴露出来。需要及时向相关人员通告目前的项目状态,以便相关人员知道目前的项目进度以及遇到的问题。




相关帖子

沙发
红蛋大叔|  楼主 | 2017-10-23 21:55 | 只看该作者

使用特权

评论回复
发新帖 我要提问
您需要登录后才可以回帖 登录 | 注册

本版积分规则

25

主题

69

帖子

3

粉丝