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

为什么80%的码农都做不了架构师？>>>   

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

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

转载于:https://my.oschina.net/qfhxj/blog/189694