今天我读了《大道至简》的第七章——现实中的软件工程和第八章——是思考还是思想。其中第七章主要讲了现实中的软件工程一些需要注意的地方。而第八章作者则分享了一些他自己在编程过程中的思考和思想。
在第七章的开头，作者便引用了IBM的事例，大公司是如何在软件工程中进行运作。Rational 被 IBM 购并的真实原因在于 IBM 需要构建一个完整的软件工程体系，对于 IBM 来说，Rational 有着 UML 语言的非常丰富的实践经验， 还有着 RUP 作为理论框架的创立者和领导者的地位，这些对 IBM 在确立大型软件工程应用方案提供商的行业形象，都是极大的支持。而另一个开发商：Borland 没有在 ALM 作为工程理论方面的任何优势。于是 Borland 开始购并与实现 ALM 体系相关的公司，其中收购过程改进咨询公司 TeraQuest 并组建流程优化实部，以及收购 TogetherSoft 为开发工具来强化模型构建能力，都是相当大的一些举措。通过这些努力，Borland 快速地补全了 ALM 作为一个工程体系在理论方面的不足。而处于风口浪尖的Microsoft 与 Borland 和 IBM 通购并来达到目的的方式并不相同，Microsoft 有足够的力量全方位出击。所以如今的软件界是大公司之间相互制约的结果。大公司们在标准、理论、语言上的争来夺去，未必全然出于“软件实现”的考虑。对统一理论、统一工具、统一过程的企图，其最终目的是在整个软件工程体系中的全面胜出。
除了软件本质力量的推动之外，商业因素也推动着软件工程体系的发展。文中所画软件工程层状模型可以看出，作者将软件工程划分为实现，团队和经营三部分。从这个模型中可以看到，在“程序”与“方法”层面，是关注于“(具体的)实现”的；而在“过程”和“工程”层面，更首要考虑的是团队问题。从角色的角度上来说：开发经理思考项目的实施方案和管理具体的开发行为； 而项目经理则保障团队的稳定性和一致性。然而这只是基本模式，或者说，是理想模式。
大道至简第八章：刚才说到目标和质量的问题时，提及“平衡时间、资 源和功能三者的关系”。这其实是一个实施过程中的细节。 或者说，它是一个具体的方法，而不是目的。 所以我们通常所说的细节，其实是对实施方法的一些 有限量的描绘。比如“软件工艺”这个概念本身的提出， 就是考究“细节问题”的。从这个角度上来说，我并不反 对“细节决定成败”这样的观点。但请注意一个前提：这 是技术或方法的细部。
软件工程是灵活的，在软件开发中很多常见的问题，一些人不知究竟地使用着技巧和方法，而一旦出了问题，则归究于这些技巧和方法的不好。只能说这些人不会变通，不会灵活的运用，所以如作者所说：死读一本《软件工程》的人不会做真正的软件工程。