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