#legoo内核# -- 准则一 ：小便是美

      从目前社会的发展可知，随着社会的不断进度，分工也越来越精细，这种来自社会发展的规则也一样适用于软件架构设计。SOA其实就是在模拟社会的一种分工精细框架的投影，业务成熟度越高，SOA体现的价值就愈大，反之则价值体现愈小。我写这段开场白的目的其实就是想说明，基于软件架构而言，软件架构的进化过程与社会的工业化进程有着惊人的类似之处，而 #legoo内核# 的定位是模拟 工业化下的流水线做业模型。正如 文章的标题，“小”表明着每一段有效的代码都是独立的流水线上的一个节点，功能单一但绝对高效，而且能够随处复用。
      若是你准备开始编写一个程序，首先要作的就是勾勒一个完整的程序流程图，下一步则是对流程图进行修饰，保证流程图上的每个节点尽量的功能单一而且可复用，让节点成为业务数据的加工场与过滤器。做为一个传统的架构师，心中确定怀着一个编写伟大程序的渴望，可是在真正的投入项目研发时，却要花费数周甚至几个月的时间去从零开始构思一个完整的项目解决技术方案，然这种方案是不可取的，其实在我现实的世界中，只要把一些小巧的解决方案组合起来，几乎能够解决90%以上的问题，好像到如今读者依旧没法体会 基于 小 的思惟模式如何进行流水线设计？下面用一个很传统的程序例子来讲明。
      任何一个懂电脑的人，都知道文件复制吧，也就是用户把一个文件从一个文件夹复制到另一个文件夹抑或在同一文件夹复制，貌似如何简单的一步操做，若是我做为操做系统的复制流程设计，那么我要用以下的一种思路来对拷贝的过程进行分解，从而完成最终的拷贝，整个流程按照序号依次进行：
       一、要求用户选中所要复制的文件
       二、检查源文件是否被锁定，若是锁定则提示用户没法完成复制
       三、检查目标文件是否存在（复制的目的文件夹）
       四、若是存在同样的文件，咨询用户是否要进行覆盖抑或取消复制操做
       五、对文件加锁，而且读入文件信息。
       六、若是文件内容为0字节，则提示用，是否继续 或者退出复制
       七、申请内存，随机读取指定大小的文件块
       八、建立目标文件，而且写入文件内容，知道源文件读取完毕
       九、关闭IO流
       十、提示用户复制成功
       若是做为linux的话，可能还会加入当前用户对文件的 读写权限的过程，window下则能够忽略这一过程，一个文件的复制，只有在第七、8步才是真正的执行复制操做，而其余的流程节点则是在为复制进行合法性过滤以及对复制结束的后台动做进行收尾处理，若是你是一名程序员的话，你可能会发现，其余的几个步骤也能够适用于除了文件复制以外的其余任务，例如文件 剪切 操做。
       上面的每个节点均可以做为一个独立的程序片断去设计，每个片断的存在并不关心本身到底在作神马动做（复制 or 剪切），他只聚焦于本身自己的功能，例如 第3步：检查一个文件是否存在，他仅仅须要一个文件路径参数便可，也不关心他的下一步要干吗，这就是  小 的优雅之处。
      整个流程是基于必定的规则组装而来的，相似于SOA下的bpel流程设计，但这是基于程序片断的一种流程组装，“等一下”也许读者会这样子想， 这些复杂的程序如何能按照必定的规则去运做，入参如何控制。。。诸如此类的问题，这一章节不讨论这些，文章主要是向你们阐述明白  小 的这种思惟模式与方法论。
      本人也认可，就程序片断而言，完成的功能很简单也很单一，可是把这些简单的功能组装在一块儿，你就会体现到他的强大之处，总体功能大于局部功能的简单叠加。任何大型任务均可以按照这种思惟模式 进行 “小”的设计与分解。这让我想起 本山大叔的一个小品，大意是这样子的：动物园开会，大象没来 。。。。请问，把大象关冰箱须要分几步。。。 看到了吧  程序源自生活，打开冰箱 与关上冰箱 是可复用，把任何东西放进去都须要这两个动做，因此要把这两个动做单独剥离出来设计，化整为零大法啊。。。。。
      从专业的角度来看待这个问题，首先小程序总完成既定的u，不存在二义性，这样子在任何地方复用，升级均可以保持他功能的惟一性，而不是一个函数同时要完成几项不一样的业务处理，这种贫血设计是严格不建议使用的，从维护的角度来看待问题：大程序相对复杂一些，也给人们带来了理解的障碍，程序的规模越大，就愈加背离了架构师的初衷，代码的行数也会成为维护人员的噩梦，1000行的代码是什么概念，~~~ 写这种代码的程序员 要好好地反思反思了。固然，任何业务也许总会出现一些让人难以理解的业务与程序，无论她的规模大小，这是由于自己他们的执行的功能就很难懂，可是这样的程序必经是少数，本人很推崇 8/2 法则，一个框架能解决80%的问题，那就足够了，剩下的20% 则彻底能够特殊化处理。对于通常的初级、中级程序员而言，小的程序是容易看懂的，先对于大程序而言，商家的维护成本能够下降。
     小程序从维护和优化角度讲，都是值得推崇的，这一点我很坚信，若是出现 单点的故障，能够很快找到一个代替的方案去替换他，而无需惊动整个业务流程，抑或优化，抑或替换，惟一影响的就是节点本身。
     从内存使用角度看，小的程序对于内存消耗更加具备优点，由于他们短小，因此运行时占用内存很小，执行完则可彻底释放内存。这大大下降了程序持有内存的时间，下降了内存交换与分页的请求，若是对于Java程序而言，内存的回收是影响性能的很大因素，小的程序能够下降JVM对内存回收的计算深度，便于jvm更好地进行内存回收。
     小程序更加容易被复用，小 设计的目的就是为了复用，越大的东西越不容易复用，在现实的世界中，也是这样子的。有小程序组装的业务流程更加能适应多变的业务，由于每一个小程序之间的链接是基于某种契约配置的，而不是基于硬编码 铸就的（可能会牺牲一些性能，依旧用8/2法则来回答 哈哈）。
     经过我这几年的不断积累，愈来愈喜欢把程序往 小 的方面切割，随着项目的不断壮大，感受本身越游刃有余。乐高积木 就是一个伟大的发明，由于我创造的积木形状越多，后期可服用的也越多，感受本身 是 活字印刷术 通常了 ~~ 神奇~~~~
   让每一个程序片断只完成一个功能，尽可能保持入参 与 出参的简洁性。小程序从设计到编写 到维护，都有无比拟的优越习性，对将来业务发展的包容性将更加好，能够应对未来更加复杂的业务，作出较好的应对。

   让每个程序只作好一件事    这就是  小  的内涵，也是我结尾要说的一句话。 
       如今时间  23：47 分，关于 小 既是美的话题 就此打住， 洗漱休息。一我的的家  显的格外的冷清~~~~~~