每个业务系统都不可避免要涉及到计费需求，如何解决计费问题总是没那么容易。做得少了满足不了用户的基本需求，一些费用登记不了。做得多了变成一个不专业的财务系统，被使用的可能性极小，通常各企业都有自己的财务系统，财务人员不可能再到业务系统里去做一遍数据。
最常见的托运单都是把费用填在单据中的，而不是单独计费的。例如，运费、送货费、提货费、保费等，五花八门。而单据的明细条目则通常在三条以内，有些甚至只有一条。而费用则是由各个明细条目一起计算出来的，只有一条当然好算，如果是多条的话，就稍微有点麻烦了。因为有些情况下是按整单计费的，没法精确知道各个条目所分担的运费。或者先是按各条目计费，然后把合计的费用 ...
运输公司常常要求我们的系统能够提供一些实时查询的功能，方便他们跟踪客户的货物。例如，客户的某一票货现在在哪辆车上，车大概到了什么地方，是否可以准时到达。而我们的设计则不能直接发映出这些功能，运输公司跟客户交接用的是托运单，司机则拿的是配载单，上面列有详细的货物信息。我们的方案基本能满足他们的需求，但做起来就发现问题多多。
首先，托运单和配载单是多对多的关系，如果你直接去建立他们之间的关系，无疑会复杂化实现。采取折衷的方案会更好，我们把配载单的明细记录和托运单的明细记录进行关系，形成多对一的关系，间接解决了前在提到的多对多关系。再把每次配载的数量写到托运单明细记录中，记录已经配载了多少数量，而 ...
我曾经参与过几个运输公司系统的项目开发，基本上大同小异。他们的业务模式主要分为两类，一类是做干线运输，只做点到点运输。他们的自有车辆比较少，覆盖面窄。如果客户的业务要求运到他们无法到达地方，直接转包给别的运输公司--他们的二级承运商。这种模式的优点是成本较低，运送到达准时率、货物完好率比较高，同时有时间保障。这类公司通常认为中途的装卸会导致破损率升高，且耽误时间。缺点是车辆满载率无法保证，对车辆的调配要求比较高。同时外包业务也存在一定的风险。
另一类是做干线中转业务，他们的车辆比较多，线路覆盖比较广，基本上不会把业务转包出去。通常他们的车辆都是装有多个城市的货物，在中途也需要卸货/装货。这种 ...
所谓依赖，指代码中的耦合。依赖倒置，是相对于传统的面向过程的设计结构而言，面向对象的结构把依赖关系倒置了。
DIP原则：
高层模块不应该依赖于低层模块，二者都应该依赖于抽象。高层模块只应该包含重要的业务模型和策略选择，低层模块则是不同业务和策略实现。首先高层模块和低层模块都要抽象出来，高层抽象不依赖于高层和低层模块的具体实现，最多只依赖于低层的抽象。高层的实现独立于低层模块不应该依赖于低层模块，而是依赖于低层抽象。同时，低层的抽象和实现也只依赖于高层的抽象.为什么要依赖于抽象呢？因为抽象/接口都是相对稳定的，不会被频繁改动的，依赖是可以信任的。如果都依赖于具体的实现，想想吧，改动一小块代码是 ...
最近常常会听到有人在讲如何如何研究某某大公司的行政制度，薪酬制度，然后再断章取义，把其中的某一部分照搬过来开始在自己的小企业内部实施。虽然遇到了重重困难，但给别人和自己的理由都是非常冠冕堂皇：某某公司就是这么做的。最后就是画虎不成反像猫，吃力不讨好。
我们也常常会看到大公司的管理层常常在谈如何才能像小公司一样灵活敏捷，好像Welch在他的自传中也提到过这一点。
看到了吗？小公司拼命想学大公司，希望变得更死板僵化。大公司则千方百计地希望能变得更灵活小巧，迅速做出反应。
这很有趣，不是吗？
Salesforce是一家提供SaaS服务的企业，大概有十年历史。他已经与Google开展了深度合作，同时向他们的客户出售Google Docs服务，当然是集成在他们的系统中使用。现在就有可能存在双方之间的交易--Google会收购Salesforce。
一方面，Google希望把他们的应用出售给一些企业客户，另一方面，salesforce也已经使用了大约41000个Google的应用。如果交易成功，对双方都是有利的。
关于领导的概念理解有许多不同的解释，这里我要谈的是技术领导。
技术领导的概念不同于管理，通常我们所说的领导就是指管理一组人来完成一项任务，而实际上技术领导是营造一种使他人可以更富有成效，更有效率工作的环境(出自Weinberg)。并不是只有管理者才可以领导，事实上每个人都有领导的才能并发挥着领导的作用。
首先，帮助他人就是帮助自己。对于一个团队中个体来讲，你只有更好的帮助别人完成工作，才会使自己的工作的价值最大化。如果整个团队失败了，个体的任务程度的成功都会变得没有意义。这样的例子我们常常会看到，拥有明星级的开发人员，却开发不出明星级的产品。不只是项目经理要认识到这一点，团队中的每个人都要 ...
开闭原则(OCP)是OOD常用的基本原则之一.这个原则首先由Mayer在其著作<Object Oriented Software Construction>中提出.
软件实体,包括但不限于Classes, modules, functions,应该对扩展是开放的,对修改是封闭的.换句话说,在极端的情况下,你不需要修改现有的代码,新功能通过子类,重载或通过代理来委托现有代码来完成.这样会防止你向现存的代码中引入bug,因为现存的代码不会被改动就不会产生新的问题.
首先要澄清的一点是:没有100%封闭的代码.封闭一种设计上的策略,并不是指具体的代码.代码体现并趋向于你的设计策略,这不代表 ...
samuelray
- 浏览: 48958 次
- 性别:
- 来自: 深圳
- 详细资料
搜索本博客
最新评论
-
规划职业生涯
beyondqinghua 写道哪个人不想好好的静下心踏踏实实的学习,但是经常生 ...
-- by samuelray -
规划职业生涯
踏实、兴趣、激情、健康；宽容、沟通！与君共勉！
-- by shaquan6776 -
规划职业生涯
不错,支持一下!
-- by intfloat -
规划职业生涯
共勉～
-- by justin8335 -
规划职业生涯
哪个人不想好好的静下心踏踏实实的学习,但是经常生活的压力总是让你更加浮躁啊!
-- by beyondqinghua
评论排行榜