深圳台风，堵车中偶遇同事，聊起当前系统开发的问题，昨天我看到一个存储过程大概有6000多行，毕竟我是入职没多久，不敢妄加评论如何如何，同事接过话题，说那些存储过程经历了几代程序员的修改，才有如此规模的篇幅，更有甚者超过10000行的存储过程代码。
这个问题听后，有点压抑，首先想到的是自己以后是否也是会如此的篇幅的代码中继续累加更多的代码，这个是需要考虑下的。在此引发一个更加深层次的问题：为何现在大型企业的软件系统都这样子的，一上线就是一个滞后的系统，而且总是让一批批新的程序员为此买单，花费大量的精力在熟悉这写代码，然后在诚惶诚恐的修改者，深怕改错一个地方造成整个过程的坍塌（全局变量、局部变量、游标）等等，我想到这些就有点恐怖了。大公司都在积累自己的开发平台，想一劳永逸。把各种业务打包成组建，可以反复的复用。理想与现实是存在差距的，而且这个差距是让我们这些码工可以吐血300cc的血量。软件行业是有一个潜规则的：永远变化就是软件行业不变的规则，而且所谓的业务也都是有时代的局限性，为何能简单的把这些可以变的业务打包呢，估计这些我所谓的疑问大牛们都考虑到了，他们也无发解决，于是与提出一个比较牛逼的理论：面向领域的设计模式，什么是领域呢？如何面对领域呢？把实体业务抽象到什么程度就是领域呢？既然领域是对业务的高度抽象，业务是可以变得，领域就不会变化？那些大牛们肯定会说：面向领域是确保业务变动在一定范围之内的的情况下保证领域模型的实用性，如果你的业务有一天向东变成向西，对不起，领域建模估计扛不住这种变化。
大家也许看不顿我表达什么意思，其实这么多年来，程序是业务的逻辑实现，是计算机程式的完美展现，既然是采用程序实现的，那样我们就应该追寻程序设计的本原，那什么是程序的本原呢？流程，没错无论你的业务是如恶化的复杂多变，到了代码实现的层面都可以用标准的程序流程图进行流程建模，详细的展示业务流程的计算机建模。这个建模是对流程的建模，不仅仅是对业务的建模，这个模型是面向变化的，是可以自我学习以及自完善的，应为他建立在一个open的体系架构之上，业务其实也是流程的一种。任何复杂的业务，如果要采用计算机去实现，肯定可以被标准的程序流程图加以描述。业务仅仅是被流程所控制的一个一个代码块，这写代码块可以被设计的很独立，也无需指导自己的上一块是什么或者下一块是什么业务，他所关心的就是自己的本身的业务实现，该业务代码块如果脱离上下文，它只能是一个孤立的存在，没有任何意义可言，但是当这些贾里德代码块被流程建模装载协同工作的时候，一个人性化的业务出现了。
流水线作业一样，他们提供一个基础，至于每个流程干嘛，流水线并不关心，是焊接呢 还是拧螺丝呢 或者是粘贴标签呢 都是按照实际的需要去灵活组装。其中伟大而勤劳的中国人早就对这种思想加以应用了，那就是活字印刷术，他们把汉字独立开，在按照实际的文章进行排版，每个字单独出来则仅仅是字，没有文章的灵魂，但是一档把很多字按照文章的的规则进行拼装在一起的话，一片优美文章出现了。
我现在所追求的就是活字印刷术的工厂，是制造活体印刷术模具的模具，在软件行业，只有流程是不变的饿，至少到目前为止，他们一直都没变过，而且出现在任何一个成熟的计算机语言中，例如这些关键字：Switch、break、ifelse、for、continue、lock（互斥锁）等，把代码级的流程在升华一下，作为业务的基础流程，一切尽在不言中~~~~~~~~~
532
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
