大道至简第六章读后感

作者作为一名从事于软件行业的专业人员，已经在此浸淫了很久，却也曾陷入语言的误区，曾像大多数开发人员一样热衷于争论语言的优劣，经过很久才意识到语言只是工具，成天讨论这门语言好，或者那门语言坏的人甚至是可悲的。语言只是工具，这是真正理解工程，软件工程的第一步。

作者在这张图中阐述了代码、方法、过程、与组织的关系，在最内层的环中是编程的本源定义，是最原始的状态，与代码相关的任何工作最终都回落足于这样一条规则。长期的编程实践，自然的归演与总结，必须沉淀为某种（软件开发）方法，于是“过程”出现了，”“对象”出现了，于是相关的方法论也就出现了。这是实践的成果，方法并不是由某个人或某个组织创造的，是实践积累的结果。只有从不断的实践中才能总结经验和方法，经验来源于回顾、理解与分析，而不是你将要写的下一行代码。

过程伴生工程而出现，解决的是工程中角色间的关系问题，说的是团队如何组织在一起进行开发的问题。它首先把工程中的环节分解出来，这样，有了环节，就有了角色；有了角色，就有了沟通。因此过程中的问题，就是角色、沟通和环节的问题。

最狭义的工程，是描述“做什么”和“做到什么”。也就是说，是对目标的描述和成果的检测。至于这个工程目标的实现，是“过程”和“方法”的事；而有效、快速地实现“过程”和“方法”所需的，就是“工具”。过程伴随工程而出现，解决的是工程中“步调一致”的协作问题。而工程的出现根本原因是软件规模的不断增大，以及项目的“复杂”，要求不同的知识领域的角色参与，一个人是难以胜任的，要求更多的( 人力、技术与管理) 资源。“团队”作为开发行为的模式，是软件规模和复杂度渐次累积的结果。团队必将越来越庞大，因为( 与工程对应的) 软件规模必将越来越复杂。没有团队意识的软件公司将在高度过程化、通晓方法理论、拥有大量工具的集团军面前必将一触即溃。

工程理论是包含组织学的。如果说工程关心的是“需求”、“配置”和“文档”等等这样一些要素，那么这样的工程还是停留在技术层面的：关注的还是工程的实现细节，而非目标。从角色的角度来看，这是项目经理和技术经理所共同关注的那一部分。然而项目经理还必须关注于人力资源、项目资金以及多个项目之间的协调等等。这些与工程本身并没有直接关系，而是“组织”方面的内容。

真正的BOSS是经营者 BOSS(经营者) 决定了一个方向，组织者保证决策与这个方向是同步的，而工程是在这样的一个方向、决策的构架下的一个具体行为。

工程中没有BOSS。

从最初的简单编程开始，到现在工程团队的组织开发，实现( 一个软件) 都是最终的目的。所以可以这样说：实现，是软件开发的本质需求。它贯穿于始终，一切都是基于它而产生的。软件工程的体系中，“实现”作为软件开发的本质需求和基本动因，如同上帝之手在推动这几十年来的软件工程理论体系的形成。

从编程到工程，这当中有一步巨大的跨越。