“今天早上陽光明媚啊，”老C在教研室門口深呼吸。
“嗯，東花園顯得很漂亮啊……”小P應聲道，兩人走過東花園，來到教研室，準備妥當后，坐在小P桌前。
“好，我們今天先不評論你的代碼內容，而是重新來寫這個代碼。”老C不好意思說小P的代碼太爛以至于無法評審，所以決定另起爐灶，“然后我們拿新寫的這個版本與原來的版本做比較。”
“也好。”小P同意。
“這樣，我們兩個來一起寫這個代碼，這樣更快一些。”老C道。
“好啊好啊。”
兩人新建了一個名叫AppleGame的工程，然后老C添加了一個main.c的文件，“本來在這里應當使用配置管理工具的，但是因為簡單起見，我們就土
法煉鋼，采用拷貝的方法記錄版本吧。”老C一邊說一邊在硬盤上建立了一個新目錄，起名為AppleGame_V0.01，“名字也隨便起了，不用使用
VBD等等復雜的規范，但是你千萬注意這只是例子，以后千萬不要隨便學啊。”老C解釋道，“至于什么配置管理和版本命名規范，我們以后再說。”
“槑……”小P有些暈，下意識的回答道。
“我們的做法在一般面試、筆試的時候可千萬不要用，完全是大炮打蚊子……在這里出現只是為了演示，然而如果你熟悉了這樣的開發過程，再反過來使用更直接的方法應付面試和筆試還是比較容易的，”老C又補充道，“大炮一響，黃金萬兩……有時打打大炮也是有價值的，起碼熟悉了開炮過程，這樣以后用大炮打黃金就駕輕就熟了……”
“……”小P決定無視老C的自言自語，心想人上了年紀就是有些羅嗦。
“好，第一個任務，寫一個main函數。”
“這個簡單。”小P應道。在文件上敲下幾行代碼。
void main()
{
}
“唉，這樣是有問題滴……”老C說到。
“什么問題？”
“規范……”老C回答，“我們應當這樣寫。”老C開始更改小P的代碼。
int main()
{
return 0;
}
int main(int argc, char* argv[])
{
return 0;
}
“我們兩個中間選一個，因為這個程序沒有命令支持，所以就第一個吧。”老C說到，“這個是C99的新標準，我們還是按照標準來吧。”老C補充道，“你可以
在學校圖書館查查《ISO/IEC 9899 :
1999》這個文檔，里面說的很清楚。如果我們還使用原來的格式，可能在代碼兼容性上會出問題，我們寫出的代碼就不能在所有編譯器上編譯通過……”
“是么？這么復雜……”小P有些疑惑，“好吧，那么就這樣吧。”
“那么現在說說你解決這道題的思路吧。”老C問。
“嗯，先設計一個循環隊列，每個隊列中的元素表示一個小朋友，1表示在對列中，0表示他不在對列中，然后開始按照規則玩游戲，直到剩下最后一個小朋友，然后在隊列中找出這個剩下的元素，打印它的下標……就是座位號碼啦……”
“嗯，思路還算清晰，”老C評論，“我們姑且不論選擇循環隊列是否合適，就先按照這個思路來做，等到后面再評審更改吧。”然后他在文件中添加如下的語句。
int main()
{
/* Initialize the queue. */
/* Play the game, until the last one is found. */
/* Search the last one's seat number. */
return 0;
}
“好了，我們的第一版程序完成了。”老C拍拍手。
“完了？”小P有些不敢相信。
“是啊，”老C確定的說，“編程不只是寫代碼，代碼 != 程序！當你開始進行思考的時候，就開始進行程序設計了，代碼不過是程序的表達方式。如果人類的語言可以在計算機上執行，你剛才說的話，就是代碼。是不是這樣？”
“嗯，有些道理……”
“編譯！好了，我們的第一版程序沒有什么問題！”老C說完，將main.c文件拷貝到AppleGame_V0.01文件夾下面，然后又新建了一個AppleGame_V0.02的文件夾。
“下來我們需要一個調試宏，”老P說到，“本來可以使用IDE為我們準備的debug和release編譯選項，但是這里我們先不用，為了明白背后的道理，我們完全自己打造一個先。關于debug和release，我們以后再說。”
“哦……”小P點點頭。
老C在main.c的開頭寫下如下代碼。
#include <stdio.h>
#define PRINT_DEBUG_INFO
#if defined(PRINT_DEBUG_INFO)
#define MY_DEBUG(str) printf(str)
#define MY_DEBUG_1(str, par) printf(str, par)
#else
#define MY_DEBUG(str)
#define MY_DEBUG_1(str, par)
#endif // PRINT_DEBUG_INFO
“這幾個宏用于在調試的時候輸出一些中間信息，”老C解釋道，“如果我們想輸出調試信息，只需要#define PRINT_DEBUG_INFO就可以了，否則就注釋掉這個宏。這只是一些小技巧而已，沒有什么神秘的。”
“是嗎？嗯，我看看……”小P琢磨著代碼。
“下來進行一些實質性的，”老C接著說，“但是之前我們要了解一個規則，用
問題域的詞匯去編程，而不是解決域。”
“槑，什么叫問題域？解決域？”小P不解。
“我寫你看好了。”老C說道，然后在main.c文件中接下來的部分寫下如下內容。
//////////////////////////////////////////////////////////////////////////
//
#define CHILDREN_NUM 20U
typedef int SEAT_NUM;
typedef enum tagEXIST_STATE { ABSENT, EXISTED } EXIST_STATE;
typedef struct tagCHILD
{
SEAT_NUM seatNum_;
EXIST_STATE existState_;
}CHILD;
#define QUEUE_LENGTH CHILDREN_NUM
typedef CHILD QUEUE_CONTENT;
typedef struct tagQUEUE
{
int size_;
int index_;
QUEUE_CONTENT queue_[QUEUE_LENGTH];
}QUEUE;
typedef struct tagAPPLE_GAME
{
int currCountNum_;
int childrenRemained_;
QUEUE childrenQueue_;
}APPLE_GAME;
void InitAppleGame (APPLE_GAME* game);
int IsGameOver (APPLE_GAME* game);
void PlayGame (APPLE_GAME* game);
int LastChildSeatNum (APPLE_GAME* game);
//////////////////////////////////////////////////////////////////////////
//
int main()
{
APPLE_GAME theGame;
int num;
/* Initialize the game. */
InitAppleGame(&theGame);
/* Play the game, until the last child is found. */
while (!IsGameOver(&theGame))
{
PlayGame(&theGame);
}
/* Search the last child's seat number. */
num = LastChildSeatNum(&theGame);
printf("The last child's seat number is %d.\n", num);
return 0;
}
//////////////////////////////////////////////////////////////////////////
//
void InitAppleGame(APPLE_GAME* game)
{
MY_DEBUG("Init the apple game.\n");
}
int IsGameOver(APPLE_GAME* game)
{
static int n = -1;
MY_DEBUG("Only one child?\n");
++n;
return n;
}
void PlayGame(APPLE_GAME* game)
{
MY_DEBUG("Play game...\n");
}
int LastChildSeatNum(APPLE_GAME* game)
{
int n = 1;
MY_DEBUG("Searching last child's seat number\n");
return n;
}
“喏，就是這個意思，盡量用現實生活的語言對需要解決的問題進行描述，并將關系相近的變量用結構體放在一起。”老C說，“然后將對這些名詞的操作寫成可以
用現實生活語言表達的函數，并將結構體作為函數的入口參數傳入函數中。”老C咽了一口唾沫，“咳咳，你再比較比較我們這兩版的注釋有什么變化？”
“叫我看看……”小P開始比較代碼，“哦，在這個版本你用 game 代替了 queue，用 child 代替了 one， 但是有什么實質區別？”小P有些不解。
“嗯，這個是一個用問題域詞匯編程而不是解決域詞匯編程的例子，最大的優點是意圖明確，容易理解，代碼可讀性強；另外一個好處是相對穩定——比如用
game 代替
queue——其一，評審代碼的人可能會不明白這個queue是做什么的，為什么和下面的初始化函數格格不入，從而造成你頻繁的回答大量的溝通性的問題，
這將大大影響你生活的穩定性和質量；其二，如果我們將來——我是說如果——使用list數據結構來替換queue，避免了還要更改注釋的風險——代碼更新
而注釋陳舊，正是我們在進行項目開發時一個特別特別特別的n次冪嚴重的問題……而使用問題域的詞匯，只要需求不發生變更，則我們就不需要修改什么而導致一
些……代碼人格上的分裂……”
“哦，我再消化消化……”小P開始看代碼，“下面這些函數的實現是什么意思？”
“嗯，是測試，”老C說，“我們先不看具體函數，先看看main()函數的主要結構。”
int main()
{
APPLE_GAME theGame;
int num;
/* Initialize the game. */
InitAppleGame(&theGame);
/* Play the game, until the last child is found. */
while (!IsGameOver(&theGame))
{
PlayGame(&theGame);
}
/* Search the last child's seat number. */
num = LastChildSeatNum(&theGame);
printf("The last child's seat number is %d.\n", num);
return 0;
}
“我們用實際的代碼完善剛才的注釋——剛才的注釋其實就是偽代碼的一部分——然后在框架函數中加入測試代碼，檢驗我們的算法是否可行。”老C解釋道，“現在我們的算法一目了然，你看看是否是用問題域的詞匯表達算法更清晰一些呢？比一些a,b,c之類，或者其類似的解決域內的名字更好理解吧？”
“哦，我再看看……”小P答道，“我要消化一下……”
“嗯，”等小P抬起頭，老C補充道，“接下來一個重要的規則是
先構思如何測試，更先于編碼！”
“稍等，”可能被新的信息灌輸的有些頭暈，“這個是什么意思？”小P有些反應不過來。
“就是說，在編碼之前，我們要先想好如何測試我們即將要編寫出來的代碼。我們的代碼是否易于被測試，關系到我們代碼質量的生命！”老C解釋道，“如果你一
開始就考慮到這些問題，并留有充分的余地，那么在做代碼自測和測試人員測試時，會節省組織內部大量的精力……算了，這些也是要靠編寫代碼的規模積累起來的
經驗，你以后會慢慢的明白的。但是，無論如何你在編寫代碼的時候要保持足夠的意識，要不斷提醒自己，我所寫的代碼易于測試嗎？”
“好，我記住了。”小P說。
“呵呵，其實經歷了一些挫折你才會真正明白——不過就算建立了概念也不錯。”老C笑道，“現在你編譯并運行一下代碼吧，觀察一下屏幕輸出的信息……”
“好，”小P看了看文件底部的函數實現，然后又看了看屏幕輸出信息，“哦，算法的脈絡這樣看就比較清楚了，果然我腦海中就是這么想的，不過現在更具體，也好追蹤了。”
“O.K.！我們第二版的程序又有了！”
“這么快？為什么？”小P不解道。
“我們驗證了算法，證實算法框架運行與設計——就是你腦海中的步驟——是一致的，這樣當然ok了！”老C一邊說一邊將main.c拷貝到
AppleGame_V0.02，并且又新建了一個AppleGame_V0.03目錄。
(請等待V0.03版本)