今天看到CSDN举办了“博文大赛”，认为不错，当中有一点非常有道理：好程序猿不一定能写出好博文，但能写出好博文的一定是好程序猿。由于我认为我一直没有能把文字表达清楚。我在我的博文里也提到过，当然了。我并非一个非常好的程序猿，但我一直努力着改变自己，仅仅求每天会更好一点。
好了。不多说多余的。我想了想，选择的主题是程序模块会的见解——主要是对最近发表的程序模块会的见解总结下，和各位博友一起分享下自己的一些见解和思想。
不在乎结果，仅仅在乎能表达清晰。
总的来说，我要陈述的是关于程序模块化的四个点：
1：模块化必要性及意义
2：模块化的几个细节
3：模块化的凝视
4：模块化的移植性
一：模块化必要性及意义
在非常多时候，程序在没有理清思路的时候。我总是想到那里就写到那里，这里须要一个功能，就在这里加入一个功能，那里须要一个功能，我就在那里加入一个功能。全然没有模块会的概念。到最后，程序改动起来非常麻烦了，虽然程序是自己写的，不仅要话费非常多时间去理清思路。还得花费非常多脑力去完毕。
举个样例说。一个功能显示：LED显示，之前已经写好了LED显示相应的是档位显示。
如今须要添加一个功能。自检功能，功能是生产时候自检灯的好坏。这时，这个自检功能是加入到哪里呢？先前我会直接在显示LED的程序里写这个自检模式。结果即使不影响之前的显示效果，显示LED的程序看起来也多了非常多东西。最麻烦的是下次更改的时候。看起头非常大。因此，我认为最好的方法是，将自检模式独立写一个模块，并且，这个模块差点儿不用去动之前驱动LED显示的程序。至此。添加自检的模块差点儿完美的加入进入了，并且以后要更改。也相对easy。
所以说，模块化非常重要。写好模块既能保持原来程序的完整性，还能提高工作效率。
二：模块化的几个细节
1：致命的标志位 ——我们也许总喜欢添加一个标志位来达到改动程序的目的。然而，这往往就会存在BUG。也许会是致命的隐形BUG,所以，按我的经验来说，我建议专门写这样一个函数。我叫他ClearFlag,在这个函数，每次我添加一个标志位如F_ONOFF。我都在函数ClearFlag中写入(F_ONOFF = 0;) ，这样我们就不怕新添加的标志位了。
2：新添加模块尽量使用static 的变量。这样，下次我们看到这个模块，一下子就知道仅仅用在这里，不用思考其它的了。
3：写新的模块时，能够将已经理解好的功能宏定义在H文件里，方便下次须要时用。比方一个芯片的定时器TIM1有1分频，2分频，4分频等等，控制位2位，第3位開始，这时我们就 宏定义#define TIM1_DIV1 （0<<3）#define TIM1_DIV2 （1<<3）
4:多使用#if defined() #endif。在我们的程序模块功能越来越多的时候。有些模块是不用的。而有些编译器不会自己主动优化，这时我们仅仅要将以下#define TraWork 前面添加//就能够凝视了。此模块程序也不会占用Flash了。模块我们也可用保留在程序中。想要用的时候去掉//就能够调用了
#define TraWork
#if defined(TraWork)
//程序内容
#endif
三：模块会的凝视
写好一个好的程序不easy。改动好一个好程序更难。 调试程序中。往往会遇到这种情况，须要添加改动一个程序，这时聪明的程序猿更改了程序。好，測试也OK。就这样，把程序给封存了。这里。非常多人都会犯了一个错误，就是凝视的问题，我们发现，再过10天半个月，又来更改程序了，我们的第一感觉就是反感，呵呵。由于你可能要得又一次理解一次。也就是我们不喜欢反复的感觉。但假设你之前已经全然有凝视和提示功能更改的方向。就会添加自己的信心。或许也不会第一时间反感。为此，我觉得，凝视也是程序的重要部分，甚至比写好程序重要，而且可能花的时间要比改动程序的时间还要长，自己有时间最好，没有时间要挤出时间，把这事当作必要之事，同一时候，凝视过程。理清思路，发现BUG,总之。做好凝视，一辈子都不怕一再改动程序。
四：模块化的移植性
通过一个实例来描写叙述，函数功能非常easy：扫描LED LED的显示有不亮、闪烁、常亮 3种方式。当中闪烁次数是有规定的，我的是3次（详细是 闪烁3次。周期是0.5秒。即亮0.25秒 灭0.25秒）
F_FlsLock = 1;//启动时闪烁3次
F_FlsLock =0; F_LockEn =0;//LED不亮
F_FlsLock = 0; F_LockEn =1;//LED常亮
这是我第一次写的程序。5毫秒扫描一次。
void LedLock(void)
{
static uint8 TimeFlash = 0;//闪烁时间
static uint8 FlashTimes = 0;//闪烁次数
if(F_FlsLock)
{
if(++TimeFlash <= 50)
{
P_LED = 1;
}
else if(++TimeFlash <= (100-1))
{
P_LED = 0;
}
else
{
TimeFlash = 0;
if(++FlashTimes >= 3)
{
FlashTimes = 0;
F_FlsLock = 0;
}
}
}
else
{
if(F_LockEn)
{
P_LED = 1;
}
else
{
P_LED = 0;
}
}
}
这是我第二次写的程序，5毫秒扫描一次
void LedLock(void)
{
static uint8 TimeFlash = 0;//闪烁时间
static uint8 FlashTimes = 0;//闪烁次数
if(F_FlsLock)
{//须要闪烁
if(++TimeFlash <= 50)
{
F_LedLockEn = 0;
}
else if(++TimeFlash <= (100-1))
{
F_LedLockEn = 1;
}
else
{
TimeFlash = 0;
if(++FlashTimes >= 3)
{
FlashTimes = 0;
F_FlsLock = 0;
}
}
}
else
{
F_LedLockEn = F_LockEn;
}
}
//
if(F_LedLockEn)
{
P_LED = 1;
}
else
{
P_LED = 0;
}
表面能够看出。第2次的程序比第一次多了I个标志位F_LedLockEn 。
更深一点：假设这两个程序的移植性是那个好呢？这就是我主要说的，假设这两个程序都用在一个同样的驱动电路，即VDD-LED-电阻-GND,那么就没有什么差别。
但假设用在复用。即按键和LED共用一个IO或者LED共用COM,这时功能同样，LED驱动更改肯定要的，但推断是否显示和闪烁是时间和次数能够不改。对此，假设是第一个程序。那得大改了。哈哈。那又得浪费时间和脑力了。但第二个程序，能够应用多种电路接线方式，仅仅须要更改LED驱动方式，再通过F_LedLockEn来确定是否亮与不亮就可以。这里能够看出。推断LED是否亮的模块和LED驱动模块全然区分开，这样。两个模块就能够单独移植和改动却不相互影响。
我们不是要做到这种吗？
我说得可能还是有些欠缺。但总之。程序的模块化要做到，即使我们到了100岁，我也不怕改动。也能非常easy移植，这才是程序模块化灵魂所在。
至此，我的表达已经结束，谢谢。