苦逼併思考着——個人2017年總結

時間 2019-11-06

標籤思考個人 2017年總結欄目興趣愛好简体版

原文原文鏈接

前陣子出去玩了一趟，回來思襯着年度總結還沒寫，就過來補了。前端

回看，在ZStack待了1年多，從30多人到團隊到近百人團隊，從A輪前到B輪展望——有好有壞，盡收眼裏。一句話歸納：我肥了，也變強了。vue

今年在內部GitLab的Activity記錄（六月的時候咱們從GitHub上切到了GitLab）：

接下來講說今年我在工做中意識到的一些事情吧——可能提及來是有點平淡無奇。程序員

自動化測試是最好的保證手段之一

今年2月的時候，ZStack的bug累積到了必定程度。以前的自動化測試框架並不完美，因難寫、跑的慢等緣由而坐着冷板凳。編程

而後即是老闆寫出了新的測試框架，以後一聲令下，你們開始了沒天沒地fix bug。利用新的intergration test，有效的固化了戰果。使原有代碼處於較爲穩定的狀態，纔開始快速的feature迭代。那是1.10的版本。segmentfault

以後是2.0 UI，使用了新的框架vuejs。踩了不少坑，最可怕的是在寫的時候沒有考慮到怎麼去測，導致後來前端一直是開發組的心頭大患。測試團隊的大量資源也耗損在上面。若是有自動化測試cover，徹底能夠省不少資源。設計模式

我以前的創業小夥伴也向我諮詢過如何保證bug不regression。個人答案是：寫自動化測試。架構

今天你寫了A模塊，而且手動測試了A模塊的10個功能...
明天你寫了B模塊，而且手動測試了B模塊的20個功能和A模塊的10個功能...
明天你寫了B模塊，而且手動測試了C模塊的40個功能和B模塊的20個功能還有A模塊的10個功能...
....

彷佛聽起來並不現實。這些活只能交給自動化測試——讓機器來保證你的功能點是否出現了問題。框架

編寫可擴展的代碼——架構之美

小夥伴還和我提到過，項目的迭代速度到必定程度上會變得很是慢。要不就是改一點點就觸發bug。工具

那個時候我就開始思考了，對比我如今所在的ZStack，爲何項目迭代能夠這麼快？學習

我翻了不少相關的書籍，也看了一些技術分享。最後仍是回到了平時本身較爲熟悉的ZStack中探索架構的祕密。故而，我寫了一個系列的文章ZStack博文，其中ZStack源碼剖析：如何在百萬行代碼中快速迭代有所提到，以後還會更新上來一些相關文章。不得不說，ZStack是我目前碰到過的大項目裏代碼質量較高的一個。

編寫可維護的代碼——Clean Code與重構

除了架構，還有代碼整潔之道和勇於重構。

代碼整潔有利於後面人的維護，減小潛在的人力成本，在此基礎上產生的代碼將會更加的穩定。

而ZStack自己是一個開源的軟件項目，所以對代碼質量要求是偏高的。每一行代碼的輸出都是通過Review的。

重構則是一門藝術，在測試覆蓋率較高的狀況下，咱們能夠盡情的重構，就像藝術家在他的畫布上盡情創做通常。一樣，這也是爲了代碼整潔。

再之就是面向接口編程，我在關於設計模式有略提到。

以上三點我在學生時代就有所耳聞，但卻沒有作過較爲徹底的實踐。就如今看來，這些技巧在項目的快速迭代中蘊含着巨大的威力。

團隊、管理與溝通還有效率

我以前工做待過的技術團隊人數通常都是較少的，而目前在ZStack技術人員可能有總人數的一半。早期在人數較少的時候溝通成本極低，喊一聲你們就全知道了。但在人數多起來之後是很能作到「全局一致性」的，好比：

有些人並不知道這件事發生了、某些規則改變了，因此他仍是用以前的方法在作這件事，可能會作錯、或者相對很慢。
若是經過開會來解決這種問題，一些團隊的關鍵人物真正的產出時間可能會減小，都是在開會sync狀態。

再者就是管理上的問題，人數多起來之後管理難度並非線性增加的。這裏面有不少須要細細思考的，介於篇幅，之後有機會的話我想詳細講一講。

最後是效率——大公司的通病就是瞎忙活，你們看着很忙，其實產出都不多，最後就會變成一隻行動緩慢的巨獸。而小公司的優點就體如今行動靈活上，然在流程及生產力、生產工具落後的狀況下優先考慮堆人，若是收益是線性對數增加，恐怕成本（時間+金錢）就是線性增加了。

行業的重要性

以前提到了成本和收益。這和所在行業也有很大的關係，若是在2018乃至更後，做爲一名程序員還從事在項目型公司（即外包公司），平均待遇相比別的行業確定會低一些，這在相同的工做年限及大樣本看來便是如此。一樣，不一樣的類型的公司有不一樣高低的瓶頸。堆人堆到了必定程度，收益和成本便再也不是正比成長。並且上面也提到了，人多了管理並很差作。