项目所得:一个非典型性改动带来的思考(三) 之项目设计

-----------------------------------------
    上篇 中描述了针对第一个问题的思考, 在写的过程中几个关键词逐渐引起了我的注意, 本篇就让它们登台吧, 它们是: 现在项目的套路及缺点, 数据库实现业务逻辑, 程序设计的美.

    先看第一个, 即现在项目的套路及缺点.
    虽说现在所项目还是不很多, 但对项目所用架构和技术还是有一定了解的. 现在是B/S流行的时代,我们这里也只讨论Java实现B/S可选择的技术. 项目大都有三层, 也可以说五层. 三层是纯Java的三层, 五层是包括了数据库和HTML_CSS_JavaScript后的说法. 这里不防采用五层的说法. 这样的分层大都有很多的框架可选(数据库和HTML除外), 而项目中大多也都是基于这样的分层围绕着数据的CRUD实现些基本功能.
    这样做的好处显而易见, 可以把别人写的框架拿来就用, 从而极大地提高开发效率. 一个Java程序员把这些层上常用的技术掌握住,一般的工作也就可以胜任了.
    但这样的项目做着做着就会慢慢发现, 似乎还缺点什么东西, 也不够过瘾. 一些很吸引人的概念和技术自己很少用到: OOP,AOP, 接口设计,WebService.....
    在这样用框架的思维主导下, 项目有些惨不忍睹了:  方法实现上以copy/paste为主, 方法调用的"私拉乱接", 方法很是变异的传参方式... 这样的项目一下子脆弱了,谁也不敢碰了, 好像一碰就瘫掉一样.而业务上的一点改动,在代码上的变更费老劲了.
    这显然不是我们要的结果.

    接着看第二个, 数据库实现业务逻辑.
    现在这个问题,我又想了这个话题.以前也多多少少地想过. 为什么这样的方法不行? 也没有系统地想过. 现在把一些零星的想法写在这里跟大家讨论,其实这是个很古拉很过时的话题了吧.
    以下是现在能想到的一些因素, 但也不是很明确, 也不知具体每一个占多大比例:
        1, 没法用OO的概念. 好像并不是很有说服力, 最典型的反倒是C, 它也没有什么OO的意思吧, 但可以想像,C做的项目也是很辉煌的.
        2, 与具体的数据库绑死了. 一般来说,一个项目很少在换数据库吧? 不过这个因素像jBPM这样的中间件得考虑的.
        3, 人们喜欢了用具体的编程语言来实现业务逻辑. 这是一种可能, 毕竟并不是所有的程序都是有很丰富的数据的, 这样由于习惯就直接导致了在一些用数据库的项目中也不用数据库来实现业务逻辑? 有些荒谬!
        4, 由于数据库的局限性,一些专门的编程语言更能胜任业务逻辑的实现. 但这个局限性又具体表现在哪? 具体编程语言的优越又体现在哪?

    最后看第三个, 程序设计的美.
    应该说这个我现在写的最心虚, 自己也没参与过设计优良的项目开发,这里只能从反面来管窥下美的体现.
        1, 程序应该运行正确. 这是最起码的要求, 或者说不算要求的要求.
        2, 程序应该便于维护. 这个涉及的面太广, 再往下分应该有: 处理代码重用,  减少功能调用的私拉乱接, 代码本身的可读性应该高些, 低耦合以便于业务逻辑的扩展, 组件化地可插拔....
        3, 程序运行效率应该高些. 这是性能上的要求了, 现在体会的还不深.
    但要想达到设计优良是有代价的, 是要投入巨大的人力物力财力的, 这样一般的项目也招架不住, 于是我们要感谢那些开源框架的伟大了.

    写到这里, 想到大名鼎鼎的<人月神话>了.

    这篇写的有些远了, 不过还是在引发思考范围内的, 下篇将回到主题.

程序设计的美确实是很虚的概念。
开发人员认为的美在客户看来可能是无用的；客户认为的美在开发人员看来可能是幼稚的。

所以美只是一个共产主义式的理想罢了。

我也有类似的想法

开发人员的美怎么是没用的呢？只有优美的代码才便于阅读，适合维护，容易复用。没人愿意去维护一个结构混乱、代码难以理解的系统。自己做不到不要怨理论错误。
客户受其技术能力制约，当然不知道你的这些优美的好处。这就要你用它能听的懂的语言说出来。客户如果能听懂你的技术那他就自己干了，你还赚什么啊。比如代码简洁，结构合理。你可以告诉他这样可以加快BUG的修复速度，减少因BUG引发的损失。代码复用，告诉他这样可以一次编写反复使用，不用加钱重新写。你和他说别的他不知道，说钱肯定知道。

也不一定，同样是装配工，装出来的东西有没有毛刺就看你给多少钱了。

代码方面实际上就是一潜规则，给钱少还要代码好，给人弄急了就不干了，所以大多数人在这方面均衡一下就算了。