随笔档案

The Architect (dedicated non-programming technical decision maker and problem solver for business):

架构师（专用非编程技术决策者，业务问题解决者）

1. Has outdated programming knowledge and experience, loss of touch with modern development approaches and practices.                                                                                                                                                                                             过时的编程知识和经验，对现代的软件开发方式和实践缺乏关注。   


2. Don’t program and don’t know much about evolving system internals, but makes key technical decisions. Often has completely irrelevant and unreal picture what is happening with the system.                                                                       不进行软件开发，对系统内部知之甚少，但却要做出关键的技术决策。对系统经常有完全无关和虚幻的映像（不太会翻译这句）。


3. Tends to complex, premature and generic solutions when the system is still in infancy and nothing is clear. Applies latest modern buzzword technologies as SOA, MDA, SaaS, Software Factories, etc. which look so beautiful in technical magazines, conferences and CV, but cause unnecessary headache for developers.                                      当系统仍处于起始阶段，都还不明晰的时候，常会做出复杂的，不成熟仅仅通用的决策。使用在技术杂志、技术大会和CV上看起来如此美妙的现代最新的口号，诸如SOA，MDA，SaaS，Software Factories等等，只是给开发人员带来不必要的头痛。


4. Plays role of the middleman introducing complexity in coordination and project responsibilities. Represents software team in interactions with business customers reducing communication value for the rest of the team and impacting idea flow.                                                                                                                                                                          以中间人的角色，引入复杂的协调和项目的责任。代表开发组与客户进行交流，屏蔽了其他成员的发言权和开发思想上的交流。（翻译时候意思懂了，但就是表达不出来）


5. Reduces quality of decisions, which become limited to one perspective; decision making starts lacking diversity, independence and decentralization, which are essential attributes of collective intelligence.                                          决定仅仅局限在某个角度 ，降低了决策的质量；最初的决定缺乏多样性，独立性和向下兼容，这些都是集体决策的本质。                      


6. Creates tension with developers who experience mismatch between grand design and reality. Often continues pushing design decisions until the system becomes overly complex, difficult to change and becomes completely unusable.                                                                                                                                                                                             在缺乏大型设计和实现经验的开发者之间制造紧张氛围。不断的做出决定，系统变得过度复杂，难于改变，和应用。


7. Secures job and justifies high salary - becomes authoritative center for solving business problems without much input from the team.                                                                                                                                                                            有稳定的工作和高薪，成为解决业务问题的权威，但却从未融入到团队当中。


8. Causes loss of sense of ownership, motivation and accountability in developers by detaching them from the key architecture decisions.                                                                                                                                                                     把开发人员排除在关键架构决策之外，让他们缺乏主动性和责任感。


9. Concentrates project knowledge and the big picture in one head, limiting (and sometimes preventing) complete understanding for others.                                                                                                                                                                 只精通工程知识和大局一面，对其他方面几乎一无所知。


10. Contributes to creation of specialized IT verticals that hurt relations with the business.                                                     擅长在纵向专门的IT方面建立联系，但同时却切断了业务上的关联。

            完成该系统后，所完成的后期维护工作中，最大的以部分就是数据统计查询分析功能的完善了。

       系统软件框架提供了一套报表生成系统来完成数据统计查询的功能。这条报表生成系统可以生成excel和pdf两种格式的统计报表。

       这个系统使用报表的流程大致为：

       1.每个功能都提供一系列的报表，在软件中这些报表以二维字符串数组的数据格式保存，每个字符串数组对象包括该报表的唯一键值，报表名称，报表条件提供页面以及生成该报表的具体的Java类。

       2.选择需要生成的报表，系统将该报表的唯一键值传入统一的报表控制类，首先是跳转到生成该报表的条件页面，按照功能划分报表的主要原因就是每个功能的报表条件一致，可以使用统一的控制类。

       3.提交条件后，统一的报表控制类会调用该报表的生成类,这些类需要继承统一的接口,提供了一个统一的方法，返回数据类型为Vector集合的对象，这个Vector对象容器数据对象要求为：

     两个Vector对象，一个为表头Vector，一个为表体Vector，这两个Vector对象中存储的数据为字符串数组对象。

   在具体应用中，只要将数据填充到字符串数组中，再依次放入Vector中，报表框架会生成报表。

   这个框架的一个确定就是只能接受字符串数组对象，如果生成excel格式的报表，无法根据生成的报表进行计算，必须手动的将数据调整为数字型。

