工程師效率

文/Tim Yang

很好奇程序員這個群體這些年效率是變低了還高了，在社交媒體中，各個階層的興趣圈都有自己的段子手及內容帳號，段子手發的內容會讓你笑 cry，內容帳號發的內容可讓你享受閱讀的快感，這些快感會比寫代碼見效快。寫完一個模塊的代碼通常要一整天或者幾天時間，代碼調通運行沒有問題才會體驗到愉悅，而社交媒體只需要一些碎片時間就可以達到高潮。相較之下高低立判。而據說這種讓大腦愉悅的神經元連接方式一旦新連上就非常穩固，結果就是讓人欲罷不能，這樣當他在寫代碼的時候，大腦會下意識的切換去刷下微博及朋友圈。只要不是最后交付關頭，總是有彈性的空間去干點別的，因此這些效率的損耗連自己也無法得知。

但在另外一個方面，資訊流動加快，在一定程度上導致社區中優秀軟件的復用程度提高。幾年前還記得 NoSQL 遍地開花，每個公司里面也都有一個 PHP MVC 框架之類。慢慢的跟社區版本一比較之后，業界百花齊放的現象就慢慢消停了。這幾天在看一些技術會議的 slide，發現大部分內容已變成各種開源軟件的技術選型技巧，不知是否矯枉過正了。協作程度的提高，也可以視為軟件已經逐漸邁向工業社會，有了真正意義的上下游，形成了分工與合作。從這個角度來講，工程師只需要在自主研發還是拿來主義之間做個選擇題，從整體的角度來說，研發效率就得到了提升，視野的提升彌補了 coding 下降帶來的效率問題。

影響工程師效率還有一個因素是來自大公司里的流程，由于“全棧工程師”還沒得到廣泛的理解及接受，因此不同棧之間的工程師之間新開發的模塊，存在一個聯調的過程，如果他們屬于不同的部門，則聯調的周期會更長。軟件開發完成到上線之前，還需要經過測試部門的測試。因此，即使在代碼中加個空格，有時候也需要一周的時間才能到線上。

大型系統中還存在模塊耦合的問題，由于多個模塊由不同的人員及部門維護，因此給調試及持續集成帶來很大的挑戰。不少公司中很多代碼只能做單個模塊的測試及集成，由于依賴復雜，測試環境很難搭建，最后只有線上才有一個包含所有模塊的運行環境，因此一段代碼如果要依賴上下游才能驗證正確性，則只有等到上線后才能判斷是否存在 bug。