发布：2014/7/10 16:14:00作者：管理员 来源：本站 浏览次数：1620
编程六月定律说每个程序员都应该回头看看自己6个月前写的代码，并且应该会唾弃当时写的那些代码。接触CI框架也差不多半年了， 现在看看6月份做的项目，确实有很多地方是可以改进的，这至少说明对CI框架更熟悉了。
CI框架是一个简洁、文档很齐全的框架，利用半天的时间看看手册， 就差不多上手了，但只是上手，要深入还需要历经一些项目的积累和领悟。经常听到说程序要写的可扩展、要方便维护，但要做到是很难的。相信很多人利用CI框架就像吃了加速光环一样，很快，但写的快不一定代表就写的好，快的同时也许埋下了很多的坑。
下面谈谈这段时间由CI想到的一些问题，也许不仅仅是关于CI的，更多的是如何把控好项目。
1、我们弄清楚每个文件夹的职责了吗？弄清怎么分层了吗？业务逻辑要写哪，是否该在控制器写SQL，是否该在视图中写业务代码？
这些问题没有绝对的答案，我们需要根据项目来决定。我们越随心所欲的开发，在一定程度上会加快我们的速度，但同时维护成本也会越来越大。一个项目就好比一颗树，也许刚开始种的时候就歪了，也许长着长着就歪了。根基很重要，后面的维护也重要，我们的每一个动作都可能影响到它的走向，所以项目的初始化工作需要做好。
2、项目规范是否已定好？SVN配置好了吗？多环境方便配置吗？
手册上有CI的开发规范，但还是觉得和自己本身的一些规范未融合，还需要在项目中去积累。这两天看一个没有配置多环境的项目，而且项目是通过SVN的方式发布的。每次提交SVN的时候都战战兢兢，这样子多环境的优点更加凸显。所以前期多花点时间把这些问题理清楚，对后面是非常有利的。
3、能在类库中、函数中、模型中或者其它地方调用CI的中的方法吗？
答案是可以的，CI的get_instance方法即可获取当前实例，获取到之后你可以在任何地方调用，甚至模型中出现调用控制器的方法都可以。能获取到是一回事，但究竟要不要这样子用呢？我觉得尽量少用，用的越多与CI依赖越紧，可能以后增加了某个非CI入口的请求文件，你会发现你写的类到处都用不了，我们要写更方便重用的代码。
4、CI中怎么才能充分利用类的一些特性？
当前感觉CI的类更多的是针对单一的类，怎样才能更好的利用类的特性，更合适的封装？比如说一个导出的功能会有几种实现，有excel、csv或者其他等，如果要使用策略的思维该怎么做？类该怎么引入，参数怎么传递，load的方式感觉有所限制，怎么样调整的成本最小，更适合CI？
5、控制器中可以很方便的分发到不同的模块，那模型呢？如果要按不同模块继承不同的模型，什么方式才是最适合的？
6、当我们发现系统中存在的问题或者某些函数已经被遗弃时，我们要及时的修正。因为你不去改，其他人也不会改的，也可能不知道怎么改，不敢改，我们也该为自己的代码负责。
7、尽量把系统做简单。做复杂容易，做简单难，很多时候不知不觉中就把事情越做越复杂，然后自己都无法掌控了。
项目需要大家共同的维护，而每个人都有自己的想法，我们能不能藏住其中的某些想法，让大家有一个更和谐的代码环境，这应该就是我理解的团队精神吧。