大家喝的是啤酒，这时你入座了，给自己倒了杯可乐，这叫低配置；给自己倒了杯啤酒，这叫标准配置；给自己倒了杯茶水，这茶的颜色还跟啤酒一样，这叫木马；给自己倒了杯可乐，还滴了几滴醋，不仅颜色跟啤酒一样，不冒热气还有泡泡，这叫超级木马；你同事给你到了杯白酒，这叫推荐配置。

       人到齐了，酒席开始了。你现一个人喝了一小口，这叫单元测试；你跟旁边的人说哥们咱们随意，这叫交叉测试；但是他说不行，这杯要干了，这叫压力测试；于是你说那就大家一起来吧，这叫内部测试；这时候boss向全场举杯，这叫公开测试。

      菜过三巡，你就不跟他们客气了，你向对面的人敬酒，这叫p2p；他回敬你，你又再敬他，这叫TCP；你向一桌人挨个敬酒，这叫令牌环；你说只要是兄弟就干了这杯，这叫广播。

   有一个人过来向这卓敬酒，你说不行，你先过了我这关，这叫防火墙。你的小弟们过来敬你酒，这叫一对多。

   酒过三巡后，你也该活动活动了，你一桌一桌的走，这叫轮询；你突然看见某一桌的漂亮mm，走了过去，这叫优先级；你去了坐下来就不打算走了，这叫死循环；你的老大举杯邀你过去，你只好走过去，这叫激活事件。

  你向一桌敬酒，他们说：“不行，不行，我们都喝白的。”于是你也喝白的。这叫本地化；你向boss敬酒，可是boss被围起来，你只能站在外围，这叫排队；你终于到了内围，小心翼翼的向前一步，这叫访问临界区；你拍照boss的肩膀说哥们咱们再喝已被，这叫越界。

                    一个程序员对自己的未来很迷茫，于是去问上帝：“万能的上帝啊，请你告诉我，我的未来会怎样？”

            上帝说：“我的孩子，你去问Lippman，他现在领导的程序员的队伍可能是地球上最大的。”

           于是他去问Lippman，Lippman说：“程序员的未来就是驾驭程序员。”

          这个程序员对这个未来不满意，于是他又去问上帝：“万能的上帝呀，请你告诉我，我的未来会怎样？”

         上帝说：我的孩子，你去问Gates，他现在所拥有的财产可能是地球上最多的。”

         于是他去问Gates，Gates说：“程序员的未来就是榨取程序员。”

        这个程序员对这个未来不满意，于是他又去问上帝：“万能的上帝啊，请你告诉我，我的未来会怎样？”

        上帝说：“我的孩子，你去问侯捷，他写的计算机书的读者可能是地球上最多的。”

        于是他去问侯捷。

        侯捷说：“程序员的未来就是诱惑程序员。”

       这个程序员对这个未来不满意，于是又去问上帝：“万能的上帝啊，请你告诉我，我的未来会怎样？”

      上帝摇摇头：“唉，我的孩子，你还是别当程序员了。”

           该系统软件框架对sql操作进行了封装，并提供了一批API帮助客户程序员更为简便的进行数据库操作。这些api包括:

1. 
   
          统一的DbConnection管理，客户程序员只需将要执行的sql语句作为参数传入，api会将结果列表以二维字符串数组的形式返回。api提供特殊的方法，例如翻页处理等都提供了相应的处理。
   
   


2. 
   
          按照功能划分dao操作类。类的编写有自身设计的一套规范。首先该功能的dao操作类设计为接口，然后按照数据库的不同特殊处理实现该接口。例如：接口为TestDAO.java，使用oracle数据库实现该接口，为OraTestDAO.java，使用sqlserver数据库实现该接口，为SqlTestDAO.java。dao操作类直接操作框架对数据库进行操作的DbConnection对象进行业务处理。
   
   


3. 
   
         所有的接口实现的dao操作类在web服务器的一个特殊目录中存在一个xml格式的配置文件。
   

   xml 代码

   
   

   
   

   
   

   
   
   1. <DAOLIST>  
   
   
   2. <DAO>  
   
   
   3. <NAME>testdaoNAME>  
   
   
   4. <CLASSNAME>com.test.dao.OraTestDAOCLASSNAME>  
   
   
   5. <DESCRIPTION>测试DESCRIPTION>  
   
   
   6. DAO>  
   
   
   7.  DAOLIST>  
   
   

   
   

   
   
   
   


4. 
   
       在web服务器的同时，会同时启动一个线程，读入该xml文件，并读入数据库配置参数文件。与hibernate这个框架相比，这个dao管理只能在web应用中使用。
   
   


5. 
   
       前几篇提到的web层使用的Ctrl控制类，在框架设计中不能直接操作dao操作类，而是存在一个中间层，包括BO类和VOListIter类，编写这两个类都需实现框架提供的接口。bo类主要包括数据库的除获取数据列表以外的所有操作，如录入，修改等，VOListIter类专门为实现数据列表翻页设计，通过该类获取翻页数据列表方法，需要首先声明一个长度为5的Integer类型的数组，DbConnection类的该方法需要这个参数，将该列表的当前页数和最大页数返回。
   
   

       这个数据库框架还提供了一些方便编写代码的操作，例如拼装sql语句，提供了一个这样的方法：MakeUp类。代码如下：

