关于架构

关于架构，或许不应该是像我这样一个工作年限的人讨论的话题，但是任然想发表一下自己的看法，至少可以提供自己以后涉及到架构的时候参考。

 

说的架构，我就想到了java的优势，java出道的时候是以其跨平台的优势存在的，但是这种优势并不是完全得以体现的，尤其是加上它比C++的运行效率低很多的时候，它这个有点并不是十分吸引人。

但是最终它还是胜过了C++的地位，个人觉得主要有两个原因。一个是java语言的设计更加面向对象，学习和使用的门槛更低，另外一个原因就是开源。我觉得后者的优势更加重要。

正是因为开源，所以才有现在如此多的基于java的开源框架，所有领域的所有话题几乎都有其对应的一个比较使用的框架存在。框架实质是对架构的思路的一种具体实现。

 

就如同计算机的出现，以及计算机编程语言的发展史一样，人们促使一项技术的发展的目前是使其简化和更容易让人接受。

当时科学家怕计算，才生了计算机，想简化计算机的操作才出现程序。可是，时代是在变的，计算机的应用程度也是变的。

当面对更加复杂的逻辑，更加精美的画面的时候，人们无法盲目的通过某种计算机语言进行实现。

这个时候催生设计，就像20年前我们不知道啥叫设计模式一样，10年前我们对框架的概念也很模糊。当各种大型的业务含义复杂的项目蜂拥而至的时候，大家纷纷拿出解决方案，也最终出现各种框架和架构。

java的成功体现的是设计的重要性，如实我们在实现一个软件产品或者服务平台的时候，都会情不自禁的想到架构。重用和易用的话题不断。这个时候，人的倾向分为两类，一类是完全由自己实现框架，从设计到代码的具体实现。另一种是把自己的框架建立在开源之上。把框架建立在别人之上的好处是自己实现的代码会少很多，但是头痛的是第三方框架不一定满足自己的业务需求。

 

 

最近公司在重新制作自己的产品，包括平台和IDE都在重新做。如是对上述的各种场面的印象很深刻，大致分为几种现状。

1.具有盲目封装倾向的行为：

因为公司有很多IDE，而IDE都有自己的编辑器，所以为了达到功能的复用，就要对编辑器的底层进行封装。首先，需求是谁提出来的？是Boss。但是boss本身对IDE的技术不是很了解，他们只是从产品的规划的角度来考虑，需要这么一个过程。但是，个人认为如果只是对编辑器封装而不把属性视图等辅助视图的功能连带进去封装，是没有太大意义的，因为gef本身的结构已经很清新和简洁了，重用的功能也很多。如果在在这个基础上进行封装，封装有时候后更灵活性的丧失挂钩的，有时候的过度封装导致无法很灵活的扩展。再加上公司本身IDE比较资深的也不多，整个结果给我的感觉就是一个败笔。我觉得一个新的架构如果建立在老的架构之上，首先必须比老的架构简洁，其次是功能的灵活性肯定不能太差。但是结果不是这样的。

 

2.完全由自己实现架构：

对于一个牛人比较多的企业，有这么一帮人专门负责前期业务需求的调研，以及架构的设计（画出规范的UML图），讨论式选择最优的架构和实现最佳的实现方式。我觉得完全由自己实现是很有意义的，因为功能的实现上更加没有局限性，当然这个前提依旧要是建立在严格的版本控制的基础上。

但是，如果前期无调用，中期设计的质量又有待考证，后期版本的控制管理又不够严格。其最终结果也就比什么架构都不设计一样。只要大家都对平台有修改权限，最终代码会改的跟马蜂窝一样。最后会变的承重和不适用。

 

或许上述两种情况是现在所有中国的IT企业面临的问题。一方面想封装，另一方面又设计不好。