自然而然的设计
设计，似乎有点高深莫测！ 一堆的模式、模型，让人无所适从。学了记不住，记住又用不上。我觉得设计应当是自然而然的事，从实际问题出发找出实际的解决方案就可以了。其实难点在于能不能看到问题。
回想起12年前的2000年，当时刚进入一家ERP公司，被安排为一家灯饰公司"客制"(所谓客制就是定制的意思!)人事系统。当时系统总被客户抱怨薪资结算太慢，四千人的工资要跑一晚上。下班时开始结算，第二天看结果。刚上系统，难免出现数据遗漏，那又要重算一遍。好在那个时代对软件有些迷信，这边说没办法，系统架构所致，客户也只是抱怨抱怨，用还是将就用。
我被安排接管这个项目的后续维护后，也发现了这个问题。当时也是初生牛犊，公司当时的研发流程也没现在这么规范。于是开始直接动手思考这个问题的解决方案，没经过评审，一周左右直接在系统维护时上线了。结算时间缩到1小时以内。客人还专门发了传真向公司表扬了一番，当然是根本上是为了督促公司提供更好地服务，毕竟之前被忽悠了(这事放在现在来看，显然很多地方不合规矩，不过那时候还是个人英雄主义的年代!)
其实解决方法很简单，用现在的话来说就是将业务逻辑放在数据层，而之前放在了表示层。这话多别扭！直白一点，之前的关于薪资运算的逻辑是放在Client端, Server端就是一台MSSQL Server。这样四千人的工资就是要一笔笔的计算四千次。取出基本薪资，取出考勤数据，取出请假数据，取出加班数据...... 计算应得薪资，扣社保，扣税，计算应得薪资。然后存回数据库，再计算下一笔。令人欣慰的是UI界面上看起很爽，一个进度条，向你一个个展当前它正在计算谁的薪资。
改进的方法就是将这部分的计算逻辑写成一个存储过程，然后用一串update语句就可以完成批次计算。计算时，调用存储过程就可以了。当然存储过程的撰写还是要动些脑筋，这就是锻炼抽象和归纳能力的时候了。对于工厂的人事系统，考勤规则和数据处理是比较复杂的，因为三班倒的情况下，有人会延班(连续上两个班,中间不用刷卡)，有人会加班(和延班不同的是会在加班时刷卡，也有不刷卡，要自动计算加班时间的)，有人会早退，有人会迟到，有人会旷工，有人会请假，法定假日上班还要另计等等诸如此类，这时就要加以区分为若干细项规则，然后一类一类的处理(一类就是一条update语)。其中考勤再多变化，总是有规则的(不然工厂就没有制度可言了)，一类类处理掉，最后公式化的加减当然就简单了。就这样一个思路，咱不用展开说，说了也没有意义。
这样做最大的好处是利用了服务器的处理能力，最大的坏处是代码不是那么好维护。(虽然增加了服务器的负荷，但对于企业内的应用而言，还不算什么大问题。当然，企业再大一些的时候就不一定了，那不还有分布式的方案吗。)
再后来2002年在厦门一家工厂做系统分析员，负责协助厂商将ERP导入上线，由原来乙方变成了甲方。当时选定的ERP厂商的成本结算就是用存储过程写的，洋洋洒洒数千行(系统号称是三层架构，使用DCOM/COM+实现)。关注它，是因为它在模拟上线时总算不准。成本上总是和财务对不起来(再先进的架构，功能达不到要求，还有什么价值！)。这又是一个问题。
我是甲方，本来只要指出问题所在就可以了。无奈厂商不给力，耗费大量的时间，就是没有结果，还在会上扯皮。我当时组织了几个人设计了一组数据，模拟现实中一个月的数据，由本部门的几个人录到系统，然后依据这个小样本分析了成本的计算过程，很快就找到了问题所在。问题找到了，大家皆大欢喜。厂商迅速给了新的并且加密了的数据库更新脚本，交给他们的顾问时，反复强调一定要由他们自己升级。最终这个厂商还是被放弃了，这是后话。总之，存储过程的实现方式(业务逻辑放在数据层)显然增加了系统维护的难度。
另外这个过程也有一个设计过程，也是给出解决方案，只不过看起来更像是在定位问题。
以上这些解决方法，现在看来都那么简单的不值一提。现在已经有八年多没有再接触企业应用相关的开发工作了，也不知道现在发展何种程度了，又在面对什么样的问题。但我一直坚信设计一定来源于问题。
当我们发现问题，开始思考如何改善或解决它时，这就是设计的起点。至于运用了什么模式或模型，那些都是自然而然的结果。有句关于设计模式的话说得很好，设计模式是经验总结，而不是理论教条！了解它们会加速设计的演化过程，但起决定性的因素还是你自己如何理解现实问题的。想想经验从何而来?
正如Martin Fowler所说的，他对别人在会上或发邮件来咨询对架构设计方案的意见无法置评，原因是他认为几分钟之内是无法理解具体的问题的。因为设计是基于具体问题而产生的，它是一个自然的过程。
想提高设计能力，还是先发现一个问题，再尝试着用自己的方法来解决掉它吧！
附注: 我在软件行业惨淡地混了十多年，说到分享，一般会提到让我分享些设计上的经验。好像软件开发经验中最值得分享的就是设计经验! 其实就我个人而言，我更愿意分享如何偷懒的方法和看似无味软件构建实践。设计嘛，具体问题具体对待，没有好坏，只有合适与否。你说呢? 我一说设计，就会想到一幅图： 
明明就是个卤蛋，却不甘于现状，偏要增加些喜感。加上个笑脸，取名快乐的卤蛋！这不就是设计吗! ) 转载请注明出处:http://blog.csdn..net/horkychen
我的异常网推荐解决方案：软件开发者薪资,http://www.myexception.cn/other/1391128.html
