2008年04月_iteye_6952

解析运输系统之三

每个业务系统都不可避免要涉及到计费需求，如何解决计费问题总是没那么容易。做得少了满足不了用户的基本需求，一些费用登记不了。做得多了变成一个不专业的财务系统，被使用的可能性极小，通常各企业都有自己的财务系统，财务人员不可能再到业务系统里去做一遍数据。最常见的托运单都是把费用填在单据中的，而不是单独计费的。例如，运费、送货费、提货费、保费等，五花八门。而单据的明细条目则通常在三条以内，有些甚至...

2008-04-30 10:40:56 114

解析运输系统之二

运输公司常常要求我们的系统能够提供一些实时查询的功能，方便他们跟踪客户的货物。例如，客户的某一票货现在在哪辆车上，车大概到了什么地方，是否可以准时到达。而我们的设计则不能直接发映出这些功能，运输公司跟客户交接用的是托运单，司机则拿的是配载单，上面列有详细的货物信息。我们的方案基本能满足他们的需求，但做起来就发现问题多多。首先，托运单和配载单是多对多的关系，如果你直接去建立他们之间的关系，无...

2008-04-25 14:24:43 135

我曾经参与过几个运输公司系统的项目开发，基本上大同小异。他们的业务模式主要分为两类，一类是做干线运输，只做点到点运输。他们的自有车辆比较少，覆盖面窄。如果客户的业务要求运到他们无法到达地方，直接转包给别的运输公司--他们的二级承运商。这种模式的优点是成本较低，运送到达准时率、货物完好率比较高，同时有时间保障。这类公司通常认为中途的装卸会导致破损率升高，且耽误时间。缺点是车辆满载率无法保证，对车辆的...

2008-04-21 10:25:02 158

依赖倒置(DIP)

所谓依赖，指代码中的耦合。依赖倒置，是相对于传统的面向过程的设计结构而言，面向对象的结构把依赖关系倒置了。 DIP原则： [b][size=large]高层模块不应该依赖于低层模块，二者都应该依赖于抽象[/size][/b]。高层模块只应该包含重要的业务模型和策略选择，低层模块则是不同业务和策略实现。首先高层模块和低层模块都要抽象出来，高层抽象不依赖于高层和低层模块的具体实现，最多只依赖于...

2008-04-15 14:53:53 147

大公司与小公司

最近常常会听到有人在讲如何如何研究某某大公司的行政制度，薪酬制度，然后再断章取义，把其中的某一部分照搬过来开始在自己的小企业内部实施。虽然遇到了重重困难，但给别人和自己的理由都是非常冠冕堂皇：某某公司就是这么做的。最后就是画虎不成反像猫，吃力不讨好。我们也常常会看到大公司的管理层常常在谈如何才能像小公司一样灵活敏捷，好像Welch在他的自传中也提到过这一点。看到了吗？小公司拼命想学...

2008-04-11 14:17:30 97

Salesforce与Google App深度合作

Salesforce是一家提供SaaS服务的企业，大概有十年历史。他已经与Google开展了深度合作，同时向他们的客户出售Google Docs服务，当然是集成在他们的系统中使用。现在就有可能存在双方之间的交易--Google会收购Salesforce。一方面，Google希望把他们的应用出售给一些企业客户，另一方面，salesforce也已经使用了大约41000个Google的应用。如果...

2008-04-08 13:40:43 136

浅析技术领导

关于领导的概念理解有许多不同的解释，这里我要谈的是技术领导。技术领导的概念不同于管理，通常我们所说的领导就是指管理一组人来完成一项任务，而实际上技术领导是[color=darkblue][b]营造一种使他人可以更富有成效，更有效率工作的环境[/b][/color](出自Weinberg)。并不是只有管理者才可以领导，事实上每个人都有领导的才能并发挥着领导的作用。首先，[b]帮助他人...

2008-04-08 10:10:20 281

开闭原则(OCP)

开闭原则(OCP)是OOD常用的基本原则之一.这个原则首先由Mayer在其著作中提出. 软件实体,包括但不限于Classes, modules, functions,应该对扩展是开放的,对修改是封闭的.换句话说,在极端的情况下,你不需要修改现有的代码,新功能通过子类,重载或通过代理来委托现有代码来完成.这样会防止你向现存的代码中引入bug,因为现存的代码不会被改动就不会产生新的问题. ...

2008-04-01 15:52:26 175

Less is more