前言：
很多人都說——程序一門藝術，對于這個說法，以前我是很難理解的，程序就是一個工具，一門學問，怎么會是一門藝術呢，后來工作越深入，考慮的東西越多，發現程序的確是一門藝術。什么是藝術呢？通過捕捉與挖掘、感受與分析、整合與運用，通過感受得到的形式展示出來的階段性結果。程序不只是你寫出來，運行起來就成功了，而是需要感受和分析、需要整合運用，需要最終變成成果。顯然，程序是符合藝術的標準。
藝術的展現除了術，還需要道。程序的術是大家都能得到的共識，各種各樣提升自己技術的文章到處都是，這里我們說說程序的道，也就是方法。這也是大家經常忽略或者不重視的地方。
作為一名藝術工作者（哈哈，自己也笑了。），工作中的確有太多需要注意的地方，特別是工作方法，這個東西在開發中一般是很少有人來培訓自己，或者花時間來教自己，這個需要自己去學習、總結。我自己越到后面越總是這方面的學習，這里我也來說說自己工作中自己爬過的坑以及身邊的同伴趟過的路。
關于開發
注釋以及代碼規范——程序是寫給人看的，其次才是給機器用的
- 代碼規范的困難點不是制定代碼規范，而是執行代碼規范。執行代碼規范無外乎就兩種方式：
- 通過代碼檢查。其實一般都是通過IDE的插件去檢查，常用的有適用于javascript的jsHint,適用于java的checkstyle,適用于 .net 的StyleCop。自動的代碼檢查能檢測到的問題還是比較有限的，主要是針對格式、注釋、命名等，但是效率高，能把一些低級的錯誤扼殺，如果熟悉二次開發，還是值得多花時間去研究定制的。
- 通過人工代碼審查。這個是純人工的方式，有些坑是工具檢測不出來的。如循環里訪問數據庫，循環里訪問網絡等，這些都需要去人工判斷的。我一般的方式就是在CVS工具獲取代碼的時候進行對比，大概的瀏覽一遍，就能發現一些低級的錯誤。這樣效率相對會高一點。
- 別說注釋影響性能，浪費時間。注釋的前提是一定要能讓人看得懂，別人能看懂你的代碼，就能節省很多時間，不要怕注釋文字多，太長。現代的語言和編譯器，對注釋產生的性能影響完全可以忽略不計。
異常的處理——程序的錯誤存在，就在你身邊
異常處理是我們開發過程中必須要面臨的問題，但是經常會有一些異常處理的方式，被錯誤的使用了：
- 不拋出異常，讓大家都懵逼了。
try
{
}
catch (Exception ex)
{
return null；
}
如果測試不出這樣的問題，在生產環境絕對懵B，沒有錯誤提示、沒有寫入日志，根本無法找到任何錯誤信息，這個看起來很低級的錯誤，在身邊的確是有人這么處理的，我見過好多了。
測試和開發環境有錯誤一定要將詳細的錯誤拋出來。
生產環境有錯誤也要適當的給與提示，告知錯誤，并且日志記錄詳細的錯誤。
- 忽略警告信息
現代編譯器產生錯誤是無法編譯通過的，但是警告默認是可以忽略的。如果條件允許，大家最好把警告全部處理掉，不處理就是在給自己埋坑，很有可能在后面會爆發。
我經歷過一個的一個事件就是.net調用redis的一次事故，使用的是官方推薦的驅動類庫為Service.Stack.Redis,但是使用的時候忽略警告信息，導致后期版本兼容性的問題在生產環境爆發，幸好已經有其他人躺過坑，所以問題立馬就處理掉了。
條件允許，請解決所有的警告，如果條件有限，經常查看警告信息，重視新出現的警告信息。
代碼潔癖——代碼一定要追求完美
很多人都經歷過接手別人的代碼，而且程序員最害怕的就是閱讀別人的代碼。不管是別人的代碼還是自己的代碼，都要習慣性去重構，代碼這門藝術不是一蹴而就的，是需要慢慢雕琢出來的。如果在開發過程中，不管是自己的代碼還是別人的代碼，發現問題，一定要去解決這些臟東西。代碼是積累的過程，不合適的代碼應該在初期就優化掉，如果越積越多，到最后只有可能是“沒時間優化”和“不敢優化”。
在重構的過程中，總是會有很多理由讓自己放棄這一操作，最多的兩個理由就是：“沒時間”和“風險太大”，持續衍生下下去，最后唯一的結果就是系統重新開發。這就是很多公司業務只是停滯不前或者穩步提升的，但是系統使用不到2年就要重做的原因。
代碼的最終結果是變成成果——一定要定義deadline
工作是永遠做不完的，但是項目必須定義deadline，即使在沒有明確考核的情況下，自己也需要給自己定義deadline，一個項目耗的太久，會讓項目的弱勢越來越嚴重，會讓成本越來越高，會讓開發人員的編碼效率低下，所有的開發任務一定要定義deadline。
定義deadline還有一個好處，就是能有成果展現，這個對于企業來說，是非常重要的。技術、知識、能力一定要變現成成果，即使是做技術研究，也需要有成果的展示，而不能一直處理進行中的狀態，這種意識是非常重要的。
關于集成
測試代碼是節省時間，而不是影響進度
一定要寫測試用例。測試用例絕對不會浪費你的時間，測試用例覺得不會拖慢項目的進度，而且能加快項目的進度，進度不是開發完了，就完成，你要協助測試，保證項目上線。項目的進度才是真正的進度。測試用例實施起來困難的地方就是無法堅持下來。即使，自己對自己寫出來的代碼負責，即使公司沒有要求，自己也要習慣寫測試用例。大家可以看看那些好的開源代碼，都是會有自己編寫的測試用例的。
現在的開發方式基本都是前后端分離，不管是web還是app，都是通過api進行數據對接，對于測試用例也更加容易測試，所有的接口都需要有對應的測試用例，如果不愿意寫代碼，測試工具也是有可以替代代碼編程的。對于開發人員，其實寫代碼測試可能體驗會更好，速度更加快，測試工具更多的是面向測試工程師。
自動化測試是增強自信的最佳方式
自動化測試是必要的
隨著時間的推移，系統的功能越來越多，功能越多其實意味著風險越大，出問題的可能性越來越大。隨著系統的變大，人工覆蓋的范圍有限，自動化測試是必須要做的。自動化測試應該提前規劃
初期，通過人工基本可以覆蓋所有的測試，但是后期功能越來越多，不僅要測試新功能，每個功能的開發都要進行全系統的回歸測試。前文提到測試用例，這個是自動化測試的基礎。有了強大的測試用例的積累，自動化測試的搭建就會更加容易。測試用例不是等到有時間，或者系統變大以后才做的，而是應該一開始就準備，不要等到系統變得非常龐大臃腫的時候才開始做，那時候你還需要重新會想當初的業務場景，得不償失。
代碼也隨時處于能被發布的狀態
現在的開發方式都傾向于敏捷開發，敏捷開發的優勢這里就不多說了，但是敏捷開發有一個特點就是高頻率的發布，所以代碼應該是需要隨時都處于能被發布的狀態，其實這并不是很難，只要合理的使用CVS工具即可。
- 永遠有一個和線上代碼一直的版本。 不要一個版本走到黑啊，一定要熟悉分支的作用。
- fix bug采用獨立版本合并發布。采用最小發布的方式，也就是需要哪幾個文件就合并哪幾個文件。
- 建立一個灰度發布的環境，作為發布前驗證的環境，和生產的環境一樣，只是地址只有內部人員知道。當然，如果可以通過Nginx或者網關控制灰度發布，就最好了。
關于協作
代碼是共享的，你的代碼大家應該都能修改
作為公司代碼的貢獻者，不管你是總監、經理、架構還是程序員，不要認為自己的代碼是別人不能修改，代碼應該是共享的，只要在公司授權的范圍內，我們應該是可以互相修改別人的模塊。
- 互相修改代碼其實是代碼審查的一個過程。
- 互相修改代碼便于互相熟悉業務。
在代碼面前人人平等，誰寫的代碼都會有問題，有重構的空間，不能因為你的職位高或者經驗足，就不讓別人碰你的代碼。
當然，有的人可能會改壞你的代碼，但是這個可以通過溝通解決這個問題。
有時，我們過多的關注了技術知識體系本身，卻忽略了把自己的技術知識更好的運用到工作中，運用到自己的系統中，因為這些東西除了學習相關的技能，更多的是需要自己總結，隨時趟過的坑越多，可能總結的東西越多，羅馬不是一天建造的，系統也是不是一次就完美的，我們自己的知識體系也需要時間去積累。
