[注]十大編程禁忌 -- 程序員都必須克服

程序員在編程的時候不免會犯錯誤，但若是不從錯誤中吸收教訓，那麼習慣成天然，你會常常犯錯的。從錯誤中不斷的學習，鍛鍊好的行爲習慣有助於事業上的穩定。

這就是咱們如何將小麥從糟糠中區別出來以及如何避免編程禁忌的絕佳經驗。此外，最重要的就是能夠爲客戶帶來更好的用戶體驗。

1. 不提高非技術技能

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

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

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

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

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

 

2. 對編碼不理智

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

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

 

3. 不必定什麼都要被理解

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

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

• a. 把全部參數、引用、方法和變量名稱儘量接近英語表達。保持文件名簡短但有助於理解的功能。
• b. 使用++包裝文字是一個好辦法，能讓代碼和註釋更加清晰。
• c. 將編寫的程序保持在一個連續的流程上，尤爲是在使用OOP基礎上的語言：C#、C 和 C++。
• d. 對於不一樣的代碼塊使用不一樣的描述名稱。

 

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

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

• 對一些可能會對其它代碼有影響的常見案例進行捕捉，處理這些比較常見的異常狀況（而不是特殊的異常）意味着無心中除除掉了會抑制整個程序的殘留部分，所以並不會影響他人的代碼。
• 也許程序員可能帶有惡意的意圖來捕捉全部的異常狀況，但即便是捕捉到了也不實施採起措施，這就是常說的「虛假安全閥」，這種異常處理手段是對整個軟件的穩定和安全的一種妥協方式。

 

5. 較差的控制版本

在任何涉及多個團隊的項目裏，當談到版本控制的時候不去介紹使用最佳實踐都是一個十足的罪過。版本控制的目的是確保由一我的執行的編輯或修訂不去影響另外一我的的工做。

版本控制不只有助於將由兩個或兩個以上的程序員的編輯工做合併到一塊兒，還有助於跟蹤程序的更改歷史。因此說，任何開發團隊都應該作一些好的改進措施以確保強大的版本控制，這其中就包括：

• 爲每一個解決方案建立一個「邏輯單元」
• 給解決方案制定描述性的名稱
• 確保你所使用的都是最早進的文件
• 頻繁的向團隊分享你所作的各類改變

 

6. 擁有最新信息的我的表明不了團隊

這是相對有趣的一點，全部的商業產品都想要以自身的敏捷技術和產品文化來給客戶留下深入的印象，可是現實中不多有廠商會花時間去磨練他們員工在介紹產品特色上的技能。許多公司只是簡單地提供了一些基本的培訓，而且抱但願與員工在真實的平常項目裏學到更多的 技能。因此部門經理和項目的直接領導能夠經過如下兩個辦法來提升員工的業績：

• 一旦有新員工加入，就馬上強制安排他參加專業培訓，讓他知道他的角色是用來幹什麼的，儘早產生創造力。例如一個測試人與加入以後，就應該向他介紹編程的理念，以後將培訓重點放到測試實踐上，而不是繼續闡述編程的重要性。
• 現階段的技術的進化程度比以往任什麼時候候都要快，因此要記住，按期培訓是必不可少的，這是在給團隊創造價值。例如一個Web 設計師須要知道響應式設計，提供給設計師大量的用戶平常使用的移動設備的不斷擴張的樣品，但願他們能得到靈感。

 

7. 不恰當的測試

測試做爲整個系統開發生命週期（Systems Development Life Cycle，簡稱SDLC）的重要一個要素，一般不須要開發團隊給出太驚人的結果。可是若是在測試環節沒有付出恰當的、相應的努力的話，這是說不過去的。 下面的一些方法或許對你的測試團隊有用，至少在大家交付產品的時候可以給用戶一個好的交代。

• 單元測試
• 實物模型
• 綜合測試

 

8. 注意安全漏洞

有的時候在軟件開發過程當中，就會碰見以下這樣的安全漏洞：

A、不一樣組件之間意想不到的交互做用：a、輸入不正確的驗證信息；b、SQL資料隱碼攻擊；c、跨網站指令碼；d、命令植入攻擊；e、跨站請求僞造（CSRF）；

B、難以實施的資源管理，包括：a、不尊重可用內存緩衝區；b、對外控制；c、使用有潛在危險的功能；

 

9. 和客戶交流

最初的合同簽定後，開發公司一般會忘記天天與客戶進行產品上的信息交互，以致於在交貨的時候還須要進行升級。兩大關鍵的交流點可讓你和客戶保持更好的、更長的關係：

• 在客戶開問以前，開發方應該和客戶進行交流溝通。
• 和客戶保持週期性的交流。

 

10. 避免標準實踐面臨的迫在眉睫的最後期限

一般狀況下項目都會遇到進度延誤的現象。然而，這不是說你有理由去偷工減料或者是在開發或測試階段耍花招，未經測試的模塊絕對是一個隱患，會讓你的開發團隊名譽受損的。一個更好的方法來管理延遲是提早告知客戶而且積極執行延遲計劃。只要延期的理由是有效的，客戶應該會理解，也會給你額外的時間來解決這個問 題。

顯然，在項目的最後期限內，急急忙忙完成編程的質量確定不是特比保險，因此在交付以後開發團隊總體上會花更多的時間和努力來進行跟蹤維護，這樣的成本也是很巨大的，最好的辦法就在一開始就制定完美的執行計劃。項目再造所耗費的資源或許是項目自己的成本的好幾倍，任何一個公司寧願花更多的時間在初始開發上，這樣最終的產品必定會符合SDLC標準，並在缺陷和不良問題上有足夠的話語權。對於顧客來講，時效性不 能以犧牲質量爲代價，永遠都不能。

 

文章最初發表在CSDN