CodeIgniter ( 6 ) - 心得体会

编程六月定律说每个程序员都应该回头看看自己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、尽量把系统、功能做简单。做复杂容易，做简单难，很多时候不知不觉中就把事情越做越复杂，然后自己都无法掌控了。

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