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

说明:

 

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

 

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

 

介绍部分:

 

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

 

序:

 

 作者怎么怎么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,也许在任何项目中都是可能的,关键在于我们有没有对问题的真正理解,让我们可以去找到它。

posted on 2010-01-25 19:18  怪怪  阅读(1259)  评论(0编辑  收藏  举报

导航