敏捷开发的入门
现在互联网行业的开发工作或多或少都受到敏捷的影响,都讲究持续迭代,持续集成。构建最小可用的应用,及时反馈,而不是等造完了火箭之后发现原本的需要是要造个飞机。
每天站会,应该也是从敏捷延伸出来的概念。不过公司这边每天的站会越来越流于形式了,很多时候我们确实不怎么关心别人的进度,而是为了证明自己干了活。站会本来的目的应该是及时暴露风险,不过我们也确实达成了这个目的。
对于 tdd 的理解确实又加深了一些,不是所有场景都适用于 tdd。tdd 更多情况下应该用于稳定的功能,以及测试先行,当你写一个方法时,就要明白它的输入输出是什么样子的。这样子,其实自己大脑也会清晰很多。
以及项目时间的预估,自己真的能否清除预估准确别人的时间。“做事所花费的时间总是比你预期的要长,即使你的预期中已经考虑了侯世达定律”。书中给的解决方案是建议故事点法,大家一起来对难度规模做一个估计。每个人有自己的点数,这样子会相对准确一些。不过还是要有功能缓冲和进度缓冲,还是要做任务拆解,优先保证核心功能。
基于分支的开发,有个问题确实比较严重,如果别人对你的方法有依赖,你很难对这些方法做一些重构的优化,比如重命名或者是修改参数。因为你的修改在合并主分支前对依赖方是不可见的。等到依赖方將其分支合入主分支的时候,就真的是火葬场了。
代码审查我一直觉得也是很重要的东西,但公司这边确实实践得很少。
现在就只能吸收这么多了,未来有新的感悟可以再回来看看。
有关键情节透露