1.系統(tǒng)流程梳理

以一個很簡單的例子來說明流程梳理對軟件開發(fā)的意義，比如你要進(jìn)行一次演講，但是這次演講是即興的，你不是專業(yè)的即興演講家，那么在沒有準(zhǔn)備情況下，你要對著臺下的人進(jìn)行演講，這個時候你走上臺去，腦子里的東西還沒有形成有條理的演講內(nèi)容，講完后臺下的人都不知道你在講什么，可能你自己都不知道你剛剛講了些什么，這就是失敗的演講，沒有做好充足的準(zhǔn)備。對于軟件開發(fā)來說也是同樣的情況，每一個開發(fā)者不應(yīng)該僅僅拿到的是一些文檔，而是應(yīng)該大家坐在一起，由熟悉該軟件業(yè)務(wù)的管理者或者其他人來進(jìn)行一次嚴(yán)謹(jǐn)?shù)拿枋觯⑦M(jìn)行討論，加以完善和改進(jìn)，讓參與編碼的開發(fā)者在這個過程中不僅能夠熟悉自己要做的那些功能的細(xì)節(jié)，還能對這個系統(tǒng)有一個大致的了解和熟悉，只有這樣，在開發(fā)中才會避免一些不必要的問題發(fā)生，而且還能發(fā)現(xiàn)一些隱藏的問題，要知道修改問題是需要花費(fèi)很多時間和精力的，比如編碼和業(yè)務(wù)是有沖突的，本人有遇到過，代碼不能完全跟著業(yè)務(wù)走，業(yè)務(wù)也在適當(dāng)?shù)臅r候在滿足正常場景下根據(jù)編碼風(fēng)格做適當(dāng)?shù)恼{(diào)整。最終達(dá)到一種整體和諧的一種美感。在編碼的前期要讓每一個參與項(xiàng)目的人能夠清晰的知道我要做的是什么，最終的目標(biāo)是什么樣的，我要關(guān)注的重點(diǎn)有些，還有哪些疑慮我需要討論或者解決的。準(zhǔn)備工作做好后，對每一個團(tuán)隊(duì)成員項(xiàng)目的進(jìn)度是非常清晰的。

2.技術(shù)框架的選擇

一般選擇技術(shù)架構(gòu)有幾個衡量的點(diǎn)：

第一點(diǎn)：效率。

在開源領(lǐng)域能完成同一個技術(shù)目標(biāo)的框架是多個的，比如在web開發(fā)的，最終開發(fā)出來的產(chǎn)品是要經(jīng)過性能這一關(guān)的，如果選擇有誤，整個軟件可以說是失敗的，因?yàn)椴荒苡茫阈枰匦逻x擇技術(shù)框架，并且要重新讓每一個開發(fā)者在新的框架上進(jìn)行開發(fā)，這是在開發(fā)一個新的軟件。

第二點(diǎn)：成本。

第一個是學(xué)習(xí)成本，第二個是經(jīng)濟(jì)成本，只討論學(xué)習(xí)成本，因?yàn)楸救朔浅７磳κ褂蒙虡I(yè)軟件，把這筆買商用軟件的資金來激勵和培養(yǎng)員工效果會更好，這里不做什么討論，不是商業(yè)上的東西就很安全，開源的東西也很安全，只說一句：大部分情況都是浪費(fèi)！關(guān)于學(xué)習(xí)成本要考慮到團(tuán)隊(duì)實(shí)力和團(tuán)隊(duì)人才培養(yǎng)方式，如果項(xiàng)目團(tuán)隊(duì)沒有什么培訓(xùn)和學(xué)習(xí)氣氛，那么這個團(tuán)隊(duì)選擇框架的原則是非常簡單的，在這種情況下就選擇自己熟悉的能有把握的；還有一種情況就是團(tuán)隊(duì)中有實(shí)力非常強(qiáng)的開發(fā)者或者學(xué)習(xí)能力非常強(qiáng)的開發(fā)者，那么可以選擇一款相對最適合整體架構(gòu)的新技術(shù)框架，并加以絕對重視，因?yàn)檫@是新的東西，風(fēng)險也是非常高的，只要重視了，而且技術(shù)上可行的，結(jié)果是完美的；這是根據(jù)團(tuán)隊(duì)的實(shí)際情況進(jìn)行參考，勇氣也很重要。

