每个人走过来的道路都是不一样的，经历过的项目都是不一样的。虽然我的大学是计算机专业，但是理论上的东西学的不多，也不系统。我主要是实践，就是写代码了。上学的时候很喜欢写代码，把自己的想法变成代码，运行出来，实现自己想要的效果。我都是先写代码，做测试然后再去寻找理论依据。一直到现在我也是真么做的。
上班之后，当老板、客户提出需求的时候，我首先要做到的就是用编码的方式来搞定，而不是理论的方式。毕竟老板、客户要的是能用的程序，而不是漂亮的理论。写不出来代码，实现不了老板、客户要的东西，饭碗不就没有了吗？
所以我是实践派，就是写代码，用代码来实现。而我又是很懒的，不愿意写那么多的代码，尤其是重复的代码，不愿意做那么多的判断（比如权限判断），所以我就想办法去“偷懒”，于是写了一个大堆的自定义控件、类库，后来整理了一下，自然框架就诞生了。
如何应对需求变更？首先需求变更也得有点普吧，如果客户想要把石头变成金子，那是传说中的点金术，去看yy小说吧。如果客户想把恐龙变成美女，那么去网聊吧。我们讨论问题要现实一点、实际一点，不要抬杠对吧。
需求变化了，代码势必要进行一些改动，才能应对客户的需求。我所想要做到的就是“代码改动的尽量的少”——很原始的想法。
当需求变化了，我只需要做最少的改动就可以满足客户的需求变化，甚至是不需要我去改代码就可以实现。
我可没有去追求能够把石头变成黄金的方法，也没有去追求“银弹”，我的想法很简单、很原始，也很实际那就是 —— 少改点代码！
那么如何少改点代码呢？我的做法有两个：一是写自定义控件，把不变的代码都“提炼”到控件里面，在控件里实现，其他的地方调用一下就可以了。如果要修改的话，也是只需要改控件内部代码就可以了。这样就尽可能的少改代码。
二是根据配置信息实现一些功能。ORM不是有一个XML吗？O和R是如何对应的就靠这个XML里的内容进行对应的，那么如果有什么变动，只需要改XML，而不需要改代码了。我的想法也是这样，只是没有用XML，也不仅仅局限于“持久化”。而是涉及整个项目，不过请注意，不包括业务逻辑。复杂的业务逻辑是不可能配置出来的，简单的业务逻辑倒是可以，不过这个“简单的业务逻辑”如何来定义或者是划分，那就是一个问题了。
那么我能够配置出来什么？数据列表、分页、查询、表单。也就是简单的增删改查。现在的自然框架对于简单的增删改查都是可以配置出来的，就是说不用再写代码了。如果客户有什么这方面的需求，或者变更，那么我就不用再去改代码了！只需要改配置信息。
当然了不可能所有的东西都能够配置出来，我也没有那个打算。我的目的只限于那些简单的、繁琐的、没什么难度的、但是又不得不写的那些烦人的代码。对于复杂的业务逻辑我是根本就没有打算用配置的方式来实现，我也不打算让自然框架去实现这些复杂的业务逻辑，那么怎么办呢？当然是“委托”出去了，交给能够实现的人去实现。做力所能及的事情，不要大包大揽。
对了，最后还有一个权限，权限是很繁琐的，你永远都不知道客户的老板要如何去分配任务、分派人员，尤其是小公司。今天让甲去用A功能，明天就让甲去用B功能，而A功能又和B功能有交集，而且还有其他人也要可以用A功能。今天加一个部门，明天又合并两个部门。今天乙是C部门的经理，明天就是乙是D部门的经理，部门变了，那么做的事情是不是可以跟着部门变呢？如果是的话那还好办点，但是真的是这样的吗？
有首歌唱得好哇，女孩的心思男孩你别猜。所以我想说，领导的分工不要猜。领导愿意让谁去做什么，那么就让他自己去设计权限吧。当然了，领导不必势必躬亲，可以让他的秘书去做，或者找一个“权限管理员”去做。总之，这是客户的事情，程序员把功能（权限管理做灵活）做好了，让客户（权限管理员）自己去玩吧。
