這次談?wù)劶兗夹g(shù)，談一些編程習(xí)慣的事情盹愚。

標(biāo)題是「編程慢習(xí)慣」栅迄，為什么是「慢習(xí)慣」呢？

因?yàn)槲医裉旆窒淼倪@些習(xí)慣在短期之內(nèi)會增加時間開銷皆怕，不能立即獲得什么收獲毅舆。但時間久了西篓，至少對我自己是非常有幫助的，為我節(jié)省了不少的時間同時在編程能力上也獲得了成長憋活。

另外在啰嗦一下污淋，本文并非針對高手的，如果您是高手余掖，可以跳過后面的內(nèi)容了寸爆，接著看下去會耽誤到您寶貴的時間。

一盐欺、做自己的需求文檔

我們在編程時赁豆，是否充分的了解了需求，關(guān)系到我們后續(xù)所開銷在項(xiàng)目上的時間冗美。做一個新功能通常不會讓我厭倦魔种，但是一次次的修改卻會讓我身心疲憊。特別是一些本身就時間緊任務(wù)重的項(xiàng)目粉洼，就意味著需要一整晚又一整晚的加班趕工了节预。

具體比如說，以下3點(diǎn)會大量增加我們的時間精力投入：

1.需求本身就存在問題属韧，邏輯無法走通安拟，但是這個時候已經(jīng)寫了不少或者和之前的代碼沖突到了。

2.部分需求沒有表達(dá)清楚宵喂，溝通后發(fā)現(xiàn)對時間的需求誤判了糠赦，規(guī)定時間內(nèi)完成變得困難

3.寫到一半，發(fā)現(xiàn)自己思路不對不得不重頭開始整理

解決這些的方法每個人都有每個人的選擇锅棕，我的選擇是做一份自己的需求文檔拙泽。這份文檔內(nèi)容并非是產(chǎn)品經(jīng)理或者技術(shù)主管、需求方所表述的裸燎，而是基于我的理解進(jìn)行的二次整理顾瞻。

需求文檔當(dāng)中大概有這么幾部分的內(nèi)容：

1.項(xiàng)目的基本概述

項(xiàng)目的簡述，這個項(xiàng)目到底在做什么

完成的目標(biāo)德绿，最終使用人對于使用這個系統(tǒng)的實(shí)際需求

預(yù)計(jì)交期荷荤，DEMO演示的日期，交付測試的日期脆炎，上線的日期

2.項(xiàng)目的資料

服務(wù)器賬號和環(huán)境

需求文檔

開發(fā)梅猿、生產(chǎn)環(huán)境需求

參考的項(xiàng)目或代碼

溝通會議記錄

3.業(yè)務(wù)相關(guān)

業(yè)務(wù)核心邏輯，通常還會轉(zhuǎn)換為初步的實(shí)現(xiàn)邏輯

執(zhí)行流程

4.實(shí)現(xiàn)

需要做的功能拆解

數(shù)據(jù)規(guī)模

實(shí)現(xiàn)方式

對現(xiàn)有系統(tǒng)影響的改動點(diǎn)秒裕，如果是全新系統(tǒng)可以忽略

5.其他

測試單元規(guī)劃

記錄完這些內(nèi)容會花掉不少時間袱蚓，中間可能還要跟需求方、產(chǎn)品經(jīng)理進(jìn)行多次溝通几蜻。至于細(xì)節(jié)到底多細(xì)喇潘，沒有一定的標(biāo)準(zhǔn)体斩，視項(xiàng)目和個人情況而定。

最重要的是做到心中有數(shù)颖低，對開發(fā)周期的心中有數(shù)絮吵、對模塊大致劃分的心中有數(shù)，對內(nèi)部流程的心中有數(shù)忱屑。