第三點(diǎn)：穩(wěn)定性。

選擇一個合適的軟件版本，個人比較傾向于在最新的平臺和框架上進(jìn)行開發(fā)，因?yàn)橛行碌奶匦裕锌赡苄牡陌姹居羞M(jìn)行一些優(yōu)化。

對穩(wěn)定性的考慮，舉一個例子，根據(jù)實(shí)際情況已經(jīng)選擇要使用一個A框架了，假設(shè)A框架有兩個版本，V1和V2，V1是穩(wěn)定版本，V2還是測試版本，V2中添加了一些新的功能，而這些功能正好滿足你的項(xiàng)目需要，并且穩(wěn)定版本是在你編碼完成前就會發(fā)布，那么眼前有兩個選擇第一個選擇，選擇V1版本并且要選擇一個新的B框架來滿足項(xiàng)目需要，這種方式風(fēng)險是最低的；第二種選擇，選擇V2測試版本，最終等到穩(wěn)定版本發(fā)布后進(jìn)行替換，這種方式也是可以選擇的，不過風(fēng)險相對第一種選擇要高些，有一個優(yōu)勢就是這一個框架就可以完全滿足你的項(xiàng)目需求，成本相對低一點(diǎn)。兩種情況我都有實(shí)踐過。

3.編碼

在軟件產(chǎn)品的編碼中需要注意的一些宏觀問題：

第一點(diǎn)：代碼風(fēng)格。

一個年輕的團(tuán)隊(duì)很容易遇到這個問題，一個軟件開發(fā)完了，回頭去看里面的代碼，編碼風(fēng)格很不統(tǒng)一，有5個開發(fā)者就有5種代碼風(fēng)格！怎么樣避免這種情況，只能在編碼之前進(jìn)行代碼編碼風(fēng)格宣講和討論，把規(guī)則制定下來，大家按這種風(fēng)格進(jìn)行代碼編寫，還有一點(diǎn)要做的就是代碼檢視，不要因?yàn)槊Χ雎赃@個，一周花一個下午來看看別人的代碼，不僅能看到一些問題，而且還能看到自己的一些問題，當(dāng)開發(fā)一段時間過去以后，代碼不斷的調(diào)整，最終的源碼看上去就是一個人完成的一樣！所以開工之前把這方面工作做好，事半功倍，后面還有很長的軟件維護(hù)工作要做，如果整體代碼一團(tuán)糟，我想沒人愿意去維護(hù)這么糟糕的代碼。這樣的項(xiàng)目本人也遇到過，深有體會。

第二點(diǎn)：注釋。

比風(fēng)格統(tǒng)一的更難的可能就是注釋了，我想你不會這么認(rèn)為，我也想自己這種認(rèn)識是錯的，因?yàn)閷懽⑨屵@種活總比編碼要容易得多吧，不是這樣的，很多人應(yīng)該都看過國內(nèi)一些開源的程序員寫的開源軟件吧，很膜拜吧？呵呵，我也有看過，說下我的感受吧，首先代碼很少有注釋，一個類文件看下來只有代碼，注釋非常稀少，不知道他是怎么想的，再簡單的代碼也要有方法和類注釋吧；其次，代碼里面有稀疏的注釋，好不容易啊，結(jié)果是英文的，還有文檔里面都是英文的，一個說中文的家伙為什么搞成英文版的呢。另外，打印日志不加級別判斷，還有一些編碼問題在里面。很想罵幾句，但是人家畢竟是開源的，不容易??！ 精神可以鼓勵，但是態(tài)度值得懷疑。如果你現(xiàn)在剛編完代碼或者要開始編碼了，請把代碼寫好的同時把注釋寫好吧！如果一個剛?cè)腴T的程序員能直接通過注釋就能讀懂你的程序代碼，那么你寫的注釋已經(jīng)非常成功了。

第三點(diǎn)：代碼目錄結(jié)構(gòu)。

