程序模块化的阶段性总结

      今天看到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移植，这才是程序模块化灵魂所在。

            至此，我的表达已经结束，谢谢。