#legoo内核# -- 准则二 ：让每一个程序只做好一件事

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

        最近回去老家购置一套衣柜，不得不去家具市场逛了一圈，发现现在的木工真的是舒服很多，各种辅助的工具，高效精准的完成一堆木板的组装，一个完美的衣橱很快出炉，那些木工师傅的工具很多，但每个工具都有其固定的工作，例如 喷钉枪，代替手工锤子，它只能用来钉入钉子，但是效率极其高。社会的发展。导致分工精细，分工精细导致工具功能的单一而高效，这就是社会的一种进步轨迹，这种轨迹映射到软件设计方面也是一样的，这种一种方法论的东东，没有什么具体的模式可参考，作为一名合格优秀的软件架构师，所要做的就是把一个看似完成复杂的功能进行有效有度的分解，让分解后的每一段程序只做单一的功能或者任务，对Java开发而言，一个Java类只完成一个单一的功能。如果是这样子的设计的话，每一段程序被Load 到内存，让后快速执行，执行完毕后退出内存，VM执行垃圾回收，load 下一个程序进行执行，这个听起来很不错吧，但是坚持用这样的一种模式来设计架构却是很难，因为，每一段程序是相互独立的，他们之间不存在依赖关系，任何一个段程序都独立的功能，亦可以独立运行。这就是他的一个设计标准，这种设计标准带来的一个问题，一直困扰着我，那就是由于片段的独立性与功能唯一性，这样会造成大量的程序碎片，对于Java程序而言，会产生大量的精悍短小的Java 文件，而且这种模式，对于debug调试 也是一个困难，按照常规设计，一个业务功能往往被封装到一个方法中，或者在方法中嵌套其他class 的方法，如果可以的话，可以单独调试到程序执行完毕，但是 利弊都是同时出现的，至少我现在认为 这种设计模式下的带来的好处 远远 大于他的不足，至少尚在可承受的范围内。

      软件架构师经常会不由自主的成为 功能控 ，这也是我几年前设计软件的一贯做法，举一个比较通俗的场景吧：一开始，我也许只想编写一个简单的函数去完成某一个功能，可是随后我的创新以及复用的天性会让我变的违背初衷，促使我在原有的函数中增加一个新的功能分支（兼容原先功能），这样原先一个简单的功能开始变得不再单一，一次两次 慢慢的程序就变成了 山西特有的 大杂烩，一锅炖了。这样就会提出一个新的问题，大家如何避免类似的问题发生呢？我并不是反对这种做法，但是在变成大杂烩之前，可以通过如下几个维度来权衡：
     1、这个程序是出于什么层次，界面层、服务层还是别的什么，用户的操作是否可以直接影响到这些功能的入参？
     2、这个程序复用的频率是否很高，而加入新的功能却使用率很低，如果这样则不建议耦合代码。
     3、有没有其他程序可以执行你想要的类似功能，或者是通过几个功能的叠加可以完成你想要的功能，如果可以，则尽量不要利用代码的模式进行耦合。
    就我目前而言，我针对XML操作，写了很多独立的片段，这些单一的功能片段，如下，其中每一个都是独立的Java类，大概列举如下常见的一些：
  1、CovertStr2XmlFilter。java ：把给定的一个字符串转换为一个XML Document对象，如果失败 则抛出异常
  2、 CovertXml2StrFilter。java：与第一个相反的功能，不过增加一个选项，是否对转换的字符进行格式化
  3、CoverMap2XmlFilter。java ：把一个hashMap转换为Xml文档 ，前提是Map为单层
  4、 CoverXml2MapFilter。java：把一个单层的XMl转换为Map<String,String>
  5、 CoverLoopXml2ListFilter。java  ：把一个有固定循环规律的XML转为话List<Map<String,String>> 需要配置指明Xml的循环标识字段
  .............
   注入这样的设计，也许很多人用一个类的N个方法就可以实现，之所以这样设计的原因就是，让这些类作为 程序流程的一个节点加以复用，让每个程序成为过滤器，如果作为方法，则会产生较大的耦合，慢慢的你想项目就会变成了 大杂烩中的大杂烩，增加了class 之间的依赖关系，同时也增加了代码调用的深度，JVm运行会增加很多额外的内存开销。

     这种设计理念，可以推而广之，通过对程序功能的切割与设计，更加容易交付于初级程序员开发，因为每个初级程序员开发的功能很单一，他甚至不需要知道整个业务流程的情况下完成开发，因为功能单一嘛，哈哈~~~~ 这是一种比较理想的境界，但是如果实在大规模的外包模式下，多人协作时，这种模式就会显的比较适用，因为业务的装配是基于某个既定的契约，而这种契约可以对开发人员透明，有点SOA的思想模式吧。
   
       这样做程序架构设计，可以让每个开发人员集中精力完成一个独立单一的任务，首先他不会产生额外的大杂烩思想。如果你的架构设计无法让程序员只做好一件事，那么你很有可能并不理解自己正在试图解决的问题或者架构，看看现实社会中的那些精良的工具吧，这样的设计是符合事物发展的普遍规律。
    
      特别是spring框架的出现，让这种模式显的更加的灵活，很多项目都在不断的上演代码走读，代码检查的这种模式，靠机器或者人为干预去降低代码风险，在我看来这些都是 治标不治本，这种问题的根源出现在整个架构上，架构从根源决定了你的代码的不稳定性与不确定性，所以 如果你的公司还在通过review代码的模式来降低软件代码风险，这时需要考虑是否要从软件机构层来屏蔽这种风险。
   
     让每一个java类只做一件事，这是作为java开发的转义，每个java类不存在依赖关系，他们是并行的，任何一个类脱离另外一个都可以独立运行，他们独立可以完成一个独立的功能。

     周六的早晨 ， 一个人可以安静的去梳理我自己的一些技术沉淀。首先是为了自己的技术梳理。写作的同时 也可以让我进一步体会这种设计思想的利弊。

     11点了，出去买菜~~~~~ DIY午饭  山西蔬菜大乱炖~~~~~~ 
   // end

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