當這個@訊息最終傳遞到當事的工程師手裡，他也需將描述的問題再測試一遍，如果不能重現，問題就變得更加複雜，工程師需要從一堆海量的日誌去定位當時使用者出現這種現象的原因。那一次排查到最後，發現原因是某臺伺服器的返回的資料不對導致，那臺伺服器可能是由於在某些特殊情況下，啟動了一個不同的版本而導致使用者的呼叫不能正常返回。如果你也是一個工程師，是否有幾分熟悉的感覺？
自從工程師鍵入第一行程式碼那一時刻起，開發流程中每個環節都存在出錯的可能。比如
- 程式碼可能未被單元測試覆蓋，當然有更多的團隊根本沒有編寫單元測試的習慣；業務流程未被功能測試覆蓋；因此當終端使用者才發現不正確的問題時（如文首描述的情況），整個技術團隊需要更多的時間去解決。
- 服務之間的呼叫方式、引數或邏輯不正確；當服務由不同的團隊維護時，出錯的概率會更大；另外一個團隊的服務往往只有幾行文字的描述的郵件，很多引數語焉不詳，你需要通過以前的程式碼或者親自呼叫一下來推測這些引數的作用。這時候如果你需要的功能剛好能調通，歡呼之外就是接著提交及釋出程式碼了，因為上面已經開始對你聯調時間過長有些不滿。
- 釋出的版本、配置、順序、伺服器等不正確。儘管大家都覺得有一個上線手冊之類的指導文件，但在實際工作中開發與運維的互動可能會是通過IM工具，開發工程師說，今天上線模組的順序是ABDC，運維工程師雖然對為什麼不是ABCD的這樣的順序有些疑惑，但也依照開發的順序做完了。而下一次上線前，開發工程師沒提及上線順序，運維工程師可能納悶，到底是ABCD還是ABDC呢？
上面種種情況，如果每一次程式碼修改及釋出都依賴每一位工程師的細心及考慮周全的話，則高概率的質量問題不可避免。而工程師則很沮喪的發現經常在解決同一型別的問題。而將全流程更多不易變的單超程式設計標準化，由程式來控制，則可以從源頭上減少問題，讓軟體開發變得簡單及享受。在上面例子中，可以將（1）測試過程標準化。（2）在服務化架構中，將更多的單元標準化。（3）釋出流程標準化。這些點更多的看各團隊工程的成熟程度。團隊中標準化程度越高，軟體的可靠性就會越好，更多的精力將會從各種不確定性問題中解放出來。
說下第2點服務標準化的一個例子，Tim所在團隊最近幾年做的系統密集的使用了訊息佇列，經過幾年的演進，也將各種很複雜的場景實現在系統內，比如多級串聯、並聯、實時性要求非常高的PUB/SUB，用自定義各種服務池來做任務排程，踩了很多坑也積累了很多經驗。但是標準化意識以及抽象能力不足，業務架構與技術架構也缺少分開去考慮，因此大部分系統主要針對自己特定場景的設計去實現，即使有很多有價值的特性，但無法複用到另外的場合。當一些新人去學習Kafka這些系統時，老的架構師也會去反思標準化的問題。當然，3年以上的技術團隊才會有這些感悟，年輕的團隊通常會沉浸在搭建自己系統的快感中。
再說另外一個例子，曾經有一篇技術貼說某個美國的工程師Twitter技術面試失敗的經歷。
然後我們聊了一小會關於在twitter的生活。
我掛掉電話的那一秒我意識到了我的答案是錯的。
……
現在我捫心自問：在這件事我學到了什麼？客觀地說——不多。對於面試官沒有問我正確的問題來引導我向正確的方向思考，我很難過。當我的解答實際上不正確的時候，我不知道為什麼Justin告訴我“這應該有用”。
從中可以部分感受到矽谷科技公司對工程師的嚴格要求。但是國內的情況有所區別，由於網際網路行業有些過熱，合格的人才處於供不應求的情況，因此大部分崗位要求都比上文中描述的要求低。工程師只要具備基本的學習及模仿能力，比如能參考一個現有的軟體能夠實現相同的功能，那這個工程師基本能進入各個網際網路技術崗位（當然表面的工作經歷也是需要的）。
在這種情況下，整個技術群體很難對程式碼質量形成太多共識。再加上大多團隊是業務驅動型（技術驅動的鳳毛麟角），企業對於技術的要求侷限在按時交付。精心雕琢的軟體相比於打補丁修補而成的軟體並不會得到更好的價值體現，因此追求高質量軟體的風氣也不易形成。
企業裡面的軟體可複用還有惡性迴圈的情況，比如某個工程師做了一個公共元件來解決一些公共問題，但是另外一個團隊在使用後發現存在一些問題，理想的情況是，反饋的問題得到了及時修復，解決了各個團隊共性的需求，公共元件在更多場合得到了推廣。但在現實中，具備開發良好公共元件能力的人是非常稀缺的，儘管每個Web開發團隊都有開發一套自己的MVC框架，但在做到優雅的業務實現方面尚有不足的情況下，一廂情願的去做自己的標準元件是較難把握共性的需求及得到使用認可。
在另外一方面，其他的團隊也容易把“那個版本沒有很好的滿足我們需求”的情況成了自起爐灶的理由，通過各自建設，表面上完成了自己的內部需求，自認為團隊內部的認知成本是降低了，但人的精力畢竟有限的，有限的時間只能做好有限的事情，最終各自搭建可能也只能建成一些不可複用的系統，除了短期的自我充實感之外較難有更多的價值。
相關閱讀
評論(1)