【精品博文】笔记：近期总结之开发大坑

有一阵子没有更新博文了...

人的惰性也是有惯性的，而且一旦停下来，再次开始就有了一些难度。就好像汽车在启动的时候油耗往往是最高的，跑起来之后，油耗反而会下降。

最近新接手一个比较急的项目，拿到手之后，发现软件简直一塌糊涂，好在功能不是特别复杂，看了看代码，发现还能hold住。项目期间，有一些体会，记录下来，作为备忘。

硬件

有一个器件的封装做的偏小，器件放到PCB上之后，将焊盘都覆盖住了，焊接难度很大，而且容易造成虚焊。以后要注意不能太小气...

有一块PCB开槽问题，偷懒使用不规则焊盘（长方形孔）代替机械开槽，

厂商用低版本的软件打开PCB文件后，孔的形状发生了变化，导致开孔错误，最后返厂重新加工。以后应该更加规范一些，在布局布线之前把机械层和禁布层绘制好，在开孔时，最好小心一些，最好多重保险。也可以考虑直接提供光绘文件给厂商。

软件

软件的工程组织、文件的组织、函数功能划分都过于简单。

所有的文件都放在一个文件夹下，单个c文件过于冗长，不便于代码的修改，以main函数为例，竟然有2500行，各种功能都包含一些，大大增加了软件后续维护成本。多数函数命名不够好，不具有自明性，但是又没有良好的注释。

上位机和下位机通信协议没有形成文档。

这个...交接给过来的文档里没有，只能从程序里反推了，好在协议不复杂，但是这种做事方式不可取，在以后自己负责的项目开发中应该避免。

下位机使用SD卡作为存储介质，但是没有将SD卡存储区域划分情况形成文档。

在项目设计初期将存储器的存储区域进行划分，并形成文档。以便后续功能的增加、存储区域的维护，项目交接。

在调试过程中碰到了一些莫名其妙的bug，因为领导给的是量产软件，所以一直怀疑自己添加的代码导致这些奇怪的bug，从而导致debug精力放在自己的代码上，增加了调试时间。最后发现是基础软件本身存在问题，才将debug范围缩小，找到了问题原因。

在以后的项目开发中，拿到一版软件，在改动之前，进行功能测试，验证软件是否存在问题。

总重量gTotalWeight定义为u16型，为了便于存储，将实际重量扩大10倍后保存，在计算输送量时，将总重量直接除以10，会导致小数位丢失，从而增大了计算误差。调试时才发现该问题，将临时总重量tempWeight定义为float类型，在计算过程中加入了强制类型转换将问题解决。

保存之后，对全局变量gTotalWeight进行清零操作，导致其他函数调用gTotalWeight时，计算结果一直为零。

在进行功能设计的时候，根据变量用途，设计好变量类型和生存周期，可以在设计流程图的时候注明一些重要的赋值和清零操作。