[20060427發(fā)表于blog.csdn.net，20090929重新編輯]

重新編輯注釋：這是我上上家公司的離職總結(jié)，一些技術(shù)，幾年沒碰，現(xiàn)在都忘了，我感覺當(dāng)時(shí)我的水平跟現(xiàn)在已經(jīng)差不多了，難道說這幾年都沒什么進(jìn)步？特別是這一年多時(shí)間，我怎么感覺自己心態(tài)變老很明顯。文章中描述的一些問題到現(xiàn)在已經(jīng)得到了比較好的解決，有些卻依然存在，如果各位道友有什么見解，不妨拿出來分享一下。（BTW：當(dāng)時(shí)公司主要是做一些小型網(wǎng)絡(luò)游戲，棋牌類的，從文中能看得出來。）

對近日來一些問題進(jìn)行思考，希望能有個(gè)解決方案。
 
1、數(shù)據(jù)庫方面

每個(gè)項(xiàng)目都離不開數(shù)據(jù)庫，而數(shù)據(jù)庫的建立過程是個(gè)問題，如何將我們的開發(fā)成果移動到運(yùn)營環(huán)境中是個(gè)問題，如何維護(hù)以后的更新更加是個(gè)問題，所有的東西都看起來是那么簡單而缺乏技術(shù)含量，但真的嘗試把它做好卻是非常不容易，人工手動來維護(hù)這些文檔是可以的，但恐怕這是一個(gè)專門的工作，如果干這個(gè)的人還同時(shí)做別的事情，總會無法避免地出現(xiàn)疏漏，我想一定需要借助工具了，而與這些工具的磨合，也是個(gè)不小的成本。

1）往往忘記寫修改履歷，不知道哪個(gè)是新的，哪個(gè)是舊的
通病了，希望修改履歷都別忘了寫，包括修改日期、作者和內(nèi)容，這樣就不至于到出了問題找人負(fù)責(zé)的時(shí)候手忙腳亂，至于用CVS來管理怎樣，我沒經(jīng)驗(yàn)。

2）多個(gè)人同時(shí)直接修改數(shù)據(jù)庫，管理這個(gè)的人很痛苦
沒有好的解決方案。用CVS來維護(hù)如何？

3）Oracle 9i開發(fā)出的程序不一定能在Oracle 8i上使用
千萬別使用高版本的開發(fā)環(huán)境和低版本的運(yùn)營環(huán)境，理想情況是一樣的環(huán)境，不行的話反過來用低版本的開發(fā)環(huán)境和高版本的運(yùn)營環(huán)境也可以。切記，產(chǎn)品的成功不在于開發(fā)它的工具是高級還是低級。

由于版本不一致，原先設(shè)計(jì)好的注釋到新的環(huán)境就變成了問號，不堪忍受

4）外鍵約束使用不當(dāng)導(dǎo)致很多問題
外鍵約束很大程度上保證了數(shù)據(jù)的完整性，但世界上所有的事情都是一分為二的，在我們開發(fā)過程中，外鍵約束往往約束的是我們而不是數(shù)據(jù)，當(dāng)我們需要添加一行測試數(shù)據(jù)的時(shí)候，當(dāng)我們需要修改一個(gè)字段屬性的時(shí)候，當(dāng)我們需要更新一個(gè)單元格的時(shí)候……到最后，我發(fā)現(xiàn)我們的項(xiàng)目去處了很多外鍵約束，最后的成果和設(shè)計(jì)相去甚遠(yuǎn)了。對于小型項(xiàng)目，很多時(shí)候沒必要使用外鍵約束，當(dāng)你確定真的需要使用的時(shí)候，仔細(xì)思考，它真的合理嗎？

5）冗余與效率問題
總結(jié)過程中我發(fā)現(xiàn)了一些數(shù)據(jù)冗余，這是很正常的，比如一個(gè)用戶表中包括了用戶性別、出生日期和身份證號碼，其實(shí)這就是冗余，因?yàn)槲覀兺耆梢酝ㄟ^身份證號碼來確定用戶性別和出生日期，但這種冗余是必要的。一定的冗余能提高我們的效率，我們往往需要在冗余與效率之間選擇一個(gè)平衡點(diǎn)。參考數(shù)據(jù)庫三范式。

