是思考还是思想——灵活的软件工程

是思考还是思想——灵活的软件工程

       《大道至简》第八章“是思考还是思想”看起来就像一个杂物箱，里面充斥着作者的一些零散的、片段式的文字。不知道是不是正如标题所说：作者这些看似杂乱的想法，到底是他的思考，还是思想？

         第1节主要说明虽然书中对软件工程的各个要素孤立来分析，但是其实所有这些要素之间是相互关联的，是一个有机的整体。所以，对软件工程的把握，我们不能将这些要素割裂开来，需要整体来思考。 我觉得，作者发明的EHM就是一个很好的架构图，秉着这个秘笈，就算有些弯路，也不会差得太大。
         
         第2节作者谈论自己对RUP的另一个视角——杂物箱。作为一个重量级的软件开发过程模型，他体现了巨大的“包容性”，所以作者把他比喻成一个杂物箱。那杂物箱和专业工具箱的差别是什么呢？其实，专业的工具也都可以放入杂物箱，只是没用的多余的东西也可能混杂其中，所以，需要做的就是 定制 ！一个RUP实在太大太广太全了，以至于不仅难以学习、把握和运用，而且大多数情况也不需要全部都用上，否则不仅无法起到有效的作用，反倒成为一种累赘。 所以，对像RUP一样的软件工程模型，我们首先需要根据自己的团队、项目进行必要的定制，才能找到适合自己的软件工程模型。

         第3节“UML与甲骨文之间的异同”其实就是再次回到沟通的问题，对一个团队而言，无论是UML，还是甲骨文，只要有明确的规约，而且大家都能很好的接受，就是很好的沟通语言。反之，则UML和甲骨文都没有区别，因为缺少规约和说明的图案，都是天书。 这个道理：其实是说明沟通不要追求更不要限于形式，ML固然显得很专业，但是如果不能被广泛接受，那么“聚室而谋”这种最简单最原始的做法可能效果更好。沟通本身是一个最基本的问题，如果能简单化，未尝不是一件好事。事实上，我认为，如果“聚室而谋”广受欢迎，那么说明这个团队的关系和氛围都很好，对沟通的效果更是相得益彰的！

         第4节讨论的是软件工程中的角色问题。不同的角色，他们的关注层面是非常不同的。不要期望BOSS理解某种设计显得多么优美，也不要期望Programer多么考虑为项目节省成本，要铺就这个天堑中的桥梁，正是项目经理这个角色的职责之一。 意识到自己角色的定位、职责，是做对、做好事情的前提！

         第5节谈到软件工程中的一对矛盾：目标（产品的功能和交互的时间）和产品的质量总是一对难以调和的矛盾。不过，没有谁能告诉你彻底解决的办法。就类似于无论硬件性能的如何提升，都无法满足软件无止境的需求一样。或许，这对矛盾将是永远困扰软件工程的问题。

         第6节“枝节与细节”，再次提醒软件工程管理人员，很多时候确实需要关注一些细节问题，以保证产品质量。但是做决策的时候又必须学会忽略细枝末节的问题，只有把握整体才是关键，才能做出正确的决策。

         第7节作为全书主体内容的最后一节，作者以一个命题来表达了对软件工程的总体看法——灵活的软件工程。软件工程是一系列严谨的过程，但又需要灵活的掌控。不要拘泥于软件工程各个过程的形式，正如作者说的：“所以死读一本《软件工程》的人不会做真正的软件工程”。 只有首先深刻把握了软件实践的思想，谨记软件工程整体的终极目标——实现，然后才可能优化地配置和组织所有的环节和过程，才能真正的做好工程。

         灵活的软件工程，这是结束《大道至简——软件工程实践者的思想》一书的最后一个思想。