谈谈这阵子忙的事一：关于design整个过程的感想
前阵子一直忙于做Detail Design, 产品的需求是要开发一个新的Application,在旧有的Application上增加一些新的服务加入一些新的概念.这样就涉及到要改动一些现有的UI,使它们能够适应新的Application,并且保持在旧有的Application里显示的UI不变.
一开始自己很自然的想到用状态变量去控制,不同的Application分别给它们设置不同的状态,这样在UI里就出现了一些if...else...逻辑.美国那边架构师在review时一口否定掉我的idea,然后跟我们说应该这样这样.接下来我得回过头来实施构架师的idea, 深入思考后,发现这样做有些问题, 就把这些issues阐述给架构师听. 然后他就又给出一些ideas来解决这些问题,然后我又能发现一些问题得不到很好的解决,回馈给他,由他来给出新的idea.这样每天来回地send mail交流了差不多2个星期,最终终于敲下了方案.
回过头来想想整个过程,发现导致这个情况出现的原因在于:一个主要是我设计经验还比较缺乏,遇到问题时不能有效地找到方案,而且有时候太专注于那些复杂的逻辑,没有很好地把握住整体的方向,以至于没有很好的idea.另一方面呢,架构师总是有很好的ideas,但由于他们不可能专注于某个特定模块,所以可能对这个模块的细枝末节并不是很清楚,于是难免给出的ideas不能很好地解决这些方面.以致于我们需要反复交流沟通,然后改进.
当然我是很享受整个从发现问题到解决问题到发现新的问题的过程.这个架构师也非常的nice,中间自己思考了很多也学到了很多.设计本身也就是这样一个不断趋于完善的过程,不可能一开始就能找到完美的方案.
现在讲讲最后敲定的方案是怎么做的.
此做法跟WinForm里的设计器服务很相似,先抽象出一些共同的服务,然后在Application层里负责创建自己的具体服务,并注册他们. 这样在UI上就不需要进行状态判断, 不需要知道Application层的任何事情,它们要做到的事情仅是获得服务,然后面向这些抽象的服务接口编程. 这样的好处就是,耦合性非常小,最主要的是所有逻辑处理都是放在Application层, UI只是负责去调用,这样以后如果要增加新的Application时就很容易进行扩充.
后面篇幅有点长，就另起一篇来发牢骚，有兴趣的继续看看^_^,
谈谈这阵子忙的事二: 关于Coding时遇到的一些现象
一开始自己很自然的想到用状态变量去控制,不同的Application分别给它们设置不同的状态,这样在UI里就出现了一些if...else...逻辑.美国那边架构师在review时一口否定掉我的idea,然后跟我们说应该这样这样.接下来我得回过头来实施构架师的idea, 深入思考后,发现这样做有些问题, 就把这些issues阐述给架构师听. 然后他就又给出一些ideas来解决这些问题,然后我又能发现一些问题得不到很好的解决,回馈给他,由他来给出新的idea.这样每天来回地send mail交流了差不多2个星期,最终终于敲下了方案.
回过头来想想整个过程,发现导致这个情况出现的原因在于:一个主要是我设计经验还比较缺乏,遇到问题时不能有效地找到方案,而且有时候太专注于那些复杂的逻辑,没有很好地把握住整体的方向,以至于没有很好的idea.另一方面呢,架构师总是有很好的ideas,但由于他们不可能专注于某个特定模块,所以可能对这个模块的细枝末节并不是很清楚,于是难免给出的ideas不能很好地解决这些方面.以致于我们需要反复交流沟通,然后改进.
当然我是很享受整个从发现问题到解决问题到发现新的问题的过程.这个架构师也非常的nice,中间自己思考了很多也学到了很多.设计本身也就是这样一个不断趋于完善的过程,不可能一开始就能找到完美的方案.
现在讲讲最后敲定的方案是怎么做的.
此做法跟WinForm里的设计器服务很相似,先抽象出一些共同的服务,然后在Application层里负责创建自己的具体服务,并注册他们. 这样在UI上就不需要进行状态判断, 不需要知道Application层的任何事情,它们要做到的事情仅是获得服务,然后面向这些抽象的服务接口编程. 这样的好处就是,耦合性非常小,最主要的是所有逻辑处理都是放在Application层, UI只是负责去调用,这样以后如果要增加新的Application时就很容易进行扩充.
后面篇幅有点长，就另起一篇来发牢骚，有兴趣的继续看看^_^,
谈谈这阵子忙的事二: 关于Coding时遇到的一些现象
