要注意避開這七個程式設計迷思啊！

我們很少看到有人公開談論自己的錯誤。

人非聖賢，孰能無過？雖然難言出口，但反思過去所犯的錯誤可以讓人不會在未來——至少是短期的未來，犯下同樣的錯誤。

Mohamed Barouma是位工作5年的專業程式設計師，但和任何人一樣，他也犯過錯。

他這麼說：「通常情況下，我不會馬上意識到自己做錯了什麼；只有在接觸到正確的做事方法後，我才知道犯了哪些錯。」

結合他的原文，本文總結了他所犯下的七大誤解。

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希望自己能學會單元測試的“藝術”，從入學第一天開始練習單元測試，可惜學校並不教這個。

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

參考：

https://betterprogramming.pub/7-big-mistakes-i-have-made-in-my-career-as-a-software- engineer-f14ef540be10

以上是要注意避開這七個程式設計迷思啊！的詳細內容。更多資訊請關注PHP中文網其他相關文章！