花力氣為自己做的需求文檔蹬敲。在完成后，不僅核心要點(diǎn)印象深刻莺戒，后期檢索也會非常方便伴嗡，最大限度在已知條件下降低走彎路的概率。從過往經(jīng)驗(yàn)來說从铲，等到開始開發(fā)以后再去查聊天記錄瘪校，或者是找相關(guān)人員詢問，就慢的多了名段。

二阱扬、用最笨的方法先去實(shí)現(xiàn)

需求文檔做好了之后，我就會開始動手寫代碼伸辟，會把需求文檔中最核心需要實(shí)現(xiàn)的業(yè)務(wù)邏輯獨(dú)立分解出來麻惶，做一個Demo。按照輸入自娩、處理用踩、輸出，三個部分進(jìn)行編寫忙迁。

基本上不會去寫太多的注釋。也不會去想模組如何構(gòu)建以及語法是否美觀可讀碎乃、效率是否是最優(yōu)姊扔。能夠得到正確的輸出結(jié)果為第一位有優(yōu)先。這樣做可以隨意修改梅誓，而且代碼量少恰梢，如果實(shí)現(xiàn)過程出現(xiàn)問題，很容易就可以定位到原因梗掰。

把功能實(shí)現(xiàn)以后嵌言，先做壓力業(yè)務(wù)邏輯測試，沒有問題及穗，再移植到項(xiàng)目中摧茴。移植的過程時，本身也是對代碼邏輯的Review埂陆，思考實(shí)現(xiàn)的合理性與是否需要進(jìn)行一些調(diào)整苛白。

這里還有一個重點(diǎn)娃豹，通常稍大的項(xiàng)目是無論時間有多緊張，也不能不經(jīng)思考直接的去把代碼直接復(fù)制進(jìn)去购裙。給自己挖坑的事情越少做越好懂版。

三、做壓力測試調(diào)整結(jié)構(gòu)設(shè)計(jì)

很多程序員習(xí)慣把代碼先寫完躏率，交付前最后在做性能測試躯畴，如果前面的設(shè)計(jì)就沒有考慮到性能問題，就很頭大了薇芝，代碼也沒有時間可以重寫蓬抄，就這么將就著先用了。最后一直被性能問題所困擾著恩掷。

業(yè)務(wù)的需求和壓力在哪里倡鲸，產(chǎn)生瓶頸的核心點(diǎn)在哪里。如果你做為程序員也能懂這些黄娘，不僅有效避免后續(xù)的修改次數(shù)峭状，自身價值也會更高。

所以我在DEMO實(shí)現(xiàn)后逼争，就會習(xí)慣性考慮性能問題优床。模擬預(yù)想中會出現(xiàn)的高并發(fā)高流量，自己寫一個壓力測試模塊誓焦。如果發(fā)現(xiàn)有問題胆敞，先修改DEMO中的核心代碼及實(shí)現(xiàn)方式，調(diào)整到自我認(rèn)為平衡為止杂伟。

四移层、盡可能的砍掉代碼冗余

同樣的實(shí)現(xiàn)，通常有多個方案可以去實(shí)現(xiàn)赫粥，我在一開始做的時候观话，用的可能是當(dāng)時想到的快速實(shí)現(xiàn)方案。

當(dāng)想到更好替代方案時越平，不太會猶豫频蛔，保證安全和性能的前提之下會砍掉原有的代碼。用更簡單的邏輯的寫法替換到冗余的代碼秦叛。

五晦溪、多留日志

就算測試的再完美，上線之后也難免會出問題挣跋。這之中三圆，既有可能是本身服務(wù)器運(yùn)維方面的問題，也有可能是BUG。如果能再現(xiàn)的故障還算好查嫌术，最怕一些偶然發(fā)生哀澈，但又無法復(fù)現(xiàn)的問題。負(fù)責(zé)運(yùn)維和開發(fā)的工程師兩邊都會非常頭疼度气，難以快速解決割按，還會相互扯皮。

