前陣子出去玩了一趟，回來(lái)思襯著年度總結(jié)還沒(méi)寫(xiě)症革，就過(guò)來(lái)補(bǔ)了。
回看鸯旁，在ZStack待了1年多噪矛，從30多人到團(tuán)隊(duì)到近百人團(tuán)隊(duì)，從A輪前到B輪展望——有好有壞铺罢，盡收眼里艇挨。一句話概括：我肥了，也變強(qiáng)了韭赘。
今年在內(nèi)部GitLab的Activity記錄（六月的時(shí)候我們從GitHub上切到了GitLab）：
接下來(lái)說(shuō)說(shuō)今年我在工作中意識(shí)到的一些事情吧——可能說(shuō)起來(lái)是有點(diǎn)平淡無(wú)奇缩滨。
自動(dòng)化測(cè)試是最好的保證手段之一
今年2月的時(shí)候，ZStack的bug累積到了一定程度泉瞻。之前的自動(dòng)化測(cè)試框架并不完美脉漏，因難寫(xiě)、跑的慢等原因而坐著冷板凳袖牙。
然后便是老板寫(xiě)出了新的測(cè)試框架侧巨，之后一聲令下，大家開(kāi)始了沒(méi)天沒(méi)地fix bug鞭达。利用新的intergration test司忱，有效的固化了戰(zhàn)果。使原有代碼處于較為穩(wěn)定的狀態(tài)畴蹭，才開(kāi)始快速的feature迭代坦仍。那是1.10的版本。
之后是2.0 UI叨襟，使用了新的框架vuejs繁扎。踩了很多坑，最可怕的是在寫(xiě)的時(shí)候沒(méi)有考慮到怎么去測(cè)糊闽，致使后來(lái)前端一直是開(kāi)發(fā)組的心頭大患锻离。測(cè)試團(tuán)隊(duì)的大量資源也耗損在上面铺峭。如果有自動(dòng)化測(cè)試cover，完全可以省很多資源汽纠。
我之前的創(chuàng)業(yè)小伙伴也向我咨詢(xún)過(guò)如何保證bug不regression卫键。我的答案是：寫(xiě)自動(dòng)化測(cè)試。
- 今天你寫(xiě)了A模塊虱朵，并且手動(dòng)測(cè)試了A模塊的10個(gè)功能...
- 明天你寫(xiě)了B模塊莉炉，并且手動(dòng)測(cè)試了B模塊的20個(gè)功能和A模塊的10個(gè)功能...
- 明天你寫(xiě)了B模塊，并且手動(dòng)測(cè)試了C模塊的40個(gè)功能和B模塊的20個(gè)功能還有A模塊的10個(gè)功能...
- ....
似乎聽(tīng)起來(lái)并不現(xiàn)實(shí)碴犬。這些活只能交給自動(dòng)化測(cè)試——讓機(jī)器來(lái)保證你的功能點(diǎn)是否出現(xiàn)了問(wèn)題絮宁。
編寫(xiě)可擴(kuò)展的代碼——架構(gòu)之美
小伙伴還和我提到過(guò)，項(xiàng)目的迭代速度到一定程度上會(huì)變得非常慢服协。要不就是改一點(diǎn)點(diǎn)就觸發(fā)bug绍昂。
那個(gè)時(shí)候我就開(kāi)始思考了，對(duì)比我現(xiàn)在所在的ZStack偿荷，為什么項(xiàng)目迭代可以這么快窘游？
我翻了很多相關(guān)的書(shū)籍，也看了一些技術(shù)分享跳纳。最后還是回到了平時(shí)自己較為熟悉的ZStack中探索架構(gòu)的秘密忍饰。故而，我寫(xiě)了一個(gè)系列的文章ZStack博文寺庄，其中ZStack源碼剖析：如何在百萬(wàn)行代碼中快速迭代有所提到艾蓝，之后還會(huì)更新上來(lái)一些相關(guān)文章。不得不說(shuō)斗塘，ZStack是我目前碰到過(guò)的大項(xiàng)目里代碼質(zhì)量較高的一個(gè)赢织。
編寫(xiě)可維護(hù)的代碼——Clean Code與重構(gòu)
除了架構(gòu)，還有代碼整潔之道和敢于重構(gòu)馍盟。
代碼整潔有利于后面人的維護(hù)敌厘，減少潛在的人力成本，在此基礎(chǔ)上產(chǎn)生的代碼將會(huì)更加的穩(wěn)定朽合。
而ZStack本身是一個(gè)開(kāi)源的軟件項(xiàng)目俱两，因此對(duì)代碼質(zhì)量要求是偏高的。每一行代碼的輸出都是經(jīng)過(guò)Review的曹步。
重構(gòu)則是一門(mén)藝術(shù)宪彩，在測(cè)試覆蓋率較高的情況下，我們可以盡情的重構(gòu)讲婚，就像藝術(shù)家在他的畫(huà)布上盡情創(chuàng)作一般尿孔。同樣，這也是為了代碼整潔。
再之就是面向接口編程活合，我在關(guān)于設(shè)計(jì)模式有略提到雏婶。
以上三點(diǎn)我在學(xué)生時(shí)代就有所耳聞，但卻沒(méi)有做過(guò)較為完全的實(shí)踐白指。就現(xiàn)在看來(lái)留晚，這些技巧在項(xiàng)目的快速迭代中蘊(yùn)含著巨大的威力。
團(tuán)隊(duì)告嘲、管理與溝通還有效率
我之前工作待過(guò)的技術(shù)團(tuán)隊(duì)人數(shù)一般都是較少的错维，而目前在ZStack技術(shù)人員可能有總?cè)藬?shù)的一半。早期在人數(shù)較少的時(shí)候溝通成本極低橄唬，喊一聲大家就全知道了赋焕。但在人數(shù)多起來(lái)以后是很能做到“全局一致性”的，比如：
- 有些人并不知道這件事發(fā)生了仰楚、某些規(guī)則改變了隆判，所以他還是用之前的方法在做這件事，可能會(huì)做錯(cuò)僧界、或者相對(duì)很慢侨嘀。
- 如果通過(guò)開(kāi)會(huì)來(lái)解決這種問(wèn)題，一些團(tuán)隊(duì)的關(guān)鍵人物真正的產(chǎn)出時(shí)間可能會(huì)減少捎泻，都是在開(kāi)會(huì)sync狀態(tài)。
再者就是管理上的問(wèn)題埋哟，人數(shù)多起來(lái)以后管理難度并不是線性增長(zhǎng)的笆豁。這里面有很多需要細(xì)細(xì)思考的，介于篇幅赤赊，以后有機(jī)會(huì)的話我想詳細(xì)講一講闯狱。
最后是效率——大公司的通病就是瞎忙活，大家看著很忙抛计，其實(shí)產(chǎn)出都很少哄孤，最后就會(huì)變成一只行動(dòng)緩慢的巨獸。而小公司的優(yōu)勢(shì)就體現(xiàn)在行動(dòng)靈活上吹截，然在流程及生產(chǎn)力瘦陈、生產(chǎn)工具落后的情況下優(yōu)先考慮堆人，如果收益是線性對(duì)數(shù)增長(zhǎng)波俄，恐怕成本（時(shí)間+金錢(qián)）就是線性增長(zhǎng)了晨逝。
行業(yè)的重要性
之前提到了成本和收益。這和所在行業(yè)也有很大的關(guān)系懦铺，如果在2018乃至更后捉貌，作為一名程序員還從事在項(xiàng)目型公司（即外包公司），平均待遇相比別的行業(yè)肯定會(huì)低一些，這在相同的工作年限及大樣本看來(lái)即是如此趁窃。同樣牧挣，不同的類(lèi)型的公司有不同高低的瓶頸。堆人堆到了一定程度醒陆，收益和成本便不再是正比成長(zhǎng)瀑构。而且上面也提到了，人多了管理并不好做统求。
最后再說(shuō)學(xué)習(xí)
我看了看去年的年度總結(jié)中定的學(xué)習(xí)目標(biāo)检碗，約有一半是完成的，然而額外也收獲了很多——有些是應(yīng)該被列入計(jì)劃內(nèi)的码邻，有些則是性子來(lái)了順便就上手開(kāi)始了折剃。這應(yīng)了那句話——計(jì)劃趕不上變化。我將不再制定一些詳細(xì)的計(jì)劃像屋，不過(guò)怕犁，前進(jìn)還是永恒的主題。
就是這樣己莺。
附上今年看到的一些好文（當(dāng)然和文章主題相關(guān)）：