這點(diǎn)和編碼風(fēng)格是掛鉤的，也可以屬于代碼風(fēng)格里面的一部分，但是單獨(dú)拿出來肯定有獨(dú)特的含義。你有沒有想過或者遇到過通過代碼目錄結(jié)構(gòu)就能夠大致看懂該項(xiàng)目是要做什么，有哪些功能，如果看到這樣的工程是不是有一種很想再往里面看的沖動？本人有參與這樣的項(xiàng)目編碼，當(dāng)時我們做的還比較成功，剛開始做有點(diǎn)不習(xí)慣和編碼風(fēng)格不同，關(guān)于代碼目錄結(jié)構(gòu)我們進(jìn)行了單獨(dú)的討論，根據(jù)本身的技術(shù)架構(gòu)來制定的，把這點(diǎn)做好，開發(fā)者編寫代碼更加清晰了，效率也有所提高了，后期維護(hù)哪怕是新人來維護(hù)，只要稍微講講，也會很容易的接受，一切都變得更加簡單了。

第四點(diǎn)：命名。

這點(diǎn)也可以同屬于代碼風(fēng)格。坦白講單獨(dú)拎出來說也沒有多大意思，因?yàn)榇a風(fēng)格里面就會強(qiáng)調(diào)，但是你不覺得這么重要的東西很容易忽略嗎，比如大小寫，id我是寫Id還是寫成ID呢，沒有多少人會在意，只有出現(xiàn)問題了，代碼冗余量增加了，才會發(fā)現(xiàn)，命名也是非常重要。還有一些，類文件的命名詞不達(dá)意的，我想提醒你的是，既然這么重要那么請謹(jǐn)慎對你的代碼進(jìn)行命名！

第五點(diǎn)：贊成有必要的重構(gòu)。

重構(gòu)需要注意時機(jī)，有兩個點(diǎn)是最好進(jìn)行重構(gòu)了，第一點(diǎn)是在自己編寫完代碼以后進(jìn)行優(yōu)化和重構(gòu)，轉(zhuǎn)測試之前；第二點(diǎn)就是當(dāng)項(xiàng)目初期大家沒有意識到要去重構(gòu)，也就是第一點(diǎn)沒有做充分，導(dǎo)致代碼重復(fù)率比較高等一些整體問題，在這種前提下找一個時間段，對整體代碼進(jìn)行一次重構(gòu)計(jì)劃，這是有必要的。

第六點(diǎn)：一些提高代碼的工具使用。

在這里簡單列出幾類工具，網(wǎng)上有很多資料，需要根據(jù)自己的語言進(jìn)行選擇。

第一類：代碼自動檢視bug工具

第二類：代碼統(tǒng)計(jì)工具

第三類：代碼重復(fù)率和復(fù)雜度工具

第四類：代碼覆蓋率工具

第七點(diǎn)：不要隨意修改代碼，特別是別人的代碼。

修改代碼應(yīng)該是放在一個時間段，而不是隨意進(jìn)行修改，目前比較流行的敏捷開發(fā)中有一個現(xiàn)象就是版本發(fā)布比較頻繁，修改代碼是有很大的風(fēng)險的，修改的代碼很有可能是公共代碼，多處地方有調(diào)用，很有可能造成其他地方出問題，小問題解決，大問題來了。當(dāng)需要修改其他開發(fā)人員的代碼時一定要和對方溝通下，避免造成不必要的誤會和引發(fā)潛在的問題。

*編碼中需要注意的一些微觀問題

這些就是編碼功底了，我自身的感受就是，要不斷的回頭看看自己的代碼，很多地方值得你重新思考和關(guān)注。

平時有時間可以靜下心來閱讀比較經(jīng)典的書籍，看不懂或者不太記得沒有關(guān)系，重新再看。

4.測試

作為一個開發(fā)人員所接觸的測試首當(dāng)其沖的就是編寫單元測試用例，盡量覆蓋每一個場景，這對軟件質(zhì)量起到一個很關(guān)鍵的作用，為了避免與測試人員反復(fù)溝通增加無謂的成本，開發(fā)能做的就是寫單元測試發(fā)現(xiàn)一些潛在的問題，把大部分的bug提前發(fā)現(xiàn)。從管理角度來講，測試也會輕松很多。開發(fā)一款相對完美的軟件絕對是一個優(yōu)秀程序員的追求。也是在程序員這條道路上的一筆收獲。

? ?