十一月工作总结

十一月的工作总结

1.
头文件包含问题
1）
交叉包含问题，在*.h中包含了头文件。例如：a.h中include了b.h，而在b.h中include了a.h，则出错，相当于死锁。至于在a.c中include了b.h，b.c中include了a.h，则无此无问题。
2）
在包含的头文件中，有多处宏定义了同一个宏名称，但是宏定义不一致，导致在某一处的*.c中使用该宏出现问题。例如：
在a.h中，
#define _ZZP 1
在b.h中，
#define _ZZP 0
在sample.c中，
#include “a.h”
#include “b.h”

这里，sample.c不知应该使用哪个宏。

解决方法：
1.2.1）只include其中一个*.h文件。
1.2.2)若不得不include两个文件，则使用比较猥琐的方法。在sample.c中重新定义该宏，注意该重新定义的宏应该写在上面两个include语句之后。

3）对于一个比较大的project，因为各个module的*.h文件是分散在各个目录下的，按照常规做法，当某个module需要include其他module时，include需要指定这个*.h文件的路径，相当麻烦。现在有两种做法：

1.3.1）这种解决方案中，在每个module下都有个lis文件，我们可以在每个module的lis中将本module将要被外部引用的头文件添加进去。这样当simulator编译时会自动将该lis枚举的*.h文件自动copy到某个INC目录下，该目录即作为所有module搜索*.h的地方。而在引用这些*.h的文件中，include语句只需添文件名。

1.3.2）对于某个要引用外部module的module，在VS2005中，project
property->配置属性->c/c++->附加包含目录中将被引用的module加入。这样处理后会体现在*.vcproj文件。同样，在引用这些*.h的文件中，include语句只需添文件名。
2.
C语言作用域相关
C语言中，变量声明应该位于局部作用域开头，否则会有sytex
errror、“;”、endeclare identifer的error。若必须要将变量在函数开头以外地方声明，那么另外用{}建立一个作用域，且变量声明位于局部作用域开头。
3.
Debug相关
3.1）打印log信息。通常可在函数入口处打印传入参数，函数结束处打印返回值等。对于一些开关语句，或是if/else语句，若有必要，也可打印。打印时加上函数名等一些特有的标记可以在debug时快速定位。
3.2）debug的一般步骤。首先，先理清code的逻辑，目测下确认与逻辑无关。接着，用工具debug。注意不能太过依赖工具，否则debug效率会降低。
3.3）一步一个脚印原则。每编完一个模块即进行验证，不要等编了一堆代码才验证，到时debug定位是个问题。当然也不能过于频繁验证，这就是个编程艺术问题了。
3.4）对于simulator上编译断点不能命中的问题，可用从以下方面排查：1）代码是否已经编译过，但是仍未将动态库copy到simulator那边。2）simulator的进程是否已经绑定了进程。3）进程绑定方式是否为native。
4.
编程习惯相关

函数传入参数时，若类型不一致，要用强制类型转换。否则，simulator虽然编通过，arm不一定编通过。放到非手机开发上，保证传入函数的变量类型与函数形参一致，是个好习惯。
5.
语法相关
5.1)宏定义的的使用。

#define _ZZP 1

//… …

#ifdef _ZZP

//… ….

#else

//… …

#endif


6.
编译相关
对于静态module，在真机编译时，需要编译AMSS。查看静态模块是否编译通过，可以查看/build/ms/bin/#project
version#。静态module真机编译完后，烧入真机需要做：1）software
download->CEFS，烧系统。2）software download->multi
image，烧资源。
动态module不需编AMSS，仅需用EFS
Explorer将修改的module的mod和mid更新下。若需加入资源，也在此操作。

对于一些module，在真机上时静态module，用arm编译会有问题。而在simulator上则是动态模块，用simulator编则无问题。
7.
软件管理相关
7.1)在中国现在的IT界，对于上层的决定，是否就一定要贯彻执行，甚至对于一些不可能的任务、不符现实的需求。一个个优秀的软件工程管理工具，是否只是沦为形式化的东西。
7.2）对于测试人员提供的bug，其bug描述不清，再加上没有手机预期规范（spec）等进行手机功能预期，所以就增加了开发人员与测试人员的沟通成本。