规范在项目开发中的重要性

添加学习课件到MTK平台的项目快接近尾声了，现在把团队成员的程序整合在一起，这个过程让我很受伤。本来按我的规划，这个整合只需要两到三小时就能完成了，结果用了我两天多的时间，还是有问题存在。

项目伊始，开工会之后，我安排了一天的时间来建立环境和写环境架设说明书，本来建立环境没有很大的难度，可惜一个错误改变了一切。由于对平台不是很熟，我不知道在make文件里使用的宏定义，不需要再在mmi_feature.h中定义；我一直以为是在mmi_feature.h中定义宏，在make文件中使用。所以一直出现宏重复定义，导致环境迟迟不能整好。由于成员中很多人是第一次做项目，所以都很兴奋，干劲很足。很快小X就把环境建立好了，当然是在不知道还要在make文件中使用宏。为了加快项目进度，我决定还是使用这个环境。这个决定被证明是大错特错。

在项目开发中，作为项目的架构，要兼顾到项目中的各个模块，因为是团队开发，所以要考虑到各个模块不会互相影响。小X的环境正是模块高偶合的典型。当他把这个架构好的环境发给大家后，我看到了这种情况，于是在这上面做了修改，由于是刚开始，这个修改不大，整个工程有四五百M，所以我懒得再发布工程环境，只是把团队成员叫到一起，给他们讲解了怎么解偶合，怎么把各自的模块独立出去，以及文件怎么命名等。可惜这又犯了一个错误，人都是懒惰的，所以项目中就有成员没有这样来做，包括小X，所以在这个整合中，用了很多的时间来帮他解偶合。你说反正都已经做好了，随便加进去能运行就可以了。那样的话，类似的东西，有多种不同的做法，而且他说一些自己模块的东西都加到公共的地方来，那怎么可行呢！以后维护的时候，谁会看得懂这些乱七八糟的东西了。

对于新手来说，可能对于规范的东西的认识更低。项目开始的时候，为每个模块分配了ID，而像小M，他就不用为他的模块定义的ID，而是自已定义ID，这样就出现了ID对应不起来，每次关于资源的编译，就要花半个小时，所以为这小小的失误就花了不少的时间。

由于环境不是自己架构的，加上修改都是要开会的形式进行的，所以没有对项目中用到的文件名和ID名进行规范，实际上在开会的时候已经有说明了，可是交到我手上的手上的时候，文件名的形式各种各样，五花八门，kao，这怎么可行呢，于是又要为他们改文件名，唉，为什么这伙人不能在开始的时候就记住这些呢。所以以后在项目之初，一定要有文档的形式来规范各种命名。

现在开始怀念华为的那样开发方式了，他们半个月左右要进行一次代码检读，代码有不符合规范的，设计方案有错的，那时就能发现了。唉，我都在推行规范化程序开发，为什么执行的时候没有想到这一点呢？

又怀念泰又的开发方式了，当时项目开始的时候都会写一篇环境架构说明书，实际上负责这个项目的时候我也有准备这样去写，种种原因没有坚持，以为这个的一个小项目没必要这样去做。“麻雀虽小，五脏俱全”，老毛的这句话不无道理，我对老毛的敬仰尤如淘淘江水，连绵不绝…

结论：以后带项目的时候，无论怎么情况，都要在项目开始阶段都进行规范，建立环境说明书，定义命名规则。在项目进行到一段时间的时候，对部分成员的代码进行抽样检查，检查代码是否符合标准。

<script type="text/javascript"> function ImgZoom(Id)//重新设置图片大小 防止撑破表格 { var w = $(Id).width; var m = 550; if(w < m) { return; } else { var h = $(Id).height; $(Id).height = parseInt(h*m/w); $(Id).width = m; } } window.onload = function() { var Imgs = $("content").getElementsByTagName("img"); var i=0; for(;i