6）命名問題
表面上看又是一個(gè)沒有技術(shù)含量的小問題，其實(shí)是最令我頭疼的問題之一，一張user表中，出現(xiàn)了多個(gè)“state”，state表示一種狀態(tài)，每個(gè)用戶有若干種狀態(tài)，很正常，我稍微列一下我能看到的：super_assistant_state、login_state、multi_user_state、forbidden_state、lock_state、score_lock_state……如果和別的表關(guān)聯(lián)起來，恐怕還有更多的state，這些state如果命名得不好，往往容易引起誤會，比如lock_state和forbidden_state，兩個(gè)都表示對用戶的限制，如果注釋中沒有進(jìn)一步詳細(xì)的說明，誰又會知道那么多呢？

7）類型混亂的問題
字段的類型有時(shí)候看起來確實(shí)混亂，比如什么時(shí)候用integer，什么時(shí)候用number，我想這絕對不是隨意的，至于number究竟有多長，最長可以指定多長？誰研究過呢？integer和C++中32位的int類型有什么異同嗎？而long類型和C++的long是一樣的嗎？字符串到底用char、varchar還是varchar2？我想需要進(jìn)一步研究。

8）過于復(fù)雜的單句SQL語句
Oracle的功能是很強(qiáng)大的，幾乎支持所有的SQL風(fēng)格，當(dāng)然包括了復(fù)雜的聯(lián)合查詢和子查詢，但過于龐大的select語句使后來的維護(hù)者感覺非常費(fèi)勁，一個(gè)語句往往需要閱讀很長時(shí)間，而且根據(jù)我的經(jīng)驗(yàn)，調(diào)試時(shí)候出問題多的存儲過程就是包含了這些復(fù)雜SQL語句的存儲過程，我們有辦法將它簡化嗎？如果不能簡化，務(wù)必謹(jǐn)慎，測試測試再測試，確保其正確性，然后添加清晰的注釋。

2、應(yīng)用程序方面

應(yīng)用程序的問題主要還是集中在版本的控制上，包括消息頭文件的版本，運(yùn)營與維護(hù)的不同版本程序，測試與發(fā)行的不同版本。當(dāng)然還有別的問題，不一定是技術(shù)上的原因了，使得后來做出來的成品和原先設(shè)計(jì)的相差很大，很多設(shè)計(jì)文檔實(shí)際上已經(jīng)廢棄，加大了以后維護(hù)的難度。

1）common_lib的放置
common_lib是我們使用的一套公共類庫（與之類似的還有aeslib），主要的功能是網(wǎng)絡(luò)通信、寫log、hash表和隊(duì)列等。幾乎所有的程序都用到了這些功能，不考慮common_lib本身版本上的差距，我們有不同的使用方法，以Linux環(huán)境開發(fā)為例，一種是把common_lib與項(xiàng)目分離，放置在$(HOME)目錄下，而在make文件中也指定了“$(HOME)/common_lib”的搜索路徑；另一種是把common_lib放置在項(xiàng)目目錄中，make文件指定的路徑可能是“../common_lib”。前一種方法有可能把項(xiàng)目從一臺機(jī)器移動到另一臺機(jī)器（或從一個(gè)賬號移動到另一個(gè)帳號）的時(shí)候發(fā)現(xiàn)common_lib找不到的情況，因?yàn)?#8220;$(HOME)/common_lib”不一定有嘛；后一種方法有可能會將common_lib所作的一些額外更改忽略掉，它用的還是自己的庫。但考慮到common_lib趨于穩(wěn)定，因此我們盡量使用后一種方法，程序能正確，穩(wěn)定地運(yùn)行就是我們的追求了，最新的代碼并不是必須的。另外，使用common_lib的同時(shí)，我們也通常會用到aeslib，我覺得是不是將它們合并起來更好呢？

