今天看到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移植，這才是程式子產品化靈魂所在。
至此，我的表達已經結束，謝謝。