在編程時(shí)應(yīng)該注意哪些問題？有什么誤區(qū)？

在編程時(shí)應(yīng)該注意哪些問題？我們很少看到有人公開談?wù)撟约旱腻e(cuò)誤。人非圣賢，孰能無過？雖然難言出口，但反思過去所犯的錯(cuò)誤可以讓人不會(huì)在未來——至少是短期的未來，犯同樣的錯(cuò)誤。下面我們就來看看編程的常見問題。

在編程時(shí)應(yīng)該注意哪些誤區(qū)？

1、沒有使用合適的ORM

數(shù)據(jù)訪問層代碼總是混亂、乏味和無聊的。不幸的是，往往這點(diǎn)到最后才能發(fā)現(xiàn)。

Mohamed和ORM有著一段孽緣。ORM，即Object Relational Mapping，它是對(duì)象關(guān)系模型的簡稱。它的作用是在關(guān)系型數(shù)據(jù)庫和對(duì)象之間作一個(gè)映射，使程序能夠通過操縱描述對(duì)象方式來操縱數(shù)據(jù)庫。

當(dāng)Mohamed第一次做一個(gè)簡單的內(nèi)部會(huì)計(jì)應(yīng)用程序時(shí)，他發(fā)現(xiàn)只是為了完成基本的程序，就不得不編寫大量的代碼。于是他開始埋頭于ADO.NET，并手動(dòng)編寫了一個(gè)自制的、具有非常特殊的、自定義的表模式的ORM，來滿足目的。

在一段時(shí)間里，這個(gè)ORM工作的相當(dāng)不錯(cuò)，直到幾個(gè)月后，公司的業(yè)務(wù)需求發(fā)生了一些變化，這導(dǎo)致了整個(gè)表格模式的變化，然后，就是對(duì)ORM的反復(fù)修改。這個(gè)流程的痛苦之極，讓Mohamed最終選擇了強(qiáng)類型數(shù)據(jù)集適配器。

雖然這件事因此解決，但如果能找到一個(gè)更合適的ORM(比如NHibernate)來完成工作，Mohamed仍會(huì)義不容辭，至少當(dāng)他的用戶數(shù)量增加時(shí)，不必?fù)?dān)心更改數(shù)據(jù)庫的供應(yīng)商。

2、沒有學(xué)會(huì)使用泛型

Mohamed Barouma的職業(yè)程序員生涯始于Net 1.1。而在當(dāng)時(shí)，Net 1.1的主要問題在于它沒有泛型支持，這代表它不能有一個(gè)強(qiáng)類型列表，只能滿足于乏味的ArrayList。但是使用Arraylist在Java代碼中進(jìn)行類型轉(zhuǎn)換和裝箱，會(huì)導(dǎo)致讀寫起來十分痛苦。

因此，Net 1.1的程序員們使用CodeSmith生成一個(gè)強(qiáng)類型集合列表。

但隨著代碼庫的增長，那些定制生成的列表本身就變成了一個(gè)無法收拾的怪物。只要經(jīng)常為了創(chuàng)建對(duì)象或調(diào)用方法去達(dá)到目的，隨后就會(huì)因?yàn)樾薷拇a導(dǎo)致混亂和錯(cuò)誤。

如果切換到Net 2.0，并在它可用時(shí)立即開始使用泛型，而不是創(chuàng)建越來越多的難以維護(hù)的自定義集合列表，那么一切問題都將迎刃而解。

3、沒有放棄“造輪子”

這是個(gè)老生常談的話題，“反復(fù)造輪子”（Reinvent The Wheel）。新程序員總是喜歡反復(fù)“造輪子”，自認(rèn)為當(dāng)前的實(shí)現(xiàn)不夠好，所以不得不從頭重寫整個(gè)東西。

為什么叫“造輪子”？就像真正的的輪子早在幾千年前就被確定是圓形的一樣，很多數(shù)據(jù)庫也早就已經(jīng)成熟易用了，但還是有數(shù)不勝數(shù)的程序員們鍥而不舍的去“造輪子”，有的人飛蛾撲火、蚍蜉撼樹，有的人別具一格、推陳出新，這就是“造輪子”魔法一般的吸引力。

這其中也不乏Mohamed，他想重新編寫自己的UI控件，因?yàn)閃indows Forms UI控件實(shí)在是太簡單了。最后，他造的GUI工具被商業(yè)化成體系的.Net UI控件輕松打敗，又一輛新生程序員造的“輪子”被擊沉到了代碼海洋里。

4、沒有精簡過多的文檔

