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

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

第1节主要说明虽然书中对软件工程的各个要素孤立来分析，但是其实所有这些要素之间是相互关联的，是一个有机的整体。所以，对软件工程的把握，我们不能将这些要素割裂开来，需要整体来思考。我觉得，作者发明的EHM就是一个很好的架构图，秉着这个秘笈，就算有些弯路，也不会差得太大。

第2节作者谈论自己对RUP的另一个视角——杂物箱。作为一个重量级的软件开发过程模型，他体现了巨大的“包容性”，所以作者把他比喻成一个杂物箱。那杂物箱和专业工具箱的差别是什么呢？其实，专业的工具也都可以放入杂物箱，只是没用的多余的东西也可能混杂其中，所以，需要做的就是定制！一个RUP实在太大太广太全了，以至于不仅难以学习、把握和运用，而且大多数情况也不需要全部都用上，否则不仅无法起到有效的作用，反倒成为一种累赘。所以，对像RUP一样的软件工程模型，我们首先需要根据自己的团队、项目进行必要的定制，才能找到适合自己的软件工程模型。

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

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

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

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

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

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

posted on 2013-07-17 11:03 Tim 阅读(198) 评论(0) 编辑收藏引用所属分类: 品读《大道至简》

只有注册用户登录后才能发表评论。


相关文章: 品读《大道至简》团队缺乏的不只是管理——“体制病”的猛药是思考还是思想——灵活的软件工程思考项目成本的经理——忽略细节，把握关键从编程到工程——系统地分析软件工程失败的过程也是过程——软件工程的模型和过程跟随蚂蚁——软件开发团队管理思想是懒人造就了方法——做思维勤快的懒人为不存在的角色留下沟通的渠道——让项目的历史有据可查流于形式的沟通——沟通需要用心准备

网站导航: 博客园 IT新闻 BlogJava 知识库博问管理

无我

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

导航

统计

公告

留言簿(9)

随笔分类(173)

IT

Life

搜索

积分与排名

最新随笔

最新评论

阅读排行榜