2）程序中的錯(cuò)別字
這是個(gè)不重要又重要的問題，也許大家都默認(rèn)之后不會覺得有什么不妥，但站在用戶的角度，會不會覺得開發(fā)人員水平很差呢？我列舉一下常見錯(cuò)誤（括號內(nèi)是正確用法）：登陸（登錄）、Acount（Account）、超連接（超鏈接）、Sucess（Success）。

3）數(shù)據(jù)庫？配置文件？寫死？
我們可能需要修改一些程序運(yùn)行的參數(shù)，比如開分最大金額、心跳時(shí)間、最大連接客戶端數(shù)目……等等。這些參數(shù)的改變究竟如何實(shí)現(xiàn)？我觀察了下程序，普遍有三種情況，一是將參數(shù)存放在數(shù)據(jù)庫中（可以在運(yùn)行中生效），二是寫配置文件（重新啟動程序生效），三是寫死在程序中（需要重新編譯程序，再運(yùn)行方生效）。這個(gè)除了看需要外，我還想提些建議：
1、如果需要網(wǎng)頁方面控制，只能使用數(shù)據(jù)庫了；
2、只要以后有可能需要修改就不要寫死在程序中，要知道，編譯的環(huán)境不是哪里都有，就算有也不是什么人都會，況且代碼是保密的；
3、對于較多的批量配置數(shù)據(jù)，盡量使用數(shù)據(jù)庫；
4、程序初始化的配置數(shù)據(jù)使用配置文件通常更為恰當(dāng)，因?yàn)槌跏蓟弥巴鶡o法訪問數(shù)據(jù)庫嘛。
最后，貪方便把東西都寫死是不負(fù)責(zé)任的表現(xiàn)，結(jié)果往往帶來很多不方便。

4）版本依然混亂
我經(jīng)常說的一句話是：“XXX，請把YYY的最新版本代碼，給我一份。”或者說：“XXX，你這個(gè)是最新版本嗎？最近一次改了什么內(nèi)容？”其實(shí)老說這句話我都覺得丟臉，做了這么久開發(fā)，版本控制問題還是搞不好，不排除制度和開發(fā)模式上也有些問題，但考慮到自己有時(shí)候都不能很好執(zhí)行，就不用怪別人了。通常表現(xiàn)為：
1、修改隨意，常常忽略修改標(biāo)識，無日期，無內(nèi)容，改錯(cuò)了回頭再尋找困難；
2、經(jīng)常忘記CVS檢入前先同步一次，導(dǎo)致內(nèi)容混亂；
3、責(zé)任不明確，程序到底誰在負(fù)責(zé)??？比如有人離開了公司，他的代碼究竟誰來管？
4、舊版本經(jīng)常不留備份，修改過程無蹤跡可尋（CVS可能經(jīng)歷很多修改才檢入一次）。

5）目錄結(jié)構(gòu)安排
一個(gè)工程，安排怎樣的目錄結(jié)構(gòu)？單個(gè)目錄？或者許多？我想這應(yīng)該不是隨意的，我認(rèn)為通?？梢赃@樣：將公共模塊放置一個(gè)目錄，將類庫（比如數(shù)據(jù)庫操作的類庫，圖形類庫，加密狗類庫）放置各自的目錄，剩下自己編寫的代碼放一個(gè)目錄即可，但如果自己寫的代碼模塊獨(dú)立性強(qiáng)，也可以考慮把他們分開，以便以后的復(fù)用。還有就是bin目錄的建立，現(xiàn)在想想還是有必要的，將生成的可執(zhí)行文件放置bin目錄下（VC++自己有debug目錄和release目錄就另外講了），配置文件也放置bin目錄下，發(fā)布時(shí)候只需要發(fā)布bin目錄嘛，我們通常寫log，log目錄呢？我認(rèn)為放置在bin目錄下，這樣發(fā)布的時(shí)候也沒忘記帶上log目錄，當(dāng)然啦，要先將里面的log文件清空。