很多剛?cè)胄械某绦騿T，會(huì)在一開始覺得代碼文檔很好，因?yàn)樗煤唵蔚挠⒄Z注釋了代碼在做什么。但事實(shí)上這些文檔通常在修改了幾次代碼之后變成了一攤廢紙，變得陳舊、過時(shí)亦或是完全錯(cuò)誤。

常常有人花了很多時(shí)間編寫代碼文檔——比如XML文檔，結(jié)果發(fā)現(xiàn)在更改代碼時(shí)需要更新文檔。因?yàn)樗墓δ芸赡芏家呀?jīng)改變了。更新代碼是必須的，但更新XML文檔不是必須的：這是一種負(fù)擔(dān)，它消耗時(shí)間，而且毫無用處。

最終，反復(fù)地更改XML文檔使人逐漸失去耐心，轉(zhuǎn)而做其他事情。

5、沒有使用自動(dòng)化構(gòu)建

應(yīng)用程序的部署和打包比編程相對(duì)容易，所以它往往被放在了非常低的優(yōu)先級(jí)上。但很快，粗制濫造的構(gòu)建就會(huì)因?yàn)闊o法工作，受到各式各樣的投訴：

“先決條件缺失，該如何修復(fù)？”

“dll沒有更新，你能給我一個(gè)補(bǔ)丁嗎？”

“我的圖標(biāo)怎么不見了？”

緊接著，電話像雪崩一樣源源不斷地打到桌旁。這是Mohamed的真實(shí)經(jīng)歷，并讓他那天精疲力盡——不是因?yàn)榫幊蹋且驗(yàn)榱钊寺槟镜闹匦虏渴鸷椭匦掳b過程。

而這一切，本可以通過編寫自動(dòng)化腳本節(jié)省一些時(shí)間，否則在事后debug浪費(fèi)的時(shí)間絕對(duì)比可以節(jié)省的時(shí)間多上數(shù)倍。應(yīng)該讓軟件可以一鍵構(gòu)建，否則再多都是一種浪費(fèi)。

6、沒有停止對(duì)視覺檢測(cè)和debug的依賴

Visual Studio讓人們可以很容易地調(diào)試代碼并進(jìn)行動(dòng)態(tài)檢查，這也使得創(chuàng)建一個(gè)表單并顯示輸出非常簡單。但如果太沉迷于調(diào)試器，這項(xiàng)好處就要變成壞處了。

為什么呢？想象一下，如果一個(gè)方法只在應(yīng)用程序啟動(dòng)并運(yùn)行45分鐘后才被調(diào)用，那難道要打算等45分鐘再開始調(diào)試嗎?

所以，動(dòng)動(dòng)手將應(yīng)用程序分解為可以獨(dú)立調(diào)用的子模塊，這樣就可以準(zhǔn)備產(chǎn)生錯(cuò)誤輸出的輸入值，并從那里開始測(cè)試它。

7、沒有做單元測(cè)試

不少程序員可能這么想過：“我的這個(gè)應(yīng)用程序微不足道，它可以很容易地被手工測(cè)試覆蓋；單元測(cè)試是針對(duì)大型和復(fù)雜的東西，而不是針對(duì)我的程序。”

可想而知，這會(huì)直接親手創(chuàng)造一個(gè)沒有關(guān)注點(diǎn)分離，難以重構(gòu)，完全不可維護(hù)的代碼庫。

“躡手躡腳”幾乎是許多小白程序員的通病，害怕對(duì)代碼進(jìn)行哪怕是最輕微的修改，因?yàn)槿魏胃亩伎赡軐?dǎo)致或不會(huì)導(dǎo)致破壞性的更改。結(jié)果到最后一發(fā)不可收拾，出現(xiàn)的問題無法解決。使用這種遺留代碼不僅僅是無聊和緊張，而且精神上也有壓力。

但是使用單元測(cè)試，能讓代碼的壽命大大提高。Mohamed希望自己能學(xué)會(huì)單元測(cè)試的“藝術(shù)”，從入學(xué)第一天開始練習(xí)單元測(cè)試，可惜學(xué)校并不教這個(gè)。

世界上，無數(shù)令人為之一振的創(chuàng)新發(fā)明都源自無數(shù)次的試錯(cuò)，但即便如此，避免基礎(chǔ)性的錯(cuò)誤依舊是很有必要的。在你的程序人生中，還遇到過哪些令人啼笑皆非的“常見誤區(qū)”？亦或者是創(chuàng)造了一些百思不得其解的“致命誤區(qū)”？歡迎下方留言，分享你學(xué)習(xí)編程時(shí)的心得體驗(yàn)。