架构之美初次阅读的简单评价

说明：

 

买了那本的架构之美，我不知道是我有成见，还是这些杂文的作者；总之见得多了，总会有一些关于具体问题上谁更对、谁更错的判断。

 

不过观念上的补充肯定是必要的。具体的知识远没有个人感受来的有价值，这是一个体会。

 

介绍部分：

 

国内的某些作者我就不评价了，对个人的风格想必大家也都很熟悉了。

 

序：

 

 作者怎么怎么NB就不谈了，总之是干模型驱动、UML的。

 

“构建引擎”这部分对Ivar Jocobson的基于用例完成功能做法的评论和回答很有意思。

 

提倡基于数据、驱动引擎的做法也是我这些年思考、观察、实践的结果；但是对于构建、“自动传播”和他对元编程的理解，我不敢苟同。

 

很显然，不能严格遵循DRY（体现为构建时碰见的麻烦）是此人的苦恼，而之所以不能解决是缺乏必要的认识和手段（比如他号称的元编程）。

 

对于熵增，此人也有点不求甚解。熵的关键词在于，*密闭*的系统下，而他却很遗憾的忽略了。

 

就人类现阶段而言，我们处理的永远是开放的系统，如果错误的以热力学作为行事哲学，就陷入了仅能改良的境地。

 

比如他的“自动传播”的想法，有点相当于自动化构建中的一些元素；这实际上是一种头痛医头、脚痛医脚的解决，并非真正的良策。

 

我个人的想法若想真正解决，则必须改变传统的架构视角，采用知识管理的看法进行指导，这是一种我正在尝试的方式。

 

他在文章前部提到的范式与factoring之间的关系，是一个好的开端，可惜没能继续走下去。

 

具体到他的问题和他采取构建时自动传播这种应对措施，其祸害在于这种机制不够灵活最终又会变的难于管理。

 

总之，此人必定有很多“抵制熵增”的经验可供借鉴，不过这也足以引起警惕；以我个人之浅见，在此之外总可以寻找更好的解决。

 

正如XXXX所说，碰见问题是因为我们采用了错误的办法；一旦选择了正确的那个，如何应对则成了根本不存在的伪命题。

 

前言：

 

基本上就是产业周边人员的瞎JB总结，希望给本书一个基调。我倒是可以给他们的一个问题一个备选答案：为什么找不到“桌面软件架构”的作者。

 

这基本上是因为关于界面的部分，在这个领域到今天为止，还没有一个真正成功的架构。一方面是因为不需要，一方面是因为复杂性。

 

不需要是因为大多数界面集合的复杂性必须在用户可接受的范围内，这就造成了其最高程度不会超过某个极限；再多的麻烦也至少能够得到暂时的解决。

 

第二在于，这个复杂性看似虽然有限，但却非常难于管理。界面作为人机交互的媒介，被来自于各个方面的因素所制约，很难找到一种统一的意见。

 

所以成熟的桌面软件开发人员，不能容易的梳理自己的经验、也不敢向其他所谓架构师那样，轻易的做出各种各样的论断。

 

有兴趣的调查一下真正（区别于Web）的MVC实际上是多么受限的一种样板、而进一步的尝试（如HMVC等）又如何复杂和不成功，就会有所了解。

 

其他部分：

 

最有用的一部分是每个人都干了什么，这会给阅读本书一些稍微有用的指导：哪个人在哪部分发表什么样的意见更可信。

 

第一章：

 

两位作者基本上就是搞软件工程的吧？总之没有什么太吓人的简历啦。

 

这一章本身也缺乏真知灼见，基本上就是软件从业人员一贯的自我感觉良好和不精确：大段的废话企图给“架构”下定义，并试图描述方方面面，结果还是没能成功。

 

但这一章也不乏可借鉴的内容：作为有经验的开发过程参与者，我们可以试着使用他们的经验和视角评估自己的项目，这或许会带来一些平常不曾注意的新看法。

 

第二章：

 

这位作者写过一本书：《编程匠艺》，这本书我粗略翻过目录，属于那种有不少有用经验但不怎么吸引人那种。

 

本章在技术方面，应该和那本书一样，充满了我们已经或本该知道的陈词滥调；但由于篇幅较短，我们很难在这种文章中得到必要细节和需要的内容。

 

（其中也不乏一些我一再批判的草率“结论”式论述，不过我现在已经逐渐理解开发社区中各个作者之间的相互影响了。）

 

不过本章还是有些方面需要引起注意：架构带来的灾难对团队和个人的影响；以及最后一节中问到的几个问题，在我们平时学习和实践中不妨多做总结。

 

后面的章节还没看。我个人一些多余的话：

 

“足够简单，但不要更简单”，这类的论调在这短短的阅读中碰见了似乎两次。我对这个概念开始其实是接受的，但现在有了疑问。

 

这句话非常容易沦落成我们自己骗自己的借口。往往当我们无法让事情变得“更简单”的时候，我们就认为“足够”了，进一步就过头了，但这未必是客观的。

 

最近看内核代码（刨除那些垃圾的厂商代码），Linux社区的一个口号就是KISS，我觉得有必要展开一下：“Keep it Simple and STUPID”。

 

一个我个人感觉应该强调的就是这句话的强烈程度。我曾经很喜欢那种我认为“不能”再简化、但仍旧精巧的结构，似乎它们是我们软件人员足够聪明的证明。

 

但现在，我越来越多的认为，凡是我看见的任何“不平凡”的设计，基本全都是设计错误的结果；我严重怀疑可能根本没有“不能”的例外存在。

 

最近在看Android中PacketVideo公司的OpenCORE，以及对这一部分的使用；对比内核，我个人感觉它的设计应该属于比较失败的。

 

因为没有时间完全掌握，我不能说它一定怎么样，但一个非常明显的特征是，摸清它的脉络，要比内核困难的多。

 

（最近Android 2.1的通用版本不能正式发布，基本上主要BUG都集中在这一部分；Google也开始试验新的方案）。

 

反过来观看内核，即便各个厂商挂进了很多脏东西（尤其是Google/HTC/Qualcomm部分），算上那些满天飞的宏，也比它容易顺藤摸瓜。

 

从这种对比可以很明显的看出，一个系统的基调部分会给后续部分带来多么大的影响。

 

（另一个体会是，凡是体现出复杂性的架构，往往都出现在以面向对象为基础并使用相关工具的设计中，这也是值得玩味的一件事情。）

 

很有可能的是，简单到Stupid，也许在任何项目中都是可能的，关键在于我们有没有对问题的真正理解，让我们可以去找到它。