发布:2014/7/10 16:14:00作者:管理员 来源:本站 浏览次数:1371
编程六月定律说每个程序员都应该回头看看自己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、尽量把系统做简单。做复杂容易,做简单难,很多时候不知不觉中就把事情越做越复杂,然后自己都无法掌控了。
项目需要大家共同的维护,而每个人都有自己的想法,我们能不能藏住其中的某些想法,让大家有一个更和谐的代码环境,这应该就是我理解的团队精神吧。