构建之法阅读笔记03
编程是艺术，开发是工程
比起一门编程语言，软件工程的入门过程，要难得多。盖因一门语言，其语法、关键字、系统库和常用工具，总是确定而有限的。
而软件工程，作为工程学的一个门类，它肩负着在软件开发的过程中，将种种条件确定下来，将资源安排妥当，使工作过程确定清晰，产出稳定可靠的责任。
这其中的微妙和复杂，往往在经典的教材中也不能充分表达。其中大量与人的协作，与时间的较量，其经验和体会，都是要在实践中才能慢慢积累起来。
这就使得软件工程课程，在学习过程中，常常处于一个尴尬的位置。一方面我们都会宣称它非常重要，另一方面，我们却很难从中得到收益。一方面我们都反对形式主义的软件工程，另一方面因为难以落实，使得我们最终总是在实践中流于形式。
软件工程，作为软件开发的一个基础的知识领域，它的学习过程，也迫切需要一个启动的支点。
在这样的背景下，得到邹欣老师的《构建之法》，对我来说是非常惊喜的事情。这本书很好的解决的这个知识领域“从零到一”的问题。我数了数手头十来本软件工程方方面面的读物，还是觉得，如果你是一个在校生，刚刚开始学习软件工程；或者你是一个刚刚走上工作岗位的程序员，迷惘于如何在形式化的团队开发规程和自负的才华之间找到平衡；甚至你是一个刚刚走上管理岗位的技术领导，第一次从“软件工程的受害者”成为实施者，急于完成角色转换，走上人生巅峰。你都是这本书潜在的目标读者。
Build To Learn 到 Build To Win
Build To Win 是 《构建之法》一书的英文名。这本书很好的阐述了如何逐步改进软件开发过程，邹欣老师将不同的阶段和形态形象的区分为：
• Build To Learn：开发软件，构建系统的目的是做进一步的试验，试图发现客观规律或某个试验方法的优点与缺点。这些项目经常是科研论文的基础工作。
• Build To Show：为了突出地展现某个技术的作用，开发一些演示为目的的软件，这些项目很吸引眼球，经常获得新闻报道，但是功能未必全面。
• Build To Serve：为了服务一定范围的目标用户而构建的工具等，有时以公开的SDK形式发布。
• Build To Win：以在市场上赢得用户为目标而构建的软件。这也是种种科学发现，技术突破最好的试金石。这是我在研究院之外的十余年中做的最多的项目类型，也是这本书的英文名字。
书中有针对性的设计了一个十六周的课表，可以供学校授课时使用，也可以供个人学习者或企业团队实践中估算学习用时。这本书是作者多年在高校实际进行软件工程教学——我们这些同行，都很喜欢看邹欣老师在微博上与学生的互动——的经验总结，可以作为一门课程，在一个学期内完成。独立的学习者，也可以遵循类似的时间线，即从环境和知识准备（代码仓库－测试工具等）到项目规划和组织（由个人软件开发过程开始，引入结对和团队项目形态，以及相关的项目管理和测试工具），再到质量管理、发布、跟踪维护、总结和改进等，循序渐进。
和我以前阅读的其他软件工程书籍一个很大的区别在于，作为教材，《构建之法》的启动过程非常的平滑。有一些读物是按照经典的瀑布模型，从需求分析，概要设计开始——是的，我教过这样的教材。而本书则是从一个微型项目最有可能的起步过程开始：组建团队、准备工具。
从经验来讲，版本管理工具和单元测试工具，也确实是非常适合上手的，这两种工具见效快，学习相对简单，一旦学会，学习者会迅速体验到工程化开发带来的好处：可回溯、可控制、可管理。
在其后，大量的章节用于讨论协作、项目跟踪和控制等环节，书中基本跳过了关于UML的讨论，也没有细致的讨论一个完整的软件项目可能会用到的所有技术。这种取舍非常有必要，也把握的很好。如果深入编程语言或UML这样的方向讨论，会迅速脱离整个软件工程的大范畴，陷入某个局部或者范畴外的某处，难以自拔。
即使对于学校外的学习者，也不应该将这本书视为完整的学习一个项目开发过程的指导，而应该按照这个过程去执行一个自己选择的项目来学习。这样的设定保证了全书的内容专注于软件工程本身的学习，不至于失之繁冗，也可以让学习者从一个技术上对自己比较有利的项目。这个项目所需的技术对于读者应该尽可能比较熟悉，尽量不需要学习太多。毕竟这里我们要学习的是软件工程，而不是编程技术。
书中一个很有意思的地方在于，每一个假设的情景都很活泼形象。事实上我多年以前读过的另一本微软出版的技术书籍，就曾经着重介绍过故事卡片在微软开发过程中的使用。微软的优秀团队很擅长使用这个工具。从我的经验来讲，故事卡也是一个很实用的软件工程手段。它可以作为需求分析的草稿，也可以用来引导思考，建立用例图和概要设计等。即使不将故事卡作为正规工具的团队，个人在工作过程中，建立故事卡也可以很有效的帮助自己。当然有些朋友可能在这个过程中会遇到困难，我的职业经历中，确实比较少见到擅长书写，文笔足够熟练的建立故事卡的同行。但是其实这项技能是可以练习的。只要有心，经过一段时间的训练和联系，普通的工程师也可以写出质量稳定的故事和情景设计。而本书中的情景设计，也可以印证作者对这一工具的运用是比较娴熟的，值得读者学习。
《构建之法》读后感(四)：创新的时机——学习《构建之法》
昨晚（3/12）给团队做了一个分享，叫《创新的迷思》。题目不是我起的，连PPT也不是我写的，是周筠老师发给我的邹欣老师的讲稿。要是换作以前（一个月之前），我是绝对不这么做的，我会添油加醋一些自己的东西，或者从自己的角度去讲。要是换作以前的以前（五六年之前），我连这样的分享都不会做，我会觉得这不是我的东西，没有成就感。当时是OReilly CEO的一句话敲醒了我，他说我们不是在卖书，我们是在传播创新者的思想，这让我认识到传播本身也是有价值的。关于创新的问题，困扰了我很久，直到年前看到邹欣老师的博客文章[1]才敲醒了我，我要把一些认识传播给团队。
言归正传，昨晚讲了2个多小时，72页的PPT，应该分成两次比较合适。内容太丰富了，我这里不重复了，有兴趣的可以直接看邹欣老师的博客文章，或者买一本《构建之法》，在这本书里有专门的一章，比博客文章要系统和完善的多。我这里只分享其中的一个点，就是创新的时机。
其中有个G-number的小游戏：
每个成员写下名字和一个(0, 100)开区间的有理数。最接近G点者获胜，最远者输。G点的计算方法：G = 0.618 * average (all numbers)。
共有20个人参加了游戏（不包括我），我给大家两分钟的时间，对于结果会是多少，我心里是没谱的。你现在心里猜一个数字（记住不要更改）。
你可能会想，大家随机报的话，平均数会是50，50 * 0.618 = 31，那么我选31低一点。但其他人也不是傻子，那大家都选31附近的数的话，我得选31 * 0.618 = 19。那么还得继续往下迭代，我就干脆选0.0001好了！
0.0001是正确答案吗？
我公布昨晚我们游戏的结果：G点值是19.28，一位出了21的获胜，一位出了70的输。
邹欣老师在书上还做了总结，第一次游戏获胜数字一般离17不远，也就是平均进行了两次迭代。
在我公布题目后，就有同学冒出来说接近0，被我制止了呼喊。如果大家脑子转的都足够快，可能最后真的接近0。但某些想的快的同学，并不能决定整个团体的思考阶段。即使写了0.00001，也不能赢得比赛。
在创新的道路上，需要的是领先一步，且只领先一步。我在大三的时候（2003年），上一门人机交互课程。老师剖析苹果公司的Newton产品的例子，就是苹果的产品总是领先市场两步，以至于失败。但从我的分析来看，从2001年苹果发布iPod之后，就懂得只领先一步的道理了，不管是iPhone、iPad，还是刚发布的Apple Watch。
（请在百度搜索Apple Newton）
为什么领先两步不行，我们看下面一张图：
（请在百度搜索跨越鸿沟）
这张图来自于《跨越鸿沟》，描述的是大众对新技术接受的曲线，曲线的面积大致对应人数。大众平均值再往前一步就是早期采用者区间，这里存在一个鸿沟。推出的太早，就跨越不了这个鸿沟。
再换一种角度，Gartner给出的技术成熟度曲线（纵轴是大众对新技术的期望值）：
（请在百度搜索技术成熟度曲线）
可以看到期望值随着时间会出现很大的变化，先后经过技术触发期、期望膨胀期、迷茫期、低调发展期、主流发展期。我们使用的所谓新产品（如iPhone），一般是渡过迷茫期的二代产品，第一代的也许都没等到这一天（如Nokia N70）。
以下是2014年的技术成熟度曲线：
（请在百度搜索 2014技术成熟度曲线）
我所从事的Big Data，还远没过时，处在迷茫期。
一位组员听了报告后的感想：
听完了，发点感悟：内容很丰富，很多例子听起来也很有趣。前半段听的比较仔细，后面太饿了，注意力没有太集中。总体上的感觉是以前理解的创新总是很高大上，很突出的东西，虽然很向往，但是总感觉离自己很遥远。已至于别人提出了可能比较创新的idea，自己也可能是那个泼冷水的人。现在觉得创新体现在我们身边更多是一种微创新，创新也可以是一种从量变到质变的过程，我们做的很多工作从一个点来看是也许单调枯燥的，但从长远来看可能也在为整个互联网的创新贡献着些许力量吧(^_^)
我算没白讲。