Tag Archive for 设计

工作流系统的设计

工作流系统的设计

几年前曾经写过一点点对于缓存框架设计的体会,这大半年和工作流系统打交道颇为丰富,因此想总结一点关于工作流系统的设计。

首先,明确工作流(workflow)系统的定义。维基百科上有极其简单的介绍。我记得以前在文章里面说过,作为大公司里面的小team,为了做一些有趣的东西,从而更好的招人,通常有几个众人皆知的突破口:比如一个更符合业务需求的storage,再比如一个自定义的工作流系统。在Amaz

[......]阅读全文

分享到:

追求纯粹

追求纯粹

偶然想到的这个话题,工程师做工程是一方面,而作为单纯的程序员,总是充满对于纯粹的追求。

最近又负责了一个使用Angular的项目,我们知道最近Angular很火,其中一个重要原因就是它给前端开发带来的变革,第一次发现可以让以前如此恼人的变量绑定消失掉。以往变量绑定的语句放在附属于页面的一个js片段(文件)里面,颇有些无奈的意思,如果把它视为展现层面的东西,显得很不直观(声明式编程才是最直观的方式

[......]阅读全文

分享到:

重新发明轮子

重新发明轮子

“不要重新发明轮子”是总是可以听到的话,在评判一个设计的时候,总是听到这样的话。但是凡是不绝对,而对于这句话来说,很多情况下,都是错误的。我甚至都不能说出“大多数情况下不要重新发明轮子”这样的话,因为具体问题,实在没法用大多数还是少部分来概括。重用轮子有什么好处?省代码;轮子已经经过千锤百炼,质量有保障;轮子功能在逐步更新中,可以看到未来的获益。

[......]阅读全文

分享到:

程序的库设计

程序的库设计 最近在Stack Exchange上面看到一个帖子,是问程序库设计的指导原则的,“What guidelines should I follow while designing a library?”,有趣的是,很多人都在谈论面向设计,各路API设计,还有程序语言设计,唯独搜索“程序库设计”,无论中文还是英文,Google还是百度都找不到太多内容。但是我想,没有程序员会否认库设计的重要性吧,我想

[......]阅读全文

分享到:

对几个软件开发传统观点的质疑和反驳

对几个软件开发传统观点的质疑和反驳 下面这些观点都是程序员在教科书上、在编码规范里、在正统的软件工程流程里流传开来的,帮助了许多人在程序员启蒙期间养成了良好的习惯、原则。对许多人(包括曾经的我)来说,似乎是理所当然的。但是随着阅历的增长,视角在变化、看法也在变化,曾经的好恶现在都可能大翻身了。

为代码写足够的注释,让代码易于理解

“所有程序员都会写自己看得懂的代码,但只有优秀的程序员才写大家看得懂的代码。&rdqu

[......]阅读全文

分享到:

对象转换的问题

对象转换的问题 有句话叫做“计算机科学领域任何问题,都可以间接的通过添加一个中间层来解决”,但是唯一解决不了的问题,是层次本身过多的问题。每一层内都会维护自己在乎的数据对象模型。层与层之间数据的传递,就不可避免地遇到对象类型转换的问题。

这个话题也和最近的项目有关。我们在重构一个老旧的系统,所做的第一件事情,就是要把数据访问层从原有系统中剥离出来,我们精心设计了这一层的模型和结构,但是要让原有系统平缓地从原有数

[......]阅读全文

分享到:

DAO的演进

DAO的演进 这个思考源于最近项目中对DAO的使用和讨论。数据访问对象,在贫血模型下,要怎样去设计,框架需要完成什么,后续的开发人员需要关注什么,设计的时候到底需要把握怎样的粒度?

最早做项目的时候,是老老实实给每个必要的模型增加DAO接口和实现类的:

public interface IUserDAO{
    public long add(User user);
    public void

[......]阅读全文

分享到:

设计之美

到处都在谈论UI的美感,仿佛“美”在软件工程中的定义就要落到界面上面。实际美的存在是广义的,包括架构设计,包括代码建设,包括接口定义,不妨在更多的场合引入对美的评审。软件本身就是一种艺术品,而程序员,应当是被赋予创造力的艺术工作者。

设计之美 设计之美

仅看这两张图,你觉得哪一张会更美一些?

我相信大多数人会选择第一张,因为后面那张图显得头重脚轻,事实上,后者也确实是一个短命的版本,只存活了不到半年的时

[......]阅读全文

分享到:

过度工程

过度工程 过度工程,最初我知道这个词是在Rod Johnson的《J2EE Development without EJB》,随着阅历地增长,渐渐发现书中熟悉的场景也在身边再现了。

 

敏捷、还有设计模式,给一个团队带来了什么?

我之所以把这两个词放在一起讲,是因为我要说一件显而易见的事情,可是这样一件事情很多人又不愿承认。

团队,是有风格个性的;团队,也是有能力强弱的。不管你承认不承认

[......]阅读全文

分享到:

你会怎样设计铁道部购票网站?

你会怎样设计铁道部购票网站? 最近铁道部购票已经成为了热点话题,毛病多得一塌糊涂,如果让你来设计铁道部购票网站,你会怎么做?

 

这样的网站属于实时性要求较高、并发性要求非常高、容量要求一般的类型,以下是我简单的想法:

 

1、部署是基于CDN的,对于车票查询的环节来说,这是没有问题的。

 

2、数据库表设计上面,应当有一张车次表,每行代表一趟车,至少有这样的字段:还剩多少张,已被锁定多少张。

[......]阅读全文

分享到:

贫血模型和充血模型

这两个概念是早些时候Martin Fowler总结出来的两种常见模型设计类型,没有说谁好谁不好,为不同的模型类别选择合适的场景是设计者的工作。没有工具本身的问题,只有工具使用者的问题。

 

 

贫血模型是指领域对象里只有get和set方法(POJO),所有的业务逻辑都不包含在内而是放在Business Logic层。

 贫血模型和充血模型

 

优点是系统的层次结构清楚,各层

[......]阅读全文

分享到:

由后端来类比前端设计的思考

由后端来类比前端设计的思考 有这样一句话被提起:

前端也有MVC,DOM树就是这个M,CSS就是这个V,至于C,非JavaScript莫属。

很高兴团队中有越来越多的人能够跳出某种语言、某种平台的局限性,站到抽象的层次上思考一些设计上的问题。在我的印象中,似乎前端开发总是容易给人以随意、混乱的感觉,可真的是前端技能不容易掌握吗?

大学里Java课程正儿八经学了3年,JavaScript只字未提,只是课

[......]阅读全文

分享到:

不,这样的DTO!

不,这样的DTO! 本文翻译自 Oh No! DTO! by Robert C. Martin,这篇文章很短,强调的内容简单得不能再简单,也许大家早就意识到,但是,我依然可以在很多产品的代码里面找到文中所说的“教条”的影子,我说不清为什么,在这里有激烈的讨论,你们说呢?

 

本周我在教授XP(极限编程,译注)的课程,我们要写给当前的应用写FitNesse(一种测试工具,译注)的基础测试代码。其中一位程序员

[......]阅读全文

分享到:

API风云录

API风云录 好吧,我承认我是标题党,还是让我们从一个故事开始吧。

项目的业务逻辑层需要被设计成一个具备易扩展的模式,对外提供了大小相异的API。项目组人人头脑风暴,最后在各位的努力下,克服苦难,业务逻辑层被封装起来,一组最初的API被提供出来:

1、现有Service逻辑已经疏于管理,欠缺重构,变成了不易控制的逻辑层,接口众多,鱼龙混杂,难以规整出清晰、可用的接口给第三方(例如下游定制团队),怎么办?&

[......]阅读全文

分享到:

Flash Scope

项目中遇到了一个潜在的问题,大致就是说,在一个流程的两个或某几个环节中,需要短暂地存储一部分对象(如果不存储,就需要在这几个环节中多次调用同一个外部接口,这被认为是不够合理的实现)。

而这部分对象的存储:

(1)如果用request,太小,毕竟一次提交以后就丢失了,如果需要往后传递,可能需要借助一些页面参数传值等丑陋或是不易控制的方法;

(2)如果用session,太大,我不需要在整个用户会话生命

[......]阅读全文

分享到: