入職Apifox研發(fā)組三個(gè)月，我領(lǐng)悟了30個(gè)高效開(kāi)發(fā)方法

?? 前言
從去年入職Apifox研發(fā)組至今，已經(jīng)有快「四個(gè)月」的時(shí)間了，今天來(lái)跟大家分享一下我的感想??。
寫這篇文章的契機(jī)是在年后我成功通過(guò)「三個(gè)月試用期」，也算是給自己一個(gè)交代，從自身出發(fā)來(lái)進(jìn)行反思與總結(jié)在這「三個(gè)月」學(xué)到的東西與一些感想???。
?? 我學(xué)會(huì)了什么
在這「三個(gè)月內(nèi)」我更多接受到的是工作或者說(shuō)是寫代碼甚至作為程序員「應(yīng)該掌握的方法」，而這些方法「不在于」你是什么技術(shù)?；蛘哒f(shuō)什么職位都很有用??，所以今天我就來(lái)分享一些我總結(jié)的30個(gè)方法,我主要分成??代碼方面和??程序員方面。
?? 代碼方面



學(xué)會(huì)表達(dá)
當(dāng)你在寫一個(gè)復(fù)雜的表達(dá)式甚至需要用到這些表達(dá)式來(lái)做判斷的時(shí)候，這時(shí)候要養(yǎng)成一個(gè)習(xí)慣把表達(dá)式換成一個(gè)變量來(lái)表示??，別人才能語(yǔ)義化的理解你這個(gè)表達(dá)式。
自己寫的代碼不管你寫的再?gòu)?fù)雜你自己都可以看懂，但是對(duì)于別人不同，如果你把你的這些表達(dá)式賦值給一個(gè)變量,「這樣別人只需要知道這個(gè)變量是什么意思就行了」。
學(xué)會(huì)復(fù)盤
中級(jí)與高級(jí)的程序員有一個(gè)差別是，優(yōu)秀程序員肯定至少會(huì)花一些時(shí)間來(lái)「清理??自己的代碼」。
這么做是因?yàn)?，他們知道整潔好看的代碼比雜亂無(wú)章的代碼更容易修改，「甚至他們知道自己幾乎無(wú)法一開(kāi)始就寫出整潔的代碼????」。
雖然我自己也沒(méi)有完全嚴(yán)苛遵守，但是還是希望大家多去復(fù)盤，因?yàn)楫?dāng)你去看了你之前寫的代碼后你會(huì)發(fā)現(xiàn)很多樂(lè)趣（覺(jué)得自己寫的代碼可笑??）。
擁抱變化
永遠(yuǎn)都不要說(shuō)我寫的功能 「"總是滿足我們的需求"」 ，在做項(xiàng)目開(kāi)發(fā)特別是公共模塊，你要學(xué)會(huì)「擁抱變化」??， 永遠(yuǎn)要考慮變化的情況。
養(yǎng)成一個(gè)習(xí)慣，在做一個(gè)公共模塊的時(shí)候要考慮后面有沒(méi)有實(shí)現(xiàn)變化的可能或者能不能封裝成一個(gè)js模塊??，而不是直接用第三方庫(kù)?。
特別是我們是做客戶端而不是簡(jiǎn)簡(jiǎn)單單的單頁(yè)網(wǎng)頁(yè)，而這里的公共模塊指的是 「"使用者只用用到你的提供出來(lái)的API就知道怎么用了，并不需要使用者去考慮里面的實(shí)現(xiàn)"」
學(xué)會(huì)修BUG
很多人在接到一個(gè)BUG需求的時(shí)候經(jīng)常只關(guān)注 「"眼前"」 ，即只關(guān)注遇到的問(wèn)題而沒(méi)有考慮其原本的意義。
你要做的其實(shí)不止是修改好這一個(gè)「缺陷」而是要去思考??為什么他會(huì)出現(xiàn)這個(gè)「缺陷」，一定要關(guān)注上下文。
在修改一個(gè)舊的模塊引發(fā)的BUG的時(shí)候,我們要保證不影響原來(lái)的功能邏輯，考慮清楚再commit，否則就會(huì)出現(xiàn)經(jīng)常遇到的  「"改了BUG生成另一個(gè)BUG??"」 。
多用結(jié)構(gòu)化數(shù)據(jù)
在你所做的一個(gè)組件邏輯「很復(fù)雜」的時(shí)候，更要考慮清楚它的結(jié)構(gòu)，「多用結(jié)構(gòu)化數(shù)據(jù)」，定義一個(gè)數(shù)據(jù)結(jié)構(gòu)來(lái)存儲(chǔ)中間狀態(tài)，而不應(yīng)該永遠(yuǎn)用簡(jiǎn)單的狀態(tài)?。
「所有復(fù)雜的組件你的狀態(tài)復(fù)雜是可以接受的，但是有多個(gè)狀態(tài)是不可接受的」。
因?yàn)槿绻髅骺梢杂媒Y(jié)構(gòu)化狀態(tài)來(lái)存儲(chǔ)，反而用多個(gè)狀態(tài)組合實(shí)現(xiàn)的話，你這個(gè)組合關(guān)系就很復(fù)雜了。
確定一個(gè)你所需要的數(shù)據(jù)結(jié)構(gòu)，「所有的操作都以這個(gè)數(shù)據(jù)結(jié)構(gòu)為目標(biāo)」，這個(gè)數(shù)據(jù)結(jié)構(gòu)可以是一個(gè)對(duì)象可以是一個(gè)數(shù)組任何你期望的值，這樣最后只需要拿到這個(gè)結(jié)構(gòu)化數(shù)據(jù)來(lái)進(jìn)行簡(jiǎn)單處理，所有的問(wèn)題都迎刃而解了。
不要怕錯(cuò)
很多人包括我自己在進(jìn)入一個(gè)新的公司或者面對(duì)一個(gè)別人正在開(kāi)發(fā)的項(xiàng)目難免都會(huì)有一個(gè)問(wèn)題：「"不夠自信"」 。
在看到別人的代碼時(shí)候難免會(huì)看見(jiàn)別人明顯的錯(cuò)誤，而在當(dāng)下你看來(lái)可能對(duì)自己編碼不自信而不愿意幫忙改正，又怕改了之后被同事責(zé)怪，但這是不對(duì)的?。
不要怕改錯(cuò)代碼，「如果在當(dāng)時(shí)看到一個(gè)錯(cuò)誤或者命名不規(guī)范而你覺(jué)得有更好的名字或者重構(gòu)方法可以及時(shí)改正」，就算是改錯(cuò)了那就在CodeReview的時(shí)候提出來(lái)讓大家提建議。
這樣在下次見(jiàn)到這段代碼時(shí)就不要重復(fù)努力搞懂邏輯，因?yàn)楹芸赡芟麓芜€會(huì)是你繼續(xù)改動(dòng)這個(gè)模塊。
每次只關(guān)心一個(gè)上下文
如果某個(gè)模塊經(jīng)常因?yàn)椴煌脑蛟诓豢深A(yù)知的方向上發(fā)生變化，那么這個(gè)模塊就變的很散亂了。
當(dāng)你需要在原有基礎(chǔ)上根據(jù)一種條件新增功能的時(shí)候，我可能需要更改三個(gè)函數(shù)，兩個(gè)變量，這樣的話就會(huì)很煩躁了，在如今這么內(nèi)卷的時(shí)代再煩躁起來(lái)得有多難受??。
我們要養(yǎng)成一種習(xí)慣每個(gè)函數(shù)只干一件事情，「將一個(gè)功能按照不同模塊劃分開(kāi)來(lái)」，分成數(shù)個(gè)上下文而每次我們修改功能的時(shí)候只需要找到對(duì)應(yīng)的模塊來(lái)修改就很清晰了，我們只需要關(guān)注那一個(gè)上下文就可以了。
消滅注釋
盡可能少的添加注釋，特別是團(tuán)隊(duì)開(kāi)發(fā)，有很多人不理解為什么？??我舉個(gè)最簡(jiǎn)單的例子:「如果這個(gè)函數(shù)以后功能變了,除了我們需要改里面的代碼還需要幫忙改變函數(shù)命名還要一起把之前的注釋也改了」，假如一個(gè)函數(shù)有「5-6行」注釋這么多，那你是不是每個(gè)都要改？
當(dāng)然在不添加注釋的前提下我們要保證我們函數(shù)命名變量命名「盡可能語(yǔ)義化」????。
任何你覺(jué)得需要注釋的地方，99%是因?yàn)檫@段代碼不合理。
每當(dāng)你需要用注釋來(lái)說(shuō)明什么的時(shí)候，我們要做的不是用文字去解釋這段代碼，「而是把我們需要說(shuō)明注釋的東西寫進(jìn)一個(gè)獨(dú)立函數(shù)，并以它的用途取個(gè)語(yǔ)義化的名字?」。
甚至我們可以用短短幾行的小函數(shù)來(lái)代替這件事情，哪怕之后調(diào)用函數(shù)的步驟變多，但是只要每個(gè)函數(shù)命名足夠語(yǔ)義化，就能用代碼合理的解釋你想要做的一切。
函數(shù)的長(zhǎng)度關(guān)鍵不在于有多長(zhǎng)而是在于可讀性，「在于"??如何做 "和"??做些什么"」 。
不畏注釋
我們通過(guò)上面的方法可以有效的減少在代碼內(nèi)的注釋但是對(duì)于別人已經(jīng)遺留的注釋我們應(yīng)該置之不理嗎？
如果在修改的功能模塊發(fā)現(xiàn)原來(lái)存在注釋，不要去抱怨，這對(duì)你沒(méi)有一點(diǎn)好處，「相反的這可能是個(gè)很好的信號(hào)去告知我們應(yīng)該去對(duì)這段代碼進(jìn)行修改」，而通過(guò)這些注釋可以精準(zhǔn)的幫我們定位到他的問(wèn)題所在。
學(xué)會(huì)命名
如果在編寫一個(gè)函數(shù)的時(shí)候你無(wú)法對(duì)其進(jìn)行命名，「那么這個(gè)函數(shù)多數(shù)是設(shè)計(jì)不合理的」，就像我們上面提到的，函數(shù)里面表達(dá)的是 「"如何做"和"做些什么"」 ，而我們對(duì)函數(shù)的命名也切記按照這個(gè)原則。
當(dāng)你真正對(duì)一個(gè)函數(shù)準(zhǔn)確命名，那么這里面的結(jié)構(gòu)往往是「可讀性高」的。
做任何業(yè)務(wù)都「不要把實(shí)現(xiàn)寫在函數(shù)名」上，以后如果別人需要改動(dòng)函數(shù)邏輯，還要幫你把函數(shù)名字給改動(dòng)了。
合理入?yún)?br>對(duì)于攜帶參數(shù)的函數(shù)的命名也是有講究的，我們通?！缚梢允褂猛ㄓ玫拿謥?lái)代表參數(shù)命名」而不是使用在當(dāng)下具體的名稱，比如：「apiSelectedKey=>selectedKey」
修改的好不僅能增加函數(shù)的應(yīng)用范圍，還能改變連接一個(gè)模塊所需的條件，從而去除不必要的耦合。
學(xué)會(huì)提煉函數(shù)
在簡(jiǎn)化代碼塊的時(shí)候，我們最喜歡的就是提煉函數(shù)，「提煉函數(shù)可以讓我們將意圖與實(shí)現(xiàn)分開(kāi)」。
并以意圖命名函數(shù)，但是如果發(fā)現(xiàn)自己并不能合理命名，說(shuō)明你不應(yīng)該提煉這個(gè)函數(shù)?????，你應(yīng)該考慮更多。
學(xué)會(huì)返回
上面講了兩個(gè)關(guān)于函數(shù)命名的方法，而往往在小函數(shù)內(nèi)我們對(duì)于內(nèi)部的變量會(huì) 「"詞窮"」 。
大部分的函數(shù)都可以使用result作為返回值，在函數(shù)開(kāi)頭定義，在函數(shù)結(jié)尾return，這樣下次看這段代碼的人一下就知道要返回的是什么??。
考慮時(shí)機(jī)
往往我們剛拿到一個(gè)新需求的時(shí)候很容易去實(shí)現(xiàn)它的功能，甚至不會(huì)去調(diào)研，修改BUG也是如此。
這是很容易的，任何一個(gè)程序員都可以做到，但是在什么時(shí)機(jī)做這個(gè) 「"動(dòng)作"」 是應(yīng)該考慮清楚的，點(diǎn)擊的時(shí)候？依賴變化的時(shí)候？函數(shù)返回的時(shí)候？
我就吃過(guò)這個(gè)虧，「在不恰當(dāng)?shù)拇a恰好完成了需求但是引發(fā)了一些不可控的缺陷」，導(dǎo)致我要重復(fù)讀這整個(gè)模塊的代碼，不僅拖慢了項(xiàng)目進(jìn)度還讓自己多掉了幾扎頭發(fā)??。
保持可拓展性
在拿到一個(gè)新需求的時(shí)候永遠(yuǎn)永遠(yuǎn)不要想著做完就ok，因?yàn)槟銦o(wú)法保證以后會(huì)不會(huì)讓你在這個(gè)基礎(chǔ)上增加新的功能甚至在你commit后的一個(gè)小時(shí)，產(chǎn)品的需求如果你沒(méi)有優(yōu)秀的產(chǎn)品思維是捉摸不透的??，所以要給自己留  「"一條后路"」 。
而這而最常見(jiàn)的無(wú)非就是各種判斷，根據(jù)不同的判斷來(lái)讓程序走不同的代碼，這時(shí)候我們不能寫死判斷而是多去使用map結(jié)構(gòu)來(lái)保持功能可拓展性??。
巧用模塊
如果你發(fā)現(xiàn)兩個(gè)模塊之間「需要交流」，或許你可以新建一個(gè)模塊??來(lái)存放。
在做一個(gè)需求的時(shí)候，如果很多函數(shù)跟變量都是「從不同的第三方庫(kù)引入」，這時(shí)候不妨把它歸為一個(gè)模塊，「就算是函數(shù)變量名字一摸一樣都可以」。
只要保證是在這個(gè)模塊里面導(dǎo)出就可以，這樣后面的人更加方便維護(hù)這個(gè)模塊，屏蔽這個(gè)實(shí)現(xiàn)。
「使用的人不關(guān)心用，只關(guān)心結(jié)果」，就類似中間層??。





