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