这是我读完第三遍才开始写这部书的观后感。说实话，第一遍看的时候，并没有看明白它在写些什么。草草读完第一遍，我开始细读第二遍。知道现在读完了第三遍，我决定下笔开始写这篇读后感。因为我理解了作者写书的意图，正如作者在正文最后的那句话，“死读一本《软件工程》的人不会做真正的软件工程，所以我写了这本书。”
刚开始接触这本书，我以为会是一本介绍编程介绍软工教给我们知识的一本书，但看了之后才知道它确实教给我们知识了，教的不是专业知识，而是作为程序员作为软工者应该具备的社会知识。一个程序，一个软件，做出来你可能觉得很完美，但它不符合上级的要求指示，你所做的努力就没有回报，这是最浅层的意思。往深里说，要求者他不理解我们程序员的工作，他不知道你做程序有多累多辛苦，不知道有些细节或者骨架没办法完成，他只注重你的结果所在。正如第四章所讲的沟通问题客户不理解UML，我们与客户之间只有形式上的沟通。项目经理的重要性不置可否，但那毕竟是少数。这本书读下来更多的是作者发现的作为软件开发者的问题所在，并且给予我们一些可解决的方法和变通的思维。
我觉得这本书的核心所在是后面的几章，说出了编程和工程的区别以及做软件的思维和变通。做软件本来就是一个很灵活的事情。俗话说外行人看热闹内行人看门道，客户看的是表面，并不注重内在的运行，而我们所要做的是把软件做的更精更细。这种差异便让客户与我们程序员之间产生了分歧。这些都需要我们亲身实践过后才能体会得到。正如作者周爱民所说的那样，客户是商人的客户，但计算机不是程序员的客户。
书中还有一些我认为不大合理的地方。作者在介绍编程与工程的关系上时，提出了boss与工程的关系，最后得出“工程中没有boss”这样一个结论。然而作者在书中又有提到过工程失败的原因“在一次次修改之中注入资本而导致工程的性价比降低。”虽然不是书中原话，但我的理解是这样的。这就很奇怪，既然工程中没有boss，并且工程的过程不是死模板，那最后失败的原因为何会是这样的呢？还是因为boss，也就是经营者对于工程的不满而产生的失败，归根结底工程的失败是经营者对于工程的干预。所以工程的经营者就是boss。这只是我个人的观点，我并没有说作者是错误的，也许是理解不同。
说了这么多，回归到开始引入话题还是编程。程序=算法+结构，这是大多人的想法。其实，看了作者的经历与所列举的例子，我认为他的思考是正确的，程序=算法+结构+方法。真正做过软件的人才会有这样的体会，作为java萌新，看的我确实有些“瑟瑟发抖”。
最后总结一下这本书带给我的，是对于程序员这个工作的一个更为明朗的一个认识，也让我看到了软件工程的美丽所在。虽然我是学习网工的，但里面的很多东西，包括对于团队的管理问题，包括对于客户的诸多问题，在包括对于工程的理解以及对于编程的灵活性，是我们所有学习计算机技术的程序员应当学习到的。
这篇观后感仅代表我个人的观点，可能会有不同的见解，随时欢迎讨论。