java 代码

这个makeUp方法会将sql语句拼装好，@表示数字占位，#表示字符占位。

这个系统的数据库操作管理大致就是这样了，比较简单，总的来说就是对dbconncetion 操作进行了重新封装，方便客户程序员的使用。

           维护的这个软件系统使用了一个比较复杂的系统权限管理系统，原本的设计是将用户对软件的使用权限控制到以最末级的菜单，并根据公司组织机构的设计，上级组织单位可以将自身所获得的权限继续授权到自己的下级公司。

       为了授权权限的操作简单话，不然每次都从几百个菜单选项中选择给该用户授权的菜单权限，恐怕这个权限系统管理员就要崩溃了。:-)，权限管理系统将权限分为了权限组，权限域，基本权限管理。

      权限组和权限域的区别我至今没有太分的清楚，郁闷中····在不多的使用当中（主要是设置测试用户的权限）感觉上这两种权限范围设置是评级的，没有谁是谁的上级的关系，不清楚当初为什么设置成这样，我用的主要是权限域的设置。

     给用户授权下权限，前提是已经有相应的权限域设置。

   1.权限域设置：权限域需要相应的设置编码，并选择该权限域包括的菜单权限。

   2.在设置好权限域后，就可以直接将该权限域授权到系统用户。

   权限管理使用了数据库信息管理，现在使用起来比较笨拙，不过由于最初的设置过于复杂，如果使用现在比较统一的xml文件配置，可能使用起来也不是很方便。

   每个菜单权限项都有一个自身的权限编码，该系统的菜单全部分为三级，编码规范为：一级菜单编码_二级菜单编码_三级菜单编码。这样，在授权权限的时候可以直接将一级菜单授权，用户相应的也获得该一级菜单下所有功能的使用权。

    用户登录成功后系统会将该用户的合法权限值压到一个集合中，放到sessin对象里。

   权限的控制在系统的页面和后台控制类都有实现。页面使用了上一篇提到的页面逻辑标签实现控制，在显示该页面之前，控制类使用了个系统框架提供的公共权限控制类将该用户的权限值压到页面值中。

  在调用该功能之前，控制类现会判断该用户的权限，有一个通用类，将该功能的权限和当前的用户对象作为参数传入，该类会判断在用户的权限集合中是否包括该权限，以决定是否继续执行该功能流程。

  这个系统的权限管理部分就是这么多了，下一篇讲讲这个系统的数据库管理部分。维护的这个软件系统使用了一个比较复杂的系统权限管理系统，原本的设计是将用户对软件的使用权限控制到以最末级的菜单，并根据公司组织机构的设计，上级组织单位可以将自身所获得的权限继续授权到自己的下级公司。

       为了授权权限的操作简单话，不然每次都从几百个菜单选项中选择给该用户授权的菜单权限，恐怕这个权限系统管理员就要崩溃了。:-)，权限管理系统将权限分为了权限组，权限域，基本权限管理。

      权限组和权限域的区别我至今没有太分的清楚，郁闷中····在不多的使用当中（主要是设置测试用户的权限）感觉上这两种权限范围设置是评级的，没有谁是谁的上级的关系，不清楚当初为什么设置成这样，我用的主要是权限域的设置。

     给用户授权下权限，前提是已经有相应的权限域设置。

   1.权限域设置：权限域需要相应的设置编码，并选择该权限域包括的菜单权限。

   2.在设置好权限域后，就可以直接将该权限域授权到系统用户。

   权限管理使用了数据库信息管理，现在使用起来比较笨拙，不过由于最初的设置过于复杂，如果使用现在比较统一的xml文件配置，可能使用起来也不是很方便。

   每个菜单权限项都有一个自身的权限编码，该系统的菜单全部分为三级，编码规范为：一级菜单编码_二级菜单编码_三级菜单编码。这样，在授权权限的时候可以直接将一级菜单授权，用户相应的也获得该一级菜单下所有功能的使用权。

    用户登录成功后系统会将该用户的合法权限值压到一个集合中，放到sessin对象里。

   权限的控制在系统的页面和后台控制类都有实现。页面使用了上一篇提到的页面逻辑标签实现控制，在显示该页面之前，控制类使用了个系统框架提供的公共权限控制类将该用户的权限值压到页面值中。

  在调用该功能之前，控制类现会判断该用户的权限，有一个通用类，将该功能的权限和当前的用户对象作为参数传入，该类会判断在用户的权限集合中是否包括该权限，以决定是否继续执行该功能流程。

  这个系统的权限管理部分就是这么多了，下一篇讲讲这个系统的数据库管理部分。