关于程序架构设计
2014-06-22
关于程序架构设计
最近编程当中，越来越在意程序架构问题，经常纠结怎样才是好的设计，怎样才能将程序解耦，怎样才能写出易扩展，层次分明好维护的程序。可是想来想去也是不能决定怎样做才是最佳。不过最近自己是肯定了一样东西：要想真的做出好的架构，划分好模块是第一次。只要模块划分的清晰，独立和少耦合，后面的事情就好做了。
这种想法也不单单只有我才有，我现在所在项目负责人在一个程序架构设计的技术讲座上说过这个观点。而我从我们项目的架构也看出他是这样实行的。一般在我们建立项目之初，就先建立好目录结构，而这个目录结构也很讲究，它就直接体现了我们是怎么划分模块和划分层次的。现在我们项目主要分两大块，UI模块和module模块。然后UI目录下就按照功能划分出一个个子目录，对应的再module目录下也是按照功能划分出一个个子目录。这里UI目录下的子目录结构和module目录下的子目录结构基本是一致的。然后在资源文件目录下，也是按照UI子模块那样划分，建立不同的子资源文件。只要划分好了模块，每个模块足够独立的花，每个模块里面是怎么分层，怎么做设计的，对别的模块影响不大。即使这个某个模块做得很烂，到时要重构的也只是那一个模块而已。
现在我们公司的项目很多模块划分都不是特别好，能够做到像上面那样划分模块和架构的项目估计都是很多。互联网公司人员流动大，三两下就换一拨人，每拨人里面各个技术参差不齐，根本没办法做到很好的架构设计。但是上面这种基础的架构还是可以做的，而且是可以做好的。
可是光是靠划分模块是做不到一个好的程序架构，而且一个项目有些模块是划分不出来或者跟其他模块联系很多。所以还有其他东西要做。分层就是一个。项目整体可以分层，还有模块里面也可以分层。最经典的分层就是MVC模式。像我们上面的分UI和module就是将项目按MVC分层，V,C分在了UI里，M对应的时module。一般来说，在M之下，还有一层是数据访问层，一般是数据库访问层或者是网络访问层。实际项目都很复杂，各种关联，划分好层次解耦不是件容易的事。还有为了好管理代码和复用，是需要抽出一下共用模块的。例如网络访问的话一般是一个全局共用模块，还有几乎每个移动项目必不可少的图片管理模块等。
以上说的都是在宏观方面的，真正落实到一行行代码间又有更多要注意的了。这里又有一套编码要遵循规则：API设计，接口设计原则，设计模式等。最近我经常烦的是这个类是不是太大了，要怎么分割才好。这个方法是放在这个类好，还是放在那个类好，还是新建一个类来封装？很多时候我自己都不知道怎样做才是对的，或者说是最好的。我越发觉得自己很弱，很多东西根本无法判断优劣。自己还是太嫩了，代码写的远远不够。每当这个时候我自己就会信心不足。
唯有多写代码和思考来减少为自己的无知带来的恐惧