所以我會在代碼里盡可能的多留一些日志磷籍，并且把這些日志自動進(jìn)行一些采集适荣。這樣，如果有發(fā)生問題院领，第一時間就會有大量的數(shù)據(jù)可以去查詢弛矛，對定位問題非常有幫助，不必再一點(diǎn)點(diǎn)的去調(diào)試比然，一個個模塊去排除丈氓。

同時如果對業(yè)務(wù)數(shù)據(jù)的準(zhǔn)確性非常敏感的系統(tǒng)，除了一些常規(guī)的日志外强法，我還專門針做一些對業(yè)務(wù)邏輯校驗(yàn)的日志万俗，定時通過一些自動化的程序去檢核這些數(shù)字。通過結(jié)果反推是否存在一些沒有預(yù)料到的問題饮怯。

六闰歪、忘記編代碼的過程，以其他人閱讀角度進(jìn)行修改

雖然程序是給計(jì)算機(jī)去執(zhí)行蓖墅，但是無論是業(yè)務(wù)的擴(kuò)展還是BUG的修復(fù)库倘、性能提升、算法優(yōu)化论矾，都需要通過人來進(jìn)行教翩。寫好一組代碼之后，并不100%保證自己或其他工程師以后完全不會去做維護(hù)贪壳。

基于這個考慮迂曲，在完成基本的程序編寫之后，我還會習(xí)慣先強(qiáng)迫自己忘記之前寫的代碼寥袭，以第三者的視角再來審視一遍程序：

1、程序邏輯是否清晰易懂

2关霸、代碼命名是否規(guī)范

3传黄、有沒有留下足夠的注釋線索

4、一個模塊中是否過于復(fù)雜

5队寇、是否留有進(jìn)一步改進(jìn)的余地

是選擇前人挖坑后人埋膘掰，或是選擇前人種樹后人乘涼，都看寫的人自己的一念之差。但本著負(fù)責(zé)任的態(tài)度识埋，任何情況下都少挖坑為妙凡伊。挖了坑，是出來混的窒舟，最后總是要還的系忙。

七、記錄錯誤

這一點(diǎn)和項(xiàng)目沒有關(guān)系惠豺，但是和個人成長會有直接關(guān)系银还。就像我們中學(xué)時做的錯題本一樣，從錯誤中學(xué)習(xí)是最快的方法洁墙。通過錯誤的記錄蛹疯，發(fā)現(xiàn)我們究竟是哪一部分有待提高，是語法不熟悉热监，是思考不夠全面捺弦，還是一開始就用錯了。有了記錄我們就會有可以去發(fā)現(xiàn)問題的線索孝扛。

依靠這些線索進(jìn)行思考列吼，主動意識到我們經(jīng)常出錯的部分之后×屏穑總可以有針對性的去解決冈欢。解決后接下來不定期的去反思，通過反思盈简，將學(xué)到的能力內(nèi)化形成戰(zhàn)斗力凑耻。

最后總結(jié)一下，我今天分享的七個慢習(xí)慣：

1柠贤、做自己的需求文檔香浩，讓自己對將要做的內(nèi)容心中有數(shù)，盡量避免理解不到位所付出的成本臼勉。

2邻吭、用最笨的方法先去實(shí)現(xiàn)輸入、處理和輸出宴霸。核心邏輯優(yōu)先囱晴。不去過多考慮其他問題。

3瓢谢、整合項(xiàng)目前祖搓，做壓力測試達(dá)到一開始的性能需求翼虫。而不是全部做完之后再去做性能優(yōu)化。

4、如果覺得代碼不合理羔杨，盡量多砍掉不合理的代碼進(jìn)行重構(gòu)。

5、多留日志讓不可預(yù)期的問題容易定位、分析狂魔、解決。

6淫痰、讓代碼具有可讀性最楷，別給自己與別人挖坑。

7黑界、記錄經(jīng)常犯的錯誤管嬉，及時反思總結(jié)。

以上是我的心得朗鸠，歡迎各位同學(xué)與我交流蚯撩。