【收藏】程序員必須克服的十大編程禁忌

程序員在編程的時候不免會犯錯誤，但若是不從錯誤中吸收教訓，那麼習慣成天然，你會常常犯錯的。從錯誤中不斷的學習，鍛鍊好的行爲習慣有助於事業上的穩定。這就是咱們如何將小麥從糟糠中區別出來以及如何避免編程禁忌的絕佳經驗。此外，最重要的就是能夠爲客戶帶來更好的用戶體驗。

1不提高非技術技能

咱們認爲非技術技能是項目成功的主要因素。這些非技術技能也能夠稱之爲「軟技能」，整體上來講，它已經被公司證實爲可以駕馭企業和客戶之間的長期商業關係，所以也能決定公司的成長髮展路徑。一些關鍵的軟技能指標包括：

a.紀律——這是最重要的特徵之一，缺少紀律，最終會讓這個開發團隊在開發能力上「缺少自信」。解決這一問題的矯正方法就是天天制定詳細的to-do清單：兌現你的承諾、完成你開始作的事情、避免多重任務，由於這些每每會讓你的生活產生混亂。

b.顧客的聲音——不把客戶置於決策的核心地位只會跟大家業務的原始目的相沖突。若是客戶不高興，即便你擁有世界上一流的專業知識和資源也不會起什麼做用。保持符合客戶指望的解決方案、及時交付才能體現出項目的真正價值。

c.溝通——尤爲是當客戶和供應商並不在同一地點的時候，明確而及時的溝通是填補服務空白的極好措施。主要集中在這三個方面你就能克服問題——進行主題討論、清晰表達、乾脆簡潔。

d.瞭解需求——在整個開發生命週期過程當中，決定成功和失敗的之間的一個相當重要的區別將會給人留下深入的印象。經過最初的頭腦風暴法瞭解問題狀態，以及後續的交貨程序，這其中都要和客戶完美配合。只有這樣，客戶纔會讚揚你的工做，給你好評。

2對編碼不理智

古人云：善泅者溺，善騎者墮。但估計絕大多數的程序員都認爲本身的編程技術絕對的牛。而一樣真實的是，每個代碼，讓不一樣的程序員去實現的話都會不可避免地發現它所存在的缺陷。因此說，只有經過在一個項目上的合做，程序員之間必然有的摩擦才能證實誰是最好的。健康的競爭是好事，但它不該該成爲一個原本能夠成功的項目的負擔。

另外一個創意阻礙是沒法將預約義的模板使用在對你有利的開發項目裏。幾乎全部的編程語言有一個很好的在線 /內置的代碼片斷存儲庫，能夠修補代碼，防止從新編程。然而，若是由於不理解需求或缺少接觸各類可用庫/模板的話，這就意味着程序員最終會無心間將一開始就建立的代碼付之東流。這不只增長了開發時間，也提升了整體成本。另一點就是，發佈了的代碼已經通過了質量檢測，因此只有將它用做模板才能發揮它更大的價值。

3不必定什麼都要被理解

若是你是剛調到這個團隊來的編程人員，對於手頭的工做並非很熟悉，那該怎麼辦？確定是先看一些前任留下來的工做計劃，要是他寫的詳細倒也沒什麼，若是寫的不詳細，估計會讓你更加的撓頭。

所以，推己及人，在須要交代的工做上，最好是把任務寫的儘量的詳細。這麼作也是很是現實的緣由：可以把編程問題解決掉，最好是保證使用解釋性的語言和英語發音來表示變量。一些基本的指針可讓你的程序更容易被理解，包括：

a. 把全部參數、引用、方法和變量名稱儘量接近英語表達。保持文件名簡短但有助於理解的功能。

b. 使用++包裝文字是一個好辦法，能讓代碼和註釋更加清晰。

c. 將編寫的程序保持在一個連續的流程上，尤爲是在使用OOP基礎上的語言：C#、C 和 C++。

d. 對於不一樣的代碼塊使用不一樣的描述名稱。

4不使用通過驗證的工具和技術

程序員的好壞從他使用的編程工具和調試工具上就能看出。在異常狀況的跟蹤上，下面就是程序員常常會出現的常見錯誤。