6）系統(tǒng)設(shè)計(jì)的問題
在做概要設(shè)計(jì)的時(shí)候，我們往往有很多不錯(cuò)的想法，比如構(gòu)建一個(gè)比較完美的游戲平臺，以后只需要在平臺上添加各種不同的游戲即可，這樣就產(chǎn)生了對應(yīng)的不同數(shù)據(jù)庫，平臺自身一個(gè)數(shù)據(jù)庫，每個(gè)游戲都有自己的數(shù)據(jù)庫，理論上沒問題，實(shí)際操作起來問題就大了。先是web方面根本沒考慮過這種情況，只設(shè)計(jì)了一個(gè)數(shù)據(jù)庫連接，之后重新添加了新的數(shù)據(jù)庫連接，但可擴(kuò)充性恐怕就不好了，遠(yuǎn)沒達(dá)到我們期預(yù)的效果，再就是控制管理部分程序權(quán)力過大，或者說設(shè)計(jì)不合理，往往逾越了平臺和具體游戲之間的鴻溝，進(jìn)一步加強(qiáng)了偶合，使平臺和游戲越發(fā)不可分離，擴(kuò)展性更差，最后做出來的產(chǎn)品已經(jīng)很難把平臺和游戲區(qū)別開來了，一個(gè)平臺就是一個(gè)游戲，一個(gè)游戲包括一個(gè)平臺。

7）考慮上的疏漏
舉個(gè)例子吧，我們在實(shí)際操作中需要?jiǎng)?chuàng)建新的服務(wù)器，但發(fā)現(xiàn)不成功，查原因，發(fā)現(xiàn)是因?yàn)閿?shù)據(jù)庫里需要添加新的服務(wù)器的條目才可以，添加條目是web的功能，結(jié)果發(fā)現(xiàn)web沒做好，等web補(bǔ)上了，條目添加了，發(fā)現(xiàn)還是不行，因?yàn)榉?wù)器的運(yùn)行需要數(shù)據(jù)庫的很多信息參數(shù)，而這些參數(shù)目前都沒有在添加條目的時(shí)候被添加，由于這次web的工作量較大，一時(shí)改不好，只能手動在數(shù)據(jù)庫里添加，一張表添加的條目可能有數(shù)十條，相當(dāng)繁瑣，稍微不留神就可能出錯(cuò)?？紤]上的疏漏可能會伴隨我們一生，但每一點(diǎn)一滴都是寶貴的經(jīng)驗(yàn)，起碼我們不能再犯同樣的錯(cuò)誤。

8）log文件處理
程序離不開log，按照我們的做法，每天產(chǎn)生一個(gè)log文件，時(shí)間一長，log文件就越來越多，占用空間越來越大，我想我們應(yīng)該改進(jìn)一下，比如每天自動刪除3個(gè)月以前的log。

一天加一天，log泛濫成災(zāi):)

9）exit的使用
程序碰到異常情況我們通常喜歡用exit()來結(jié)束程序的運(yùn)行，在單線程中這樣做是沒問題的，但到了多線程則未必，根據(jù)我的經(jīng)驗(yàn)，濫用exit()很容易導(dǎo)致程序結(jié)束的時(shí)候出現(xiàn)“非法操作”，甚至數(shù)據(jù)庫寫入不完整。下面是我認(rèn)為的以后的做法（不一定很正確）：只有主線程能調(diào)用exit()，其它線程運(yùn)行遇到致命錯(cuò)誤后返回錯(cuò)誤值，一層層往上返回，直至主線程，（或者將致命錯(cuò)誤消息發(fā)至主線程）由主線程調(diào)用exit()。當(dāng)然主線程也可以完全不用exit()，我更偏向于能不用就不用，因?yàn)閑xit()會不分黑紅皂白強(qiáng)制結(jié)束程序，它不能讓對象正常釋構(gòu)，另外它有類似goto語句，破壞程序的結(jié)構(gòu)化，使程序條理變得不清晰。