?? 程序員方面
巧用方法
有很多人想入行這個(gè)行業(yè)，「他要學(xué)的就是方法」，就比如說(shuō) 「《重構(gòu)》」，「《代碼整潔之道》」 這些書講的都是方法，教的就是方法??。
你一個(gè)架構(gòu)師寫的代碼好，去到一個(gè)新的項(xiàng)目怎么提現(xiàn)他的作用，還是「因?yàn)樗姆椒ê?，而不是他寫過(guò)的代碼有多好」。
「只有你的方法好，你后面新產(chǎn)出的代碼才會(huì)好」。
擇善而從
當(dāng)你覺(jué)得你在做重復(fù)的工作的時(shí)候，「一定是你做的方式不對(duì)，而不是這個(gè)任務(wù)不對(duì)」。
你任何一個(gè)任務(wù)都有可學(xué)習(xí)的地方，「我們做的是腦力活動(dòng)，不存在像搬磚那樣的情況」，一定會(huì)有更好的方案，只是你沒(méi)有發(fā)現(xiàn)??。
你可以通過(guò)研究別人的app看很多的源碼，看別人的相同效果是怎么做的，「擇善而從自己去實(shí)現(xiàn)一個(gè)新的方案」。
「當(dāng)你實(shí)現(xiàn)完了之后，你就是這種功能的大神」，以后再去面試別人公司的時(shí)候，你就說(shuō)你在之前的公司，做了xxx功能的方案，吸收了業(yè)界很多類似xxx功能方案的長(zhǎng)處，別人就會(huì)覺(jué)得你很牛逼，但是如果你只是說(shuō)你之前重復(fù)的做xxx功能的某些事情那別人直接就把你刷掉了??。
學(xué)會(huì)參考
「作為程序員就是要不斷看別人的代碼??」，哪種代碼寫得好，哪種寫得不好，哪些是值得去參考的，「自己心里要有一個(gè)底」，如果你不確定這個(gè)好不好，你就百度、谷歌、看源碼。
API設(shè)計(jì)的過(guò)程中除非你是經(jīng)驗(yàn)豐富的人，否則就得學(xué)會(huì)參考，任何一個(gè)程序員入門的方式都是抄襲，看別人怎么實(shí)現(xiàn)看別人代碼怎么寫。
「一個(gè)入門程序員、一個(gè)中級(jí)程序員一上來(lái)就給你設(shè)計(jì)一套很舒服的API這是不可能的??」,參考開(kāi)源大佬的項(xiàng)目,參考別人設(shè)計(jì)的時(shí)候?yàn)槭裁催@么做,不能自己純想。
產(chǎn)品思維
「有產(chǎn)品思維是好的，能理解產(chǎn)品需求，能與產(chǎn)品進(jìn)行有效溝通這是優(yōu)勢(shì)」。
這時(shí)候你就需要學(xué)會(huì)「跳出程序員的維度，擁有多學(xué)科交叉的能力??」，要去「了解」產(chǎn)品「提這個(gè)需求的目的」，因?yàn)樵跊](méi)了解的情況下，你按照自己的產(chǎn)品思維去認(rèn)為這個(gè)需求的不同會(huì)導(dǎo)致想法過(guò)度或不及。
在不了解的情況下要多與產(chǎn)品交流，一定不要自己想當(dāng)然，當(dāng)你覺(jué)得應(yīng)該怎么去做，「可以帶方案去找產(chǎn)品討論」。
適當(dāng)做減法
你要想把一個(gè)需求做到100分可能是很難的，但是對(duì)于用戶來(lái)說(shuō)這個(gè)需求可能做到60分已經(jīng)不錯(cuò)了,「剩下的40分就需要跟產(chǎn)品溝通什么時(shí)候把它做到100分??」。
這也是所謂的什么時(shí)候該干什么樣的事情，現(xiàn)階段你做起來(lái)可能會(huì)很吃力花費(fèi)很多時(shí)間，但或許2個(gè)月后的你來(lái)改這段代碼輕而易舉。
學(xué)會(huì)做需求
「接到一個(gè)新需求要列方案、調(diào)研????」，方案有很多種，看起來(lái)都很可行，但是實(shí)際上合不合適還是需要調(diào)研??，否則做到一半后就要重新更換方案，不然就只能在產(chǎn)品上做妥協(xié)。
在明確了自己的方案并有一種想法的時(shí)候，「多去嘗試，嘗試使用它」。如果后來(lái)發(fā)現(xiàn)不太合適，完全可以再重來(lái) 完全沒(méi)有問(wèn)題，「只要在里面學(xué)到了東西，時(shí)間就不會(huì)白費(fèi)」。就算你覺(jué)得不穩(wěn)妥，在CodeReview提出來(lái)，自然會(huì)被指出錯(cuò)誤。
當(dāng)然我們?cè)谧鲆粋€(gè)需求的時(shí)候「不能局限于這個(gè)需求」，也就是我上面有提到的保持可拓展性，眼光要放長(zhǎng)遠(yuǎn)，以后可能還會(huì)有人會(huì)用到你寫的API。
學(xué)會(huì)問(wèn)問(wèn)題
養(yǎng)成一個(gè)習(xí)慣，當(dāng)你要問(wèn)人問(wèn)題的時(shí)候，要知道每個(gè)人溝通能力不一樣的，當(dāng)你達(dá)到一種水平，覺(jué)得你能幾句話能把一個(gè)問(wèn)題說(shuō)的很清晰，你可以不寫，「如果你覺(jué)得你沒(méi)有那個(gè)水平，你要寫一下你的文字然后發(fā)給別人」，溝通協(xié)調(diào)能力也是在職場(chǎng)中需要鍛煉的??。
很多時(shí)候你不能靠問(wèn)，你必須要帶方案，「如果你靠問(wèn)別人給了你方案，那永遠(yuǎn)都是別人教你寫代碼」。
如果你自己帶了方案，別人覺(jué)得方案不錯(cuò)，或者別人有更好的會(huì)提出來(lái)，當(dāng)然別人花30s提出來(lái)的方案肯定不是最佳的，這是你負(fù)責(zé)的模塊，你熟悉的邏輯，你想出來(lái)的方案肯定會(huì)更好，要在此抉擇。
多用快捷鍵
花時(shí)間去看快捷鍵，千萬(wàn)不要在CodeReview或者技術(shù)分享會(huì)的時(shí)候找文件點(diǎn)來(lái)點(diǎn)去，在平時(shí)就要「養(yǎng)成追求"快"」 的習(xí)慣
一段時(shí)間干好一件事
這個(gè)點(diǎn)我以前一直都在提到，任何事情你都無(wú)法做到完美兼顧，「你要知道一段時(shí)間內(nèi)能把一件事情干好就已經(jīng)很不錯(cuò)了」。
如果你現(xiàn)在想要換工作，那就安心復(fù)習(xí)準(zhǔn)備面試，如果你要學(xué)某個(gè)技術(shù)，那就圍繞著它一直學(xué)，你可以給自己定個(gè)時(shí)間，「一個(gè)月？?jī)蓚€(gè)月？半年？??」 沒(méi)有關(guān)系，只要你在這段時(shí)間內(nèi)用心去做了，時(shí)間會(huì)給你答案。
動(dòng)手前提
在做公共業(yè)務(wù)和普通頁(yè)面當(dāng)你需要用到一個(gè)第三方庫(kù)的時(shí)候，中級(jí)和高級(jí)的有一個(gè)差別是 高級(jí)要「先大概把文檔過(guò)一遍」，這樣當(dāng)你「遇到問(wèn)題了可以快速定位」，「而不是遇到問(wèn)題了再去找，再去看源碼」。
這樣不會(huì)花費(fèi)很多很多時(shí)間，如果當(dāng)你看文檔的時(shí)候卡住了，你可以選擇嘗試看別人總結(jié)好解析好的的文章??，說(shuō)不定就幫你解決了問(wèn)題，要記住看文章永遠(yuǎn)是比看源碼快的。
快速定位問(wèn)題
當(dāng)你遇到一個(gè)BUG的時(shí)候一定要思考，不能莽做，縷清前因后果，思考為什么會(huì)引發(fā)這樣的現(xiàn)象。
最合適的解決問(wèn)題的路徑是：「看上下文->看issue->看文檔->看文章->看源碼」。
? 時(shí)間不知不覺(jué) 我們后知后覺(jué)
一生或許只是幾頁(yè)，不斷在修改和謄抄著的詩(shī)稿，從青絲到白發(fā)，有人還在燈下。——席慕蓉

