| 宇峰's profile梦后楼台PhotosBlogLists | Help |
|
梦后楼台当时明月在,曾照彩云归 April 17 关于荒诞摘至《谁说大象不能跳舞》:
荒诞总是存在的,在自己身边也时时发生,而且看起来总是那么有喜感,黑色的喜感。 March 31 陪产假也不如想象中累,买了红牛,没用上。在医院度过那周比较辛苦,毕竟连陪护床都要靠抢的,回家便轻松了不少。 间中基本都在读春上村树的小说,一气读了《寻羊冒险记》,《舞!舞!舞!》,《世界尽头与冷酷仙境》,《挪威的森林》,目前还在读《奇鸟行状录》,渐渐开始能读懂一点春上的作品了,以前读春上的小说,不过是在追求一些“强说愁”式的东西而已。 再次需要看房,好在有套房先住着,可以慢慢来,直觉近期房价应该会波动着缓缓上升,而不会再有06,07年的疯狂。 February 15 基于接口的软件设计似乎有种编程模式是“面向接口编程”,我没了解过那种模式,所以我也无从知道它和我现在想讲的东西是否雷同。或许是不同的几率更大些,毕竟从命名来看,“面向接口编程”强调的是一种开发模式,而我想讲的是设计的方法,还有便是“面向”和“基于”还是有本质区别的。 对于我而言,以前所使用的设计方式似乎是这样的:得到一个需求后,心里产生一种能完成该需求的内部结构,无论是算法,数据结构,或对象结构,设计模式,然后将针对不同的需求得到的东西糅合在一起,便得到了软件的架构。举例而言,比如要设计一个win32上的notepad,自然而然就会想到需要东西去监听键盘信息,又需要代码去排版文字,还要控制屏幕刷新,同时也需要小心的分离逻辑与显示。一步步分析下来,凭借架构师的技术和经验,一个整体的架构便可以被完成,以对象图或者别的什么形式展现出来。在这个过程中,我们可以看到架构师的确如外科手术医生一般,统领全局,从内至外,软件被设计出来满足了需求。如果,只是如果,这个设计流程一反传统的工程式做法,变为从外向内来进行,情况会变得怎样呢? 首先,仍然是需求分析,需求分析的结果自然是产品所需呈现的接口,或许更恰当的说,并非通常软件概念中的interface,而是对需求更精准的划分和组织,即以更软件的术语来描述的需求。这个接口,显而易见的,是对产品真正重要的东西,只要我们能呈现出预期的接口,那么怎样的内部结构都是无所谓的,甚至只要能满足接口,一个对软件产品的需求也可以被非软件产品所满足,比如一个远程打印的需求,当所需满足的接口有且只有:把存储在办公室电脑里的文档在打印室打印出来时。那么一个传递优盘去打印室的秘书就而已解决这个需求。只有当边际成本等因素成为接口时,一个切实的网络打印协议才有被设计并实现的必要。 当我们得到大体的接口定义时(之所以是大体,是因为我们永远无法得到所有的接口定义),进一步的设计就可以开始,在这一步,架构师不再需要单兵作战,因为最重要的接口已经被定义出来,可以随意组织的内部结构显然更适合集思广益,一个无论多荒诞的内部结构提议,比如传递优盘的秘书,在满足接口的情况下,都应该是被正式考虑的设计。那么,什么样的方式最适合集思广益呢?自然是头脑风暴! 在上面这些步骤完成后,我们已经有了接口定义,有了或许一堆可行的内部结构,再来确定了一个可能的内部结构后,接下来该做什么呢?嗯,对的,就是验证我们手上的东西:拿出我们已有的use case,如果没有的话,那么开始定义use case,之后用它们来检验接口和内部结构。显然,use case设定的基本要求是,覆盖所有的接口定义。 最后我们得到一个被补充完善的接口定义,一个验证后的内部结构,一堆use case。如果我们的项目足够小,已经可以开始实现;如果我们的项目足够大,那么把内部结构划分后,我们可以再次得到划分后模块的接口定义,于是,上面的步骤可以再次进行。 无论是谁都可以清楚的看到,在这种模式下,我们并不需要架构师,真正重要的是一个leader,他能引导这些步骤顺利的进行,他需要保持着谨慎心,防止我们偏离接口,走向过设计的误区,同时足够放任,能允许产品在满足接口的情况下出现足够创新的内部结构,所以他不应该是一个工程师式的架构师,而应该是一个需求分析师,是一个设计师,是一个开放的领导者。 February 12 台式机还有必要存在么?请尝试这样来做: 1. 列出台式机相对于当前笔记本的优势。 2. 考虑笔记本能否通过简单的改变来消除劣势,或者说台式机的优势是否在一定时期内能被保持。 3. 列出笔记本相对于台式机的优势。 4. 考虑台式机能否通过简单的该表来消除劣势,或者说笔记本的优势是否在一定时期内能被保持。 5. 思考题:上网本的出现意味了什么? |
|||
|
|