读《构建之法》

开篇提到的现实世界中软件工程师的职业发展与教科书上经典的瀑布模型刚好相反的观点，让人眼前一亮。

学校里教的开发流程是这样的：需求分析 —> 设计阶段 —> 实现阶段 —> 稳定阶段 —> 发布阶段 —> 维护阶段 。

而实际工作中，你会发现是这么干活的：

1. 刚进入公司，开始学习维护一些已有的软件（维护阶段），当然会有个前辈带你
2. 能够在项目中改些Bug，发布小规模的更新版本（稳定/发布阶段）
3. 有机会重写或者开发一些较小的模块（实现阶段）
4. 表现好的员工，有机会设计较大的模块，写一些文档（设计阶段）
5. 逐渐成长为团队的骨干，有机会计划新的项目（需求分析）

后面吧，没多少新意和亮点，多多少少之前都听过／看过。

有些东西需要一定的工作经验（代码量）才能更好地理解。
代码写得多了，会形成一种感觉／意识，也许会捕捉不定，难以描述。但忽然有一天你看到了某种模式或者方法论之类的书或文章，会恍然大悟“奥，对对对，我想说的就是这个”。或者之前某个概念理解的有点模糊，代码写着写着忽然就明白了“奥，原来说的是这个意思”。

总的说，书还不错。
但是，纸上得来终觉浅，绝知此事要躬行。

• 听了那么多大道理，为什么依旧过不好这一生？

• 每一代人都想把自己走过的弯路和得到的教训传递给下一代，结果是每一代人都执拗的去走了属于自己的弯路，这就是我们的宿命。