你需要一条怎样的牛仔裤？
1853年，美国加利福尼亚州发现金矿，人们从世界各地涌向这里，一时形成淘金热。一位做纺织品生意的犹太青年商人列维·司特斯（Levi strauss）灵机一动，将滞销帆布制成几百条裤子到淘金工地推销，意想不到大受欢迎。这就是全世界最受欢迎的牛仔裤品牌Levis。
去挖金矿的人是否都找到了金子我不知道，但Levi因为牛仔裤大赚了一笔是事实，不然也就没有现在Levis品牌了。
经常有人问我到底是做什么的，我说是软件工程，然后的对话就是：那我有个APP你能帮我开发吗？后面的对话就是各种不同频率的无法共振~~~。后来我就开始用这个“牛仔裤”的故事来解释，总算是可以少费点口舌了。说软件工程买卖仔裤的，还真是挺准确的，这是wiki上对Engineering这个词的定义：
Engineering is the application of mathematics, empirical evidence and scientific, economic, social, and practical knowledge in order to invent, innovate, design, build, maintain, research, and improve structures, machines, tools, systems, components, materials, and processes.
https://en.wikipedia.org/wiki/Engineering
软件工程（Software Engineering）解决的是如何做好软件开发（Software Development）的问题，使用来自于科学，经济学，社会学以及日常中总结的各种方法，经验来帮助软件开发团队做好软件。说得好玄乎~~~实话实说，我也是今天才仔细琢磨了一下这个定义，翻译过来好高大上。不过话说回来，琢磨一下自己干的事儿，这些玩意还真都用得上。
好吧，我们先来看看到底什么是软件开发。
软件开发的本质
软件开发不就是把软件做出来么？这有什么可解释的？那我们比较一下同样是把一件东西做出来，软件开发和制造一辆汽车的过程有什么不同么？
最大的不同就是汽车下线以后是不能再回炉的，而软件是要经过多次回炉才能出厂的。没有哪个4S店允许你把车子送回厂家换个椅子啥的吧？可是你手机上的APP可是隔三差五在更新，每次更新可都是在“厂子”里从新过了一遍生产线的结果。如果你注意一下你用的app的版本，就算是你拿到的第一个版本，版本号也绝不是1.0；这意味着这个APP已经回炉了不知道多少遍了。
一个汽车工厂里面积最大的部分应该就是生产线了，在这个生产线上要完成所有零件的组装。如果按照这个思路去看软件开发，那么所谓的生产线就是“编译打包”或者说“持续集成”过程。你一定要问，为啥不是写代码的过程？因为在代码写出来之前，软件都处于设计过程，“零件”还没成型啊！你想想，上了生产线的汽车零件还允许工人现场打磨一下，修改一下尺寸吗？如果是这样，这个车你敢买吗？但软件的生产过程中的大部分时间，以及基本上所有参与者（包括写代码的程序员）都在进行设计工作，都是设计师，而不是工人，真正完成装配过程的“工人”是编译器，CI系统等已经高度自动化的程序。
这就是为什么管理程序员不能像管理工人一样，因为你需要他们去创造，而不是拿着做好的东西进行装配。同时，软件开发的本质也就决定了用管理工厂的思路来管理软件开发是行不通的，这也就是为什么用“瀑布”模式来管理开发过程会很别扭。
那么如何做好软件开发？那就是本文的重点，你需要一条怎样的牛仔裤？
软件工程的本质
先讲一个关于电厂的故事，这个故事来自于
http://mindwind.me/blog/2015/02/09/%E8%BD%AF%E4%BB%B6%E5%BC%80%E5%8F%91%E7%9A%84%E6%A0%B8%E5%BF%83.html#rd
记得有个给我们上培训课的主讲老师是个须发皆白的老先生，进门后掏出一堆零件放在讲台上， 一盏酒精灯、一个小水壶、一个叶片、一个铜光闪闪的小电机、一盏小灯泡。 老先生往壶里倒了些水，点燃酒精灯，不一会儿水开了，从壶嘴里喷出了蒸汽，带动叶片旋转，然后小灯泡就亮了。
他说：这就是电厂。
他还说：如果烧的是煤炭，这就是燃煤电厂；如果烧的天然气，这就是燃气电厂；
如果获得热能的方式是核裂变，这就是核电厂；如果带动叶片的能量来自水从高处流向低处，这就是水电厂。
老先生说：你们或许会问 “那我们看到的电厂怎么这么复杂”，答案其实很简单， 电力项目需要复杂系统的目的，一是为了确保安全（Safety），二是为了提高效率（Efficiency）。
安全和效率就是工程技术的本质，在软件工程中，我们对“安全”的理解会更加宽泛，可以换做“质量”。
既然开发过程的大部分处于“设计”阶段，那么也就意味着在上生产线进行装配（编译打包）之前，软件一直处于不确定状态，因此传统的确定需求，完成设计，确保100%按照设计执行的思路是行不通的。我们必须找到适合软件开发的工程技术，这才出现了敏捷开发，极限编程，Scrum，Kanban等等；这些方法的本质都是要构建一个高度自适应的系统，以便适应这个不确定状态，所以软件开发中的效率问题的解决不是传统的标准化流程的思路，而是不停变化的思路，乍听上去会觉得一个不停变化的系统怎么会效率高呢？当然，最高效的系统一定是步调一致，统一执行的。软件开发系统其实也是这样，只是这个系统从一个高效状态到另外一个高效状态的转换是非常快的，可以说是在随时变化的。
解决了效率问题，我们来看看质量。什么是质量？我们再来讲一个故事：
一位老者去理发店剪头发，第一次去的时候理发店的店员非常热情，端茶送水，帮老者洗头，剪发，吹干，然后毕恭毕敬的送老者出门，收了30元的费用。老者很满意，过了1个月又去了这家理发店，这次店员没有迎来送往，只是剪了头发，也收了30元费用。老者虽然心里不高兴，但是头发是剪了，也算是OK了。又过了1个月，老者又去理发，这次店员再次笑脸相迎，全套服务，老者很高兴地走了。再过了1个月，老者又去，这次老者对着店员提了一个问题：我这30元到底买到的是什么服务？
我们再来举个例子：全世界质量最好的汽车是丰田汽车，但你知道为啥是丰田汽车吗？那是因为如果你买了一辆质保3年10万公里的丰田汽车，在第4年/11万公里的时候它出现问题的几率比其他厂商的品牌要高！对你没听错，要高！
结合这2个例子，你应该会理解质量到底是什么了？虽然作为消费者，你会觉得这个丰田车质量定义有点无法接受，但是高质量永远不是在造万年船，永远是在一定范围内定义的标准，而高质量就意味着偏差小。
软件开发中，制定标准并持续的检查偏差就是保证质量的思路，这里面有很多方法，如：持续集成，测试驱动开发，编码规范，完成规范，流程规范；甚至包括自动化部署，云计算环境的使用等都和质量相关。但是要提高质量，则在标准和检查的基础上还需要“持续改进”。有人问，测试那里去了，测试不是提高质量的方法吗？其实测试只解决了“检查偏差”的问题，要提高质量，以上3个要素缺一不可。
还有一些如微服务架构，SOA，可测试性，可部署性的软件架构思路也都和效率和质量相关。
—
一直想写一篇关于软件工程的文章，可惜总是没有提笔。昨天看了博客园的另外一位朋友的文章，觉得还是应该写一写，就算是一点感悟分享给大家。
这位朋友的文章链接在这里，推荐给大家
http://mindwind.me/blog/2015/02/09/%E8%BD%AF%E4%BB%B6%E5%BC%80%E5%8F%91%E7%9A%84%E6%A0%B8%E5%BF%83.html#rd
请关注微信公众号 devopshub，获取更多关于DevOps研发运维一体化的信息
