循序渐进，步步为营
编程是艺术，开发是工程
比起一门编程语言，软件工程的入门过程，要难得多。盖因一门语言，其语法、关键字、系统库和常用工具，总是确定而有限的。
而软件工程，作为工程学的一个门类，它肩负着在软件开发的过程中，将种种条件确定下来，将资源安排妥当，使工作过程确定清晰，产出稳定可靠的责任。
这其中的微妙和复杂，往往在经典的教材中也不能充分表达。其中大量与人的协作，与时间的较量，其经验和体会，都是要在实践中才能慢慢积累起来。
这就使得软件工程课程，在学习过程中，常常处于一个尴尬的位置。一方面我们都会宣称它非常重要，另一方面，我们却很难从中得到收益。一方面我们都反对形式主义的软件工程，另一方面因为难以落实，使得我们最终总是在实践中流于形式。
软件工程，作为软件开发的一个基础的知识领域，它的学习过程，也迫切需要一个启动的支点。
在这样的背景下，得到邹欣老师的《构建之法》，对我来说是非常惊喜的事情。这本书很好的解决的这个知识领域“从零到一”的问题。我数了数手头十来本软件工程方方面面的读物，还是觉得，如果你是一个在校生，刚刚开始学习软件工程；或者你是一个刚刚走上工作岗位的程序员，迷惘于如何在形式化的团队开发规程和自负的才华之间找到平衡；甚至你是一个刚刚走上管理岗位的技术领导，第一次从“软件工程的受害者”成为实施者，急于完成角色转换，走上人生巅峰。你都是这本书潜在的目标读者。
Build To Learn 到 Build To Win
Build To Win 是 《构建之法》一书的英文名。这本书很好的阐述了如何逐步改进软件开发过程，邹欣老师将不同的阶段和形态形象的区分为：
• Build To Learn：开发软件，构建系统的目的是做进一步的试验，试图发现客观规律或某个试验方法的优点与缺点。这些项目经常是科研论文的基础工作。
• Build To Show：为了突出地展现某个技术的作用，开发一些演示为目的的软件，这些项目很吸引眼球，经常获得新闻报道，但是功能未必全面。
• Build To Serve：为了服务一定范围的目标用户而构建的工具等，有时以公开的SDK形式发布。
• Build To Win：以在市场上赢得用户为目标而构建的软件。这也是种种科学发现，技术突破最好的试金石。这是我在研究院之外的十余年中做的最多的项目类型，也是这本书的英文名字。
书中有针对性的设计了一个十六周的课表，可以供学校授课时使用，也可以供个人学习者或企业团队实践中估算学习用时。这本书是作者多年在高校实际进行软件工程教学——我们这些同行，都很喜欢看邹欣老师在微博上与学生的互动——的经验总结，可以作为一门课程，在一个学期内完成。独立的学习者，也可以遵循类似的时间线，即从环境和知识准备（代码仓库－测试工具等）到项目规划和组织（由个人软件开发过程开始，引入结对和团队项目形态，以及相关的项目管理和测试工具），再到质量管理、发布、跟踪维护、总结和改进等，循序渐进。
和我以前阅读的其他软件工程书籍一个很大的区别在于，作为教材，《构建之法》的启动过程非常的平滑。有一些读物是按照经典的瀑布模型，从需求分析，概要设计开始——是的，我教过这样的教材。而本书则是从一个微型项目最有可能的起步过程开始：组建团队、准备工具。
从经验来讲，版本管理工具和单元测试工具，也确实是非常适合上手的，这两种工具见效快，学习相对简单，一旦学会，学习者会迅速体验到工程化开发带来的好处：可回溯、可控制、可管理。
在其后，大量的章节用于讨论协作、项目跟踪和控制等环节，书中基本跳过了关于UML的讨论，也没有细致的讨论一个完整的软件项目可能会用到的所有技术。这种取舍非常有必要，也把握的很好。如果深入编程语言或UML这样的方向讨论，会迅速脱离整个软件工程的大范畴，陷入某个局部或者范畴外的某处，难以自拔。
即使对于学校外的学习者，也不应该将这本书视为完整的学习一个项目开发过程的指导，而应该按照这个过程去执行一个自己选择的项目来学习。这样的设定保证了全书的内容专注于软件工程本身的学习，不至于失之繁冗，也可以让学习者从一个技术上对自己比较有利的项目。这个项目所需的技术对于读者应该尽可能比较熟悉，尽量不需要学习太多。毕竟这里我们要学习的是软件工程，而不是编程技术。
书中一个很有意思的地方在于，每一个假设的情景都很活泼形象。事实上我多年以前读过的另一本微软出版的技术书籍，就曾经着重介绍过故事卡片在微软开发过程中的使用。微软的优秀团队很擅长使用这个工具。从我的经验来讲，故事卡也是一个很实用的软件工程手段。它可以作为需求分析的草稿，也可以用来引导思考，建立用例图和概要设计等。即使不将故事卡作为正规工具的团队，个人在工作过程中，建立故事卡也可以很有效的帮助自己。当然有些朋友可能在这个过程中会遇到困难，我的职业经历中，确实比较少见到擅长书写，文笔足够熟练的建立故事卡的同行。但是其实这项技能是可以练习的。只要有心，经过一段时间的训练和联系，普通的工程师也可以写出质量稳定的故事和情景设计。而本书中的情景设计，也可以印证作者对这一工具的运用是比较娴熟的，值得读者学习。
比起一门编程语言，软件工程的入门过程，要难得多。盖因一门语言，其语法、关键字、系统库和常用工具，总是确定而有限的。
而软件工程，作为工程学的一个门类，它肩负着在软件开发的过程中，将种种条件确定下来，将资源安排妥当，使工作过程确定清晰，产出稳定可靠的责任。
这其中的微妙和复杂，往往在经典的教材中也不能充分表达。其中大量与人的协作，与时间的较量，其经验和体会，都是要在实践中才能慢慢积累起来。
这就使得软件工程课程，在学习过程中，常常处于一个尴尬的位置。一方面我们都会宣称它非常重要，另一方面，我们却很难从中得到收益。一方面我们都反对形式主义的软件工程，另一方面因为难以落实，使得我们最终总是在实践中流于形式。
软件工程，作为软件开发的一个基础的知识领域，它的学习过程，也迫切需要一个启动的支点。
在这样的背景下，得到邹欣老师的《构建之法》，对我来说是非常惊喜的事情。这本书很好的解决的这个知识领域“从零到一”的问题。我数了数手头十来本软件工程方方面面的读物，还是觉得，如果你是一个在校生，刚刚开始学习软件工程；或者你是一个刚刚走上工作岗位的程序员，迷惘于如何在形式化的团队开发规程和自负的才华之间找到平衡；甚至你是一个刚刚走上管理岗位的技术领导，第一次从“软件工程的受害者”成为实施者，急于完成角色转换，走上人生巅峰。你都是这本书潜在的目标读者。
Build To Learn 到 Build To Win
Build To Win 是 《构建之法》一书的英文名。这本书很好的阐述了如何逐步改进软件开发过程，邹欣老师将不同的阶段和形态形象的区分为：
• Build To Learn：开发软件，构建系统的目的是做进一步的试验，试图发现客观规律或某个试验方法的优点与缺点。这些项目经常是科研论文的基础工作。
• Build To Show：为了突出地展现某个技术的作用，开发一些演示为目的的软件，这些项目很吸引眼球，经常获得新闻报道，但是功能未必全面。
• Build To Serve：为了服务一定范围的目标用户而构建的工具等，有时以公开的SDK形式发布。
• Build To Win：以在市场上赢得用户为目标而构建的软件。这也是种种科学发现，技术突破最好的试金石。这是我在研究院之外的十余年中做的最多的项目类型，也是这本书的英文名字。
书中有针对性的设计了一个十六周的课表，可以供学校授课时使用，也可以供个人学习者或企业团队实践中估算学习用时。这本书是作者多年在高校实际进行软件工程教学——我们这些同行，都很喜欢看邹欣老师在微博上与学生的互动——的经验总结，可以作为一门课程，在一个学期内完成。独立的学习者，也可以遵循类似的时间线，即从环境和知识准备（代码仓库－测试工具等）到项目规划和组织（由个人软件开发过程开始，引入结对和团队项目形态，以及相关的项目管理和测试工具），再到质量管理、发布、跟踪维护、总结和改进等，循序渐进。
和我以前阅读的其他软件工程书籍一个很大的区别在于，作为教材，《构建之法》的启动过程非常的平滑。有一些读物是按照经典的瀑布模型，从需求分析，概要设计开始——是的，我教过这样的教材。而本书则是从一个微型项目最有可能的起步过程开始：组建团队、准备工具。
从经验来讲，版本管理工具和单元测试工具，也确实是非常适合上手的，这两种工具见效快，学习相对简单，一旦学会，学习者会迅速体验到工程化开发带来的好处：可回溯、可控制、可管理。
在其后，大量的章节用于讨论协作、项目跟踪和控制等环节，书中基本跳过了关于UML的讨论，也没有细致的讨论一个完整的软件项目可能会用到的所有技术。这种取舍非常有必要，也把握的很好。如果深入编程语言或UML这样的方向讨论，会迅速脱离整个软件工程的大范畴，陷入某个局部或者范畴外的某处，难以自拔。
即使对于学校外的学习者，也不应该将这本书视为完整的学习一个项目开发过程的指导，而应该按照这个过程去执行一个自己选择的项目来学习。这样的设定保证了全书的内容专注于软件工程本身的学习，不至于失之繁冗，也可以让学习者从一个技术上对自己比较有利的项目。这个项目所需的技术对于读者应该尽可能比较熟悉，尽量不需要学习太多。毕竟这里我们要学习的是软件工程，而不是编程技术。
书中一个很有意思的地方在于，每一个假设的情景都很活泼形象。事实上我多年以前读过的另一本微软出版的技术书籍，就曾经着重介绍过故事卡片在微软开发过程中的使用。微软的优秀团队很擅长使用这个工具。从我的经验来讲，故事卡也是一个很实用的软件工程手段。它可以作为需求分析的草稿，也可以用来引导思考，建立用例图和概要设计等。即使不将故事卡作为正规工具的团队，个人在工作过程中，建立故事卡也可以很有效的帮助自己。当然有些朋友可能在这个过程中会遇到困难，我的职业经历中，确实比较少见到擅长书写，文笔足够熟练的建立故事卡的同行。但是其实这项技能是可以练习的。只要有心，经过一段时间的训练和联系，普通的工程师也可以写出质量稳定的故事和情景设计。而本书中的情景设计，也可以印证作者对这一工具的运用是比较娴熟的，值得读者学习。
有关键情节透露
