0x1 No Silver Bullet
1 There is no royal road, but there is a road
软件工程缺乏一剂良药，在硬件成本随着发展速度快速下降的同时，软件工程的成本并没有出现明显的下降，然而，随着软件工程持续的、坚持不懈的发展，软件工程正在发生着重量级的变化。
2 Does It Have to Be Hard?--Essential Difficulties
必须观察到异常不是软件进展如此缓慢,而是计算机硬件进步太快。没有其他技术文明能够像计算机硬件这样已经六个数量级在性能价格上涨30年。没有其他技术可以以这样的速度提高性能或降低成本的。这些收益从计算机制造装配行业流转到加工制造工业。
一个软件实体的本质是联锁的构造概念:数据集,数据项之间的关系,算法,以及调用的函数。这本质上是抽象的,这样一个概念性的构造在不同的表现形式下都是一样的。它无疑是非常准确和丰富详细的。软件设计的难度不在于计算的精确度和功能测试，但是更重要的是规格说明书的设计和概念意义上的结构。
现代软件系统的固有属性决定了软件开发发展的难度:复杂性、整合性,可变性和不可见性。
复杂性：团队成员之间交流困难导致产品缺陷,成本超支、进度拖延；难以列举所有程序的可能状态导致程序是不可靠的；函数调用函数的复杂性使项目难以使用。难以扩展程序新功能而不产生副作用造成结构的复杂性。
一致性：虽然说软件工程并不是唯一复杂的学科，但是同样面对复杂对象的物理学家，由于大自然的规律，他们有统一的规律可以遵循。
易变性：软件产品是嵌入在一个文化的应用程序,受制于用户,法律,和机器。所有这些变化不断,他们无情地把改变强加于软件产品的变化。
不可见性：软件不像地图可以绘制出几何图层便于理解，在空间中往往是难以理解的。
3 过去的小突破
3.1 高级程序设计语言：它使一个程序的偶发复杂度。抽象的程序包括概念结构:操作、数据类型、序列,和交互。具体的机器吗是和寄存器,条件,分支,通道,磁盘等相关的。在某种程度上,高级语言构造了一个较低的抽象程序，极大降低了编程的复杂性。
3.2 分时系统：分时系统带来了一个重大的改进，提高了程序员的生产率和产品质量，
尽管不像高级语言带来那么大的作用。但是分时产生了一个截然不同的困难。分时需要及时保存信息。批编程的缓慢轮转意味着会不可避免地忘记细节,如果没有恰当的时机刷新内存就直接进行编译和执行。这个中断是昂贵的,必须不断地更新内存。
3.3 统一的编程环境
4 潜在的良方
4.1 Ada and other high-level language advances.
Ada哲学比Ada语言更多的是一种进步,因为这是模块化的哲学,抽象数据类型的层次结构。
4.2 Object-oriented programming：提供了封装机制
4.3 Artificial intelligence：关于人工智能存在两种定义，使用电脑来解决问以往只能通过人类的智慧来解决的问题；使用一组特定的编程技术被称为启发式或基于规则的编程，让计算机模仿人类解决问题的方式。事实上，真正的人工智能是无法实现的。
4.4 Expert systems：专家系统是一个程序,包含一个广义推理引擎和一个规则库,需要输入数据和假设,通过推理规则库可诱导产生结论和建议,并提供解释。推理引擎通常可以处理模糊或概率数据和规则,除了纯粹的确定性逻辑。
0x2 big ball of mud
我认为这依赖于良好的编程习惯，如果能够在编程的同时进行系统化模块化测试，那么编程效率就会大大提高，处理Bug的速度也会加快。
除此之外，代码是需要不断进行完善精简的，不能因为眼前的Bug就随便修改代码，破坏了当初设计的代码的结构，软件的架构也非常重要。
所谓大泥球，是指杂乱无章、错综复杂、邋遢不堪、随意拼贴的大堆代码。这些年来，为了对付这个泥球，多种指导方法一起出现，然而实际情形没多大变化，“大泥球”看起来仍然是设计软件架构的最常见方法。我们现在惯用的敏捷性开发的很多方面会直接导致泥球，包括：缺少前期设计、应对需求变化过晚、应对架构变化过晚、碎片式增长。
那么我们如何发现烂代码？烂代码要不要改呢？应该怎么改？如果烂代码不是先天性的，那是不是可以预防？
程序是面向用户的，为了方便应用的更新，应提前设计好程序的结构，便于后续优化。
我们团队的代码中也肯定存在着大泥球，这需要我们不断进行完善。
0x3 CatB – Cathedral and the Bazaar
我感受比较深的一句话是——如果你把公测参与者作为最宝贵的资源来对待，那么他们就会成为你最宝贵的资源。我们需要扩大软件的用户群，这样才能更好的完善功能。
尽早和尽量频繁的发布是Linux开发模式的一个重要部分。然而对于一个大型工程来说这并不是个好办法。因为早期版本几乎就是问题版的同义词，而过早地发布会把用户的耐心消耗殆尽 。但是随着功能的完善，可以进行预发布来测试软件的稳定性。
0x4 Lost in CatB这些情况在你的团队中出现过么?
作者主要讲述了开源软件中的过度依赖问题。我自己在写程序的过程中，常常为了方便调试把测试文件放的到处都是，也没有集中在同一个目录下，这样在后期的软件维护过程中造成了很大的不便。
在今后的开发中，我们团队将固定好软件结构框架，保持结构思路的清晰。
0x5 Managing the development of large software systems: concepts and techniques
我觉得瀑布模型的其核心思想是按工序将问题化简，将功能的实现与设计分开，便于分工协作，即采用结构化的分析与设计方法将逻辑实现与物理实现分开。瀑布模型将软件生命周期划分为软件计划、需求分析和定义、软件设计、软件实现、软件测试、软件运行和维护这6个阶段，规定了它们自上而下、相互衔接的固定次序，如同瀑布流水逐级下落。
瀑布模型有利于大型软件开发过程中人员的组织及管理，有利于软件开发方法和工具的研究与使用，从而提高了大型软件项目开发的质量和效率。而对于我们这种较小规模的软件开发项目，瀑布模型并无裨益。
0x 6 软件工程的方法论到底有多少用处?
现代软件工程方法论大致可以分为重方法论和敏捷方法论两大阵营，在很多书籍中将它们之间的区别总结为"文档量"的重与轻，实际上有些以偏盖全！如果从对开发工作的影响角度看，它们之间更重要的区别在于：重方法论更加强调前期设计，为未来设计；而敏捷方法论则更加强调只为现在设计，未来再重构它！而就是这个最为本质的区别才是根据项目实际特点进行正确选择的基础。
在软件技术的发展道路中，方法论起着决定性的作用。软件技术人员有必要站在哲学的高度、从方法论的角度，重新审视软件开发过程中各个环节，深刻体会软件工程和方法论的联系，从而改进和发展的现有的软件工程技术，消化吸收先进的思想、方法和技术，提高软件的质量和生产率，以适应现实世界对软件产业新的要求。软件工程应运而生。为了更好地发展和改进软件工程技术，我们有必要从方法论的各个角度分析软件工程的方法、工具和过程，从而有的放矢地改进软件工程中各个过程的思想、方法、模式和规则.