在編程時應該注意哪些問題？有什么誤區？

在編程時應該注意哪些問題？我們很少看到有人公開談論自己的錯誤。人非圣賢，孰能無過？雖然難言出口，但反思過去所犯的錯誤可以讓人不會在未來——至少是短期的未來，犯同樣的錯誤。下面我們就來看看編程的常見問題。

在編程時應該注意哪些誤區？

1、沒有使用合適的ORM

數據訪問層代碼總是混亂、乏味和無聊的。不幸的是，往往這點到最后才能發現。

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

當Mohamed第一次做一個簡單的內部會計應用程序時，他發現只是為了完成基本的程序，就不得不編寫大量的代碼。于是他開始埋頭于ADO.NET，并手動編寫了一個自制的、具有非常特殊的、自定義的表模式的ORM，來滿足目的。

在一段時間里，這個ORM工作的相當不錯，直到幾個月后，公司的業務需求發生了一些變化，這導致了整個表格模式的變化，然后，就是對ORM的反復修改。這個流程的痛苦之極，讓Mohamed最終選擇了強類型數據集適配器。

雖然這件事因此解決，但如果能找到一個更合適的ORM(比如NHibernate)來完成工作，Mohamed仍會義不容辭，至少當他的用戶數量增加時，不必擔心更改數據庫的供應商。

2、沒有學會使用泛型

Mohamed Barouma的職業程序員生涯始于Net 1.1。而在當時，Net 1.1的主要問題在于它沒有泛型支持，這代表它不能有一個強類型列表，只能滿足于乏味的ArrayList。但是使用Arraylist在Java代碼中進行類型轉換和裝箱，會導致讀寫起來十分痛苦。

因此，Net 1.1的程序員們使用CodeSmith生成一個強類型集合列表。

但隨著代碼庫的增長，那些定制生成的列表本身就變成了一個無法收拾的怪物。只要經常為了創建對象或調用方法去達到目的，隨后就會因為修改代碼導致混亂和錯誤。

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

3、沒有放棄“造輪子”

這是個老生常談的話題，“反復造輪子”（Reinvent The Wheel）。新程序員總是喜歡反復“造輪子”，自認為當前的實現不夠好，所以不得不從頭重寫整個東西。

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

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

4、沒有精簡過多的文檔

很多剛入行的程序員，會在一開始覺得代碼文檔很好，因為它用簡單的英語注釋了代碼在做什么。但事實上這些文檔通常在修改了幾次代碼之后變成了一攤廢紙，變得陳舊、過時亦或是完全錯誤。

常常有人花了很多時間編寫代碼文檔——比如XML文檔，結果發現在更改代碼時需要更新文檔。因為它的功能可能都已經改變了。更新代碼是必須的，但更新XML文檔不是必須的：這是一種負擔，它消耗時間，而且毫無用處。

最終，反復地更改XML文檔使人逐漸失去耐心，轉而做其他事情。

5、沒有使用自動化構建

應用程序的部署和打包比編程相對容易，所以它往往被放在了非常低的優先級上。但很快，粗制濫造的構建就會因為無法工作，受到各式各樣的投訴：

“先決條件缺失，該如何修復？”

“dll沒有更新，你能給我一個補丁嗎？”

“我的圖標怎么不見了？”

緊接著，電話像雪崩一樣源源不斷地打到桌旁。這是Mohamed的真實經歷，并讓他那天精疲力盡——不是因為編程，而是因為令人麻木的重新部署和重新包裝過程。

而這一切，本可以通過編寫自動化腳本節省一些時間，否則在事后debug浪費的時間絕對比可以節省的時間多上數倍。應該讓軟件可以一鍵構建，否則再多都是一種浪費。

6、沒有停止對視覺檢測和debug的依賴

Visual Studio讓人們可以很容易地調試代碼并進行動態檢查，這也使得創建一個表單并顯示輸出非常簡單。但如果太沉迷于調試器，這項好處就要變成壞處了。

為什么呢？想象一下，如果一個方法只在應用程序啟動并運行45分鐘后才被調用，那難道要打算等45分鐘再開始調試嗎?

所以，動動手將應用程序分解為可以獨立調用的子模塊，這樣就可以準備產生錯誤輸出的輸入值，并從那里開始測試它。

7、沒有做單元測試

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

可想而知，這會直接親手創造一個沒有關注點分離，難以重構，完全不可維護的代碼庫。

“躡手躡腳”幾乎是許多小白程序員的通病，害怕對代碼進行哪怕是最輕微的修改，因為任何更改都可能導致或不會導致破壞性的更改。結果到最后一發不可收拾，出現的問題無法解決。使用這種遺留代碼不僅僅是無聊和緊張，而且精神上也有壓力。

但是使用單元測試，能讓代碼的壽命大大提高。Mohamed希望自己能學會單元測試的“藝術”，從入學第一天開始練習單元測試，可惜學校并不教這個。

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