最近接手其他人做的项目，导致之前的一些幻想破灭了。因为刚工作的时候做项目是php，而php本身的web框架一般只简单区分mvc，稍微麻烦一些的会多个library或者helper之类的。这样分层很少有优点同时也有缺点。当然了，现代的框架一般支持namespace，你也完全可以借鉴其它语言来做自己的内部框架。这里先不说这个。
mvc的优点自然是简单，无论一个新人有没有做过相关的工作，你只要跟他简单说明每一层的职责是什么，马上就可以开始工作。缺点也非常明显，因为太简单，所以代码在累积到一定量以后会变得难以控制复杂度。同时容易让没什么经验的程序员把代码写得难以维护。
所以之前听说java的框架这方面做得好一些，然后对部门的java项目抱有一些幻想。不过在实际接手后，发现理想和现实真是有比较巨大的鸿沟。所以先来总结一下共通的初级程序员比较容易犯的错误吧。如果哪天自己带团队了，面试别人也可以拿这些题作为区分人的一种界限。做项目的时候有思考的人和不思考的人还是会有不小的区别的。
命名太啰嗦，或者不规范这个问题其实挺普遍的，即使是科班出身的人，工作了很多年的人，写程序也可能冒出来一堆vara/b/c之类的变量。如果你的程序本身短小精悍，或者只是纯粹的算法题，这样似乎问题不大(反正ojac了以后你可能也就再也不会看自己的代码。但这样的代码放在生产环境中，问题就很大了。首先有些变量本身的生命周期可能会超过一个横着放的屏幕。这里逗逼一下，不是谁都能买得起Dell的可横可竖的屏幕好吗。比如按照我的13寸笔记本来看，vim的全屏模式下只能显示33行(当然了，我视力不好，字体比较大)。所以如果在第一行声明了一个变量vara。那么顺着读下去，在33行之外。。。我觉得我肯定不记得这是什么东西了。
如果你想要声明一个变量，一定要让这个变量的名字本身具有含义，比如productName，productPrice，userId，userInfo，orderHistory。但保证名字有含义的同时，一定要保证名字和其含义对应得上。并且不要把一个命名好的变量以优化的名义反复存储各种不同的值。例如我们这里的代码就曾经出现过看起来是userIds，但实际上打印出来却是一堆userInfo的信息的事情。着实让人恼火。
业务内部逻辑的变量命名还是讲究单词打全，意义明了等等。如果是框架本身的一些内容命名的话。例如java的spring框架里的service命名，反而应该稍微简洁一些。例如：
KnowledgeServicekService;OrderServiceoService;UserMapperuMapper;
因为在整个class内部，service、mapper一般只会有唯一的对象，所以这里就算看不明白了去整个类的头部也能找得到。因为这些对象使用频率很高，所以简短一些对打字有好处(其实你是想偷懒吧)。当然了，如果你喜欢把名字打全，那我觉得也没什么不可。
变量命名之外，函数命名也很重要
例如上一家公司就有人会把函数叫dealData或者handleData，怎么看怎么别扭。。换成formatData是不是就很明了了？细节之处见真章。
魔法数字这个问题在哪里都看得到，最简单的例如各种订单的status跳转。你会发现各种updateStatus(1)之类的神奇代码。如果恰巧数据库的表定义里又没有这个status的定义，那必然会变成维护人员的噩梦。解决方法很简单，在配置文件中集中维护这些特殊变量。
再进一步的话，应该引入各种方便的配置系统。例如java里常用的disconf，可以在不对系统上下线的情况下在配置系统里看到配置的key和value，并且可以即时地进行修改和配置下发。如果是其它语言没有类似系统的话，也可以借助现在流行的etcd或者zookeeper来自己开发，不会太复杂。
如果你发现自己的系统里充斥着各种不明所以的数值的话，那么就是时候考虑引入配置进行管理了。(其实从一开始就应该做这些事情)
解决了魔法数字的问题，但不对配置文件进行分类有了配置系统以后，其实还有个麻烦的问题。就是所有配置都放在一个文件里。例如之前做的系统，把所有key和对应的sql都放在一起，然后导致配置文件变得很大很难看。想改个简单的sql连找都找不到在哪里。
改进方法很简单，第一是对配置文件进行业务逻辑分类，例如Order相关的配置项就放在Order的下面。如果配置内容还是很多，可以进一步进行粒度的细分，例如OrderHistory,OrderType之类的。其实一般的系统也不会这么复杂。
分类粒度问题对配置进行了分类，但有时候也有可能配置粒度实在太细，导致文件很多，找起来还是很不方便。
这怎么办呢？
第一是粒度划分要掌握好度，第二是相关的配置最好有对应的