10）多線程中MsgBox的問題
測試/維護(hù)過程中發(fā)現(xiàn)過一些很奇怪的現(xiàn)象，程序莫名其妙地到了其它電腦就出現(xiàn)“非法操作”，后究其原因發(fā)現(xiàn)是使用MsgBox（這里通指消息框）的問題，該調(diào)用會彈出對話框請求用戶確定取消等，或者僅僅將一些消息反映給用戶。在多線程中使用MsgBox我認(rèn)為存在隱患，一方面是開發(fā)工具的問題，MsgBox在C++ Builder中的實(shí)現(xiàn)和WINAPI的MessageBox是不一樣的；另一方面MsgBox并不能每時(shí)每刻都能工作得很好，我就發(fā)現(xiàn)過多線程程序中C++ Builder的MsgBox不起作用的情況；再一方面MsgBox會對線程造成堵塞，如果讓邏輯處理線程直接調(diào)用MsgBox則可能導(dǎo)致一些沒有預(yù)料到的情況發(fā)生。我認(rèn)為，MsgBox和用戶界面相關(guān)，盡量只在主線程中調(diào)用。

這種MsgBox恐怕難以令人接受

3、文檔方面

這里指的文檔包括了各種設(shè)計(jì)文檔、配置文件、說明書及程序注釋，是程序可維護(hù)性的重要依據(jù)，但往往容易被忽略，它不能影響程序的性能，但我覺得從現(xiàn)在的角度來說，一個(gè)程序的可維護(hù)性往往比性能更重要。

1）配置文件的問題
到底把配置文件放入CVS呢還是不放呢？都各有道理，放的話檢出中有這個(gè)文件，用戶知道去修改，但如果一個(gè)用戶修改了配置文件并檢入，然后另一個(gè)用戶更新，那另一個(gè)用戶的配置文件也跟著被改動了，可能導(dǎo)致錯(cuò)誤；如果不放，那用戶第一次檢出時(shí)候沒有這個(gè)配置文件，無法運(yùn)行程序，但獲得這個(gè)文件后不會因?yàn)橹蟮母露鴮?dǎo)致文件被修改。我看還是不放的好，不經(jīng)意地被改動配置文件是件很郁悶的事情，寧愿找不到配置文件自己另外去找一個(gè)。但有沒有其它更完美的辦法？

2）安裝配置說明的問題
我第一次把我認(rèn)為不錯(cuò)的安裝說明交給測試部讓他們?nèi)?zhí)行的時(shí)候，我說：“盡量參照說明，不要問我，看看是否能按部就班完成。”結(jié)果是很令人沮喪的，一天跑來問我許多次，因?yàn)閷?shí)在不知道下一步怎么弄，或是出了些意外。當(dāng)然不排除是因?yàn)長inux易用性差的緣故，但無論怎么說，我的說明文檔也十分糟糕，我一直在想怎么才能寫出合格的說明文檔呢？我想應(yīng)該寫好之后，把自己當(dāng)成一個(gè)用戶，嘗試按說明去操作一遍，這是最起碼的了。當(dāng)然要寫得好，真不亞于程序設(shè)計(jì)的難度，你考慮過意外出錯(cuò)嗎？還有各種你看起來平常的術(shù)語用戶是否就清楚？仔細(xì)仔細(xì)再仔細(xì)，難道說明真的很完美，沒有任何錯(cuò)誤了嗎？我沒有進(jìn)一步的解決，只有苦功，在此提一下這其實(shí)并不簡單，僅此而已。

3）說明書的問題
先參考一下上面所說的安裝配置說明的問題，是否存在，還有就是以下的一些問題了：1、格式不統(tǒng)一，章節(jié)不對齊；2、圖片過大，調(diào)整后模糊，影響閱讀；3、內(nèi)容混亂，針對性不強(qiáng)，到底是一個(gè)針對網(wǎng)絡(luò)管理員的說明書，還是針對一個(gè)普通用戶的說明書？我想內(nèi)容肯定相差很大。