开源软件的一些想法 大众软件SpringStruts配置管理框架
程序员文章站
2022-05-27 13:52:53
...
从工作到现在陆陆续续的接触到了很多不同的开源软件，也就是些形形色色的框架，包括出名的包括不出名的，有成功的也有一直默默无闻的。
如今咱也做开源了，有些东西不吐不快。
首先开源软件的目的：
对于作者而言存在什么目的？出名？当然有那么点，但是不是全部，你为什么写一个框架呢？我是这样的，慢慢的熟悉了一些设计模式之后逐渐发觉自己在写代码的时候不断地重复这些代码和设计，这种重复到了一定程度之后我就开始觉得繁琐，于是乎在某天找个时间抽象出来，作为开源软件出现了，当然也是一种标榜，标榜自己达到了什么样的程度。
当然也有不是基于这样的考虑的开源软件，比如我在写dbutil的时候，并不是想替代什么或者因为数据库代码写的太多了，而是因为各种数据库的ORM框架实在太烦了，他们的配置已经超过了我能忍受的范围，也许开发人员有各种工具自动生成所有的代码，但是维护这些东西的时候往往的为了一个小小的变动需要修改几处甚至于十几处的代码和配置，这样的效果实在让人难以忍受，于是乎就想能不能把ORM的细节屏蔽掉，因此产生了这个dbutil，完全屏蔽掉数据库ORM的细节，使用一种约定的方式进行对照而不是通过配置文件进行解耦。
说了这么多，还没有说到重点，开源的目的是什么？交流么？看起来不是那么美好，这种交流是一种单向的信息交流，绝大多数人只能提交bug，只有极少数的人在维护和交流。
其实开源的目的是主导，就是为了主导某种方向，在这点上面struts 1就特别成功，spring也特别成功，而hibernate则陷入了大众口水的汪洋大海。
当然如果我们熟悉ROR的话，ROR则是一种绝对的成功。
第二，开源软件的形态。
我觉得这是一个需要大谈特谈的重点，作为一个框架他的重点需要是什么？是简化开发，强化代码的稳健性，而不是增加配置的复杂性和学习曲线。
很多东西在成为了一种风俗之后就彻底的变化掉了，比如spring，本来作为一个bean容器提供的很多功能是非常有用的，但是随着项目的增大和各种功能的要求，spring变得越来越臃肿，配置文件变得复杂而且难以控制，每次一些细小的变化都需要一个熟悉spring的人员来进行操作。但是设想一下如果所有的代码都是由一个涉及良好的架构师在做的话会有什么样的效果呢？仔细想一下，如果没有spring只有简单的java代码，每处改动都不涉及架构的改动，每次功能增加只需要进行简单的实现和继承等等，这样的代码维护起来相对于交给spring进行管理我觉得还是方便的多的。
当然并不是说我们的spring不够强大，spring给我们提供了很多实用的东西，但是我觉得spring已经渐渐地偏离了原来的方向，也许spring的目的是一个一站式的解决方案，但是spring和很多我们普通的开发人员越走越远了。当然如果学习曲线下降的话，那么一切还是可以挽回的。
这也就是我要讨论的开源软件的形态的问题，开源软件必须以一种简单，微小的形态出现，我的意思不是说jar包小，而是说配置文件小，学习的曲线变低。比如我开发dispatcher的初衷就是实现类方法到url的直接映射。当时有个朋友在学习struts，在他被struts的配置文件搞的有点晕的时候我给他看我了我做的东西，然后该兄弟就反问我一句，这个不是java原来就有的么？呵呵，也就说学习曲线基本是零，因为这是一种大多数人的思维方向。简单微小，符合大众的思维方向。
当然会有很多人讨厌这种简单和微小，想象一下一个项目如果有大量的配置，那么维护起来是不是需要更多的人呢？比如使用了spring那么下次在选择人选的时候是不是会坚持找精通spring的人呢？这样保证了两点，第一spring的市场不会萎缩，第二就业人员的市场也会越来越大，只要spring越来越复杂越来越臃肿，就会有越来越多的springer出现。
但是，我或者说我们烦了。我总觉得很多东西是可以被忽略掉的，工作的机会如果我们把事情做得简单了那么将会促进很多东西的进步，然后会有更多更好的东西出现，当然还有更多的工作机会。
第三，开源软件的出路
这个是我所关心的，因为自己也想从事开源，很多大的开源软件现在我想主要是从事技术支持，但是我们的出路还不是很明确，而且以无限降低学习曲线和维护代价为目标的开源软件，真的不知道出路在何方了
如今咱也做开源了，有些东西不吐不快。
首先开源软件的目的：
对于作者而言存在什么目的？出名？当然有那么点，但是不是全部，你为什么写一个框架呢？我是这样的，慢慢的熟悉了一些设计模式之后逐渐发觉自己在写代码的时候不断地重复这些代码和设计，这种重复到了一定程度之后我就开始觉得繁琐，于是乎在某天找个时间抽象出来，作为开源软件出现了，当然也是一种标榜，标榜自己达到了什么样的程度。
当然也有不是基于这样的考虑的开源软件，比如我在写dbutil的时候，并不是想替代什么或者因为数据库代码写的太多了，而是因为各种数据库的ORM框架实在太烦了，他们的配置已经超过了我能忍受的范围，也许开发人员有各种工具自动生成所有的代码，但是维护这些东西的时候往往的为了一个小小的变动需要修改几处甚至于十几处的代码和配置，这样的效果实在让人难以忍受，于是乎就想能不能把ORM的细节屏蔽掉，因此产生了这个dbutil，完全屏蔽掉数据库ORM的细节，使用一种约定的方式进行对照而不是通过配置文件进行解耦。
说了这么多，还没有说到重点，开源的目的是什么？交流么？看起来不是那么美好，这种交流是一种单向的信息交流，绝大多数人只能提交bug，只有极少数的人在维护和交流。
其实开源的目的是主导，就是为了主导某种方向，在这点上面struts 1就特别成功，spring也特别成功，而hibernate则陷入了大众口水的汪洋大海。
当然如果我们熟悉ROR的话，ROR则是一种绝对的成功。
第二，开源软件的形态。
我觉得这是一个需要大谈特谈的重点，作为一个框架他的重点需要是什么？是简化开发，强化代码的稳健性，而不是增加配置的复杂性和学习曲线。
很多东西在成为了一种风俗之后就彻底的变化掉了，比如spring，本来作为一个bean容器提供的很多功能是非常有用的，但是随着项目的增大和各种功能的要求，spring变得越来越臃肿，配置文件变得复杂而且难以控制，每次一些细小的变化都需要一个熟悉spring的人员来进行操作。但是设想一下如果所有的代码都是由一个涉及良好的架构师在做的话会有什么样的效果呢？仔细想一下，如果没有spring只有简单的java代码，每处改动都不涉及架构的改动，每次功能增加只需要进行简单的实现和继承等等，这样的代码维护起来相对于交给spring进行管理我觉得还是方便的多的。
当然并不是说我们的spring不够强大，spring给我们提供了很多实用的东西，但是我觉得spring已经渐渐地偏离了原来的方向，也许spring的目的是一个一站式的解决方案，但是spring和很多我们普通的开发人员越走越远了。当然如果学习曲线下降的话，那么一切还是可以挽回的。
这也就是我要讨论的开源软件的形态的问题，开源软件必须以一种简单，微小的形态出现，我的意思不是说jar包小，而是说配置文件小，学习的曲线变低。比如我开发dispatcher的初衷就是实现类方法到url的直接映射。当时有个朋友在学习struts，在他被struts的配置文件搞的有点晕的时候我给他看我了我做的东西，然后该兄弟就反问我一句，这个不是java原来就有的么？呵呵，也就说学习曲线基本是零，因为这是一种大多数人的思维方向。简单微小，符合大众的思维方向。
当然会有很多人讨厌这种简单和微小，想象一下一个项目如果有大量的配置，那么维护起来是不是需要更多的人呢？比如使用了spring那么下次在选择人选的时候是不是会坚持找精通spring的人呢？这样保证了两点，第一spring的市场不会萎缩，第二就业人员的市场也会越来越大，只要spring越来越复杂越来越臃肿，就会有越来越多的springer出现。
但是，我或者说我们烦了。我总觉得很多东西是可以被忽略掉的，工作的机会如果我们把事情做得简单了那么将会促进很多东西的进步，然后会有更多更好的东西出现，当然还有更多的工作机会。
第三，开源软件的出路
这个是我所关心的，因为自己也想从事开源，很多大的开源软件现在我想主要是从事技术支持，但是我们的出路还不是很明确，而且以无限降低学习曲线和维护代价为目标的开源软件，真的不知道出路在何方了