CodeIgniter心得体会

编程六月定律说每个程序员都应该回头看看自己6个月前写的代码,并且应该会唾弃当时写的那些代码。接触CI框架也差不多半年了, 现在看看6月份做的项目,确实有很多地方是可以改进的,把这些变化的想法记录存档,给自己梳理的同时也给他人一个参考的机会。

CI是一个非常简洁、文档齐全、相当方便扩展的框架,花半天的时间看看手册就可以上手了,但只是上手,要深入还需要历经一些项目的积累和领悟。我们常常说程序要可扩展、易维护,但要做到是很难的,这不是说看懂了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、CI控制器中可以很方便的分发到不同的模块,那模型呢?如果要按不同模块继承不同的模型,什么方式才是最适合的? 通常情况下控制器会更需要这个功能,目前对模型的理解大多还是一对一,也许有更好的方式。模型的公用CI中只能通过INCLUDE的方式加载进来,还没有发现更契合CI的做法。

6、当我们发现系统中存在的问题或者某些函数已经被遗弃时,我们要及时的修正。因为你不去改,其他人也不会改的,也可能不知道怎么改,不敢改,我们也该为自己的代码负责。

7、尽量把系统、功能做简单。做复杂容易,做简单难,很多时候不知不觉中就把事情越做越复杂,然后自己都无法掌控了。

项目需要团队共同的维护,而每个人都有自己的想法,我们能不能藏住其中的某些想法,让团队有一个更和谐统一的代码环境,这应该就是我理解的团队精神吧。

-- EOF --
发表于: 2013-12-01 23:30
标签: PHP CodeIgniter