[笔记]软件框架设计的艺术

fasiondog · · 676次浏览 ·

0_13108376858MK5_thumb思想未必是最新、最独特的,但一定是有用的!

正如该书“阅读指南“中所说,该书比较啰嗦。不过,老外有此风格的不是一个、两个,忍了。

全书的主题紧紧围绕”无绪“的概念进行,所谓”无绪“,就是指某些事情并不需要对背后的原理、规则有深刻的理解,就可以使用。典型的,不懂得汽车的原理,但我们照样开车,而且开得还不错。当今,软件开发世界中,更多的应用往往只是将不同的框架、组件进行集成,以满足自身的业务需求,而对这些被集成的”部件“并不一定需要深入了解其背后的细节、原理。这也导致了软件开发从严谨的结构化设计(一步步分解、整合设计出全新的系统)向如何更好的”集成与拼装“设计转化,也是敏捷开发得以盛行的基础,因为不需要从无到有的进行创造。当然也有不好的后果,更多的分不清需求和设计之间的界限,系统设计和详细设计之间的界限,也不想分清。

其实这本书,最吸引我的还是作者本身提供的很多自身案例,对我们自身的工作方式有很多启发,摘录一些分享:

知识传递的困难:

”想要将知识传授给其他人的时候,就会因为他们没有类似于我们的经验,也就很难说服他们接受我们的知识“

程序员的骄傲:

”P2 一年后,我证明了当时的这一猜测。因为Netbeans是一个开源项目,有一个API吸引了一个外部的开发人员。开始的时候,这位外部代码贡献者主要是做一些修复Bug的工作。随后,他开始单独负责一个子项目,并设计相关的API。原先负责设计这个API的人说他发现这个子项目的API变得越来越差,但他找不出原因,希望我帮一手。他说:非常不喜欢这些新的API,更不想把它们集成到他负责的项目中。但他也同样说不清楚这些新的API到底有什么问题。最后,他说这些新的API看起来和他原来的设想不一致。我曾经也对他说过类似的话。以我的标准来评价的话,他所编写的API与NetBeans的API的设想不一致!“

Java世界的”迷炫“:

P111 2001年,我们给JavaOne大会提交了一份名为“组件定位与协作”的议题,该议题中的内容与本章多少有些关系,我们认为该议题涉及的内容对于所有的模块化程序都很重要。然而,当时的JavaOne会议的组委会可能仅仅因为觉得这个议题的名称不够酷,或者可能因为他们觉得组件这个词用得太滥了,要知道“组件”这个词几乎包含了所有可以想象的内容,所以没有接受该议题。直到2006年,我和同事Tim Boudreau又提交了一份类似的议题,名为“模块化架构中那些发现注入和依赖注入的模式”。果然,如我们所料,议题被组委会接受了。这说明一定要找到能够贴近目标人群的术语才能打动他们。一旦听到“依赖注入”这个词,他们的心就被打动了。就像API这个词一样,恰当的名称有益交流。对于用户来说,他们越容易理解API这个词,就越容易接受API的相关内容。

留一条路给自己,扁鹊的大哥没那么好做:

开发人员抱怨的事项总是不断,如评审、编程规范,等等。但API监护人需要时刻保持警醒的状态,否则就可能因为一个小小的疏忽而引发问题。另一方面,不是出个小问题,至少说明了你所做的工作确实很有用。

整理:fasiondog

笔记思维导图下载地址:http://note.sdo.com/u/1517210336#/n/qrIHw~jy6hZFnM00401hmP


发表评论

电子邮件地址不会被公开。 必填项已用*标注

我不是机器人*