小议公司架构之痛（好吧，我承认我有点蛋疼，写了下面乱七八糟的文字）大师有风险，选择需谨慎！公司采用的veloc
小议公司架构之痛
（好吧，我承认我有点蛋疼，写了下面乱七八糟的文字）
大师有风险，选择需谨慎！
公司采用的velocity，好吧，按理说采用velocity更易于MVC架构分层，可是velocity却是公司永远的痛。。。
简单介绍架构（基于java）：
首先上层数据支持采用了互联网常用的手段“服务”，把具体的数据处理抽离出来，交由专门的部门维护；
但是服务仅仅是给你提供基础数据，并不能一次性满足你的业务需求，所以一般情况下，一个界面的模块会调用大量服务然后拼装了数据进行展示。
好吧，问题出来了，数据如何封装呢？
记得我刚入行的时候写asp，不懂面向对象，界面嵌入代码扮演着各种“角色”；
一千行的界面五百行asp代码，只要一改版，就面临着难题，自己嵌套新模板到头疼，美工也无从帮助你，若你做过就会懂得。。。
公司的痛：
但是，作为知名互联网公司（就是我现在工作的公司，具体名字就不说出来了）刚经过改版，竟然还是采用“面向过程”编程方式，大量拷贝代码、冗余代码存在于模板中。
采用了牛B的技术，但是写了一坨狗屎。
问题存在的原因非常明显，公司那么多模块，竟然只有一个controller类，对你没听错，一个每天PV上亿的网站只有一个controller类。
这架构设计于2011年，一帮大师之手。
问题一：好吧，大师我问问你们，就一个controller类，你的service放哪？
大师说，没关系，我们有一套架构，会在这个唯一的controller里找到你在后台配置的匹配service（类似于可配置的工厂）。
是不是有些不懂大师的这个设计？好吧，我来了很久才知道还有这个。。。
无论从新员工的学习成本还是维护成本上，您觉得这合适么？
且工厂给你指定了固定的抽象对象，就俩接口（因为大师就一个controller，只能固定执行你实现的接口），您让我们各业务线的业务逻辑放哪？
我有时在想，这些大师费半天劲，搞的我们看不懂，是为了他们要为以后自己写一套web容器做铺垫么？！！！大师的世界你不懂！！！
问题二：小弟们搞不懂大师的“架构”，但是还要拼装数据啊，咋整？
大部分的小弟选择了写入模板，反正有模板语言，这样就导致了混乱啊混乱。
公司的产品本来就多，他们闲的蛋疼就提需求，天天改版。。。你懂的--KPI
其实，小弟们还可以选择helper类，引入模板语言，扮演service的角色，但是这样好多业务线，模板引起配置文件就苦了。。。
问题三：无注释
每当我看一下开源架构没有注释的时候，就想吐槽。
公司这帮大师写了所谓内部架构，但是没有一行注释。后询问大师为什么，大师说没必要写，只要方法名起的易懂就行。
大师的方法名写的太容易懂了，最简单的方法首字母 “大写” 大师们都懂。
所以，请大师们有点节操，在满足您的乐趣和牛B的头衔外，也要考虑一下实用性和各种成本啊。。。