誰(shuí)說(shuō)不是呢？「時(shí)間如流水，一去不復(fù)返」，認(rèn)真過(guò)好每一天也是我們力所能及的事情了。
「在漫漫程序員歷史長(zhǎng)河中，幾個(gè)月不過(guò)是浪花一朵」，學(xué)會(huì)時(shí)間管理對(duì)我們也極其重要。
我特別喜歡我老大的一句話：「"如果你是我招進(jìn)來(lái)的而在你出去后你沒(méi)有任何提升，我覺(jué)得我自己是失職的"」
在這「三個(gè)月」的時(shí)間里我「大多數(shù)的時(shí)間都花在了熟悉公司業(yè)務(wù)和代碼規(guī)范上面」，在開(kāi)始我深知我對(duì)未嘗試的技術(shù)棧的不熟，對(duì)產(chǎn)品的不熟，再到后面逐漸熟練使用，我覺(jué)得對(duì)我自己成長(zhǎng)真的不是一星半點(diǎn)??。
這里的小伙伴真的是把一個(gè)產(chǎn)品當(dāng)成自己的寶貝，細(xì)心呵護(hù)用規(guī)范的代碼澆灌成長(zhǎng)，我在大學(xué)當(dāng)模特隊(duì)隊(duì)長(zhǎng)的時(shí)候也一直在跟隊(duì)員強(qiáng)調(diào)：我們能夠在一起 「不是因?yàn)槲?，不是因?yàn)槟悖皇且驗(yàn)樗?，而?我們"」 ，只有我們達(dá)成了這種共識(shí)，才會(huì)越走越長(zhǎng)遠(yuǎn)??????。
除了平時(shí)自愿留在公司學(xué)習(xí)，一周我會(huì)花一個(gè)晚上的時(shí)間回家整理CodeReview提到的點(diǎn)，也會(huì)抽兩天早點(diǎn)回家看看書寫寫文，畢竟勞逸結(jié)合才是最好嘛。
我從來(lái)沒(méi)說(shuō)過(guò)我技術(shù)有多好，甚至我覺(jué)得我的技術(shù)跟很多人比起來(lái)差遠(yuǎn)了，可能屏幕前的你能夠感同身受，「時(shí)間不停，我們當(dāng)然也不能停滯不前」。
很多人都說(shuō)「面試造火箭工作擰螺絲」，但是實(shí)際上工作中確實(shí)會(huì)造火箭，就比如我們，做的都是很有意思的事情，一群人都會(huì)忘乎所以的去往一個(gè)方向去做去成長(zhǎng)，「但是在造火箭??的途中難免會(huì)擰一下螺絲??」，這時(shí)候我們就需要知道用什么螺絲，框架的底層是什么，做了什么就很重要了。
以上我所總結(jié)的方法都是這三個(gè)月切切實(shí)實(shí)學(xué)到的，「無(wú)論是在書里還是在工作中，基本上每一個(gè)方法都對(duì)應(yīng)一個(gè)小故事」，這些我完完全全可以拆分成30篇文章來(lái)寫，但是還是毫無(wú)保留的寫出來(lái)了，如果大家對(duì)小故事感興趣的話以后我也可以分享出來(lái)??。

作者：快跑啊小盧


歡迎關(guān)注微信公眾號(hào) ：前端快快跑