构建之法感想

第一次翻开《构建之法》，真的是眼前一亮，这本书与国内高校常规的软件工程教材有本质的不同，这本书写得跟小说似的，而且语言幽默风趣，颠覆了传统软件工程教材刻板生硬、枯燥乏味的形象，相较之下，这本书显得清新脱俗。阿超”、“小飞”、“果冻”、“小李”都是现实中典型的软件行业从业人员形象。我在现实中，就遇到过“小飞”和“果冻”的混合体，毕业刚一年的应届生，看过点代码，相当浮躁，总想着一口吃成大胖子，可是基础薄弱，更缺乏经验，老想着做大功能，总是说之前看过什么，之前做过什么，扯一些名词，他说的东西恰好我也略知一二，于是我便抱着和他探讨的心态，问了他几个问题，他却支支吾吾了半天。没有必要装这种逼，一下子就穿帮了。“看过”和“看懂”是两码事，夯实基础比什么都重要啊。正如书中所说的，“我们要让团队中做事不仔细的人慢下来，这样能减少他们的危害”；另一方面，这种人有热情，能踏踏实实的话，是一定会有成长的，只是现阶段对项目的影响还是“危害”大于“贡献”。
在第10章中提到的如何定义典型用户和典型场景，以及从典型用户到场景，从场景到任务的过程。作者在写书的过程中，也恰恰使用了这套方法论。

有了典型用户之后，我们还得决定每一个典型用户的目标 — 他/她使用系统想要达到什么目的。对于每一个目标，列出达到目标所必须经历的过程，这就是场景，也可以叫故事。

“阿超”、“小飞”就是《构建之法》这本书的典型用户，他们之间的对话就是现实中许多工程师在工作中会遇到的场景，这是“从典型用户到场景”。

场景怎么写？首先针对每一个场景，设计一个场景入口（描述场景如何开始）。接着描述典型用户在这个场景中所处的内部和外部环境（内部环境指心理因素等）。然后给场景划分优先级，按优先级排序写场景。对于刚接触这些估算方法的读者而言，觉得这公式很玄，不知道是否靠谱，只能先了解个大概，以后在自己的实际工作中去体会，去把握。第一次估算不准，多估算几次，从而形成自己的一套关于工作量估算的方法论。

对于书中第6章提到的敏捷开发也是一样。以下是敏捷开发的一种定义。

“
敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。在敏捷开发中，软件项目在构建初期被切分成多个子项目，各个子项目的成果都经过测试，具备可视、可集成和可运行使用的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用的状态。
”

什么时候该使用“敏捷开发”，还是“瀑布模型”。设计的时候是“自顶向下”呢，还是“自底向上”呢，都不是绝对的。需要根据实际的项目情况，去分析，去拿捏，更多时候是多种方式结合使用。

而且软件工程不是单一的学科，它是多学科交叉的一门综合学科。除了要具备工程能力外，还要有良好的基础知识，和一定的架构设计能力，以及必要的沟通能力，不然无法掌控一个大型的软件项目。