也算機緣巧合，一個不能稱之為機會的機會讓我再次和國外現在炙手可熱的F
公司(
由于也不想過多的說這家公司的名字，因此就用F
作為代號了)
做了一次技術和公司文化的簡單交流，這里做個簡單的交流分享，希望能夠讓更多的朋友能夠從中找到自己團隊或者公司有幫助的內容。但這里還是丑話說在前頭，中國有句成語：東施效顰。國外的月亮多圓我不知道，但是我們需要客觀的看待不同環境的差異，看到目標，而不要過多模仿過程。下面的闡述將都分成場景和觀點，如何做三部分，場景描述了具體的情況，觀點僅僅代表我自己的一些感觸和理解，如何做是對問題Action
提出自己的想法。
場景1：
F公司的任何一個小Team（業務上劃分或者職能上劃分）都需要熟悉整個系統從前到后從上到下的代碼實現。例如相冊團隊，從前端腳本，到業務邏輯，再到底層的Memcached或者圖片服務器代碼在必要的時候都能自己修改和實現業務需求。UserGroup團隊是負責對全球業務的用戶做統計分析的，當希望做一些變革能夠嘗試著提升用戶轉化率的時候，首先是考慮自己如何動手去修改已有系統的功能，而不是去協調各個團隊去做。
觀點：
垂直化的開發模式其實挑戰了國內很多企業的橫向細分化流水線方式的開發模式。從技術的橫向細分，到業務的模塊化細分，好處是提高企業的生產效率，壞處是對人全方面的培養成為一種制約。最大的問題：對自己上游系統的需求了解不透徹，對自己依賴系統的實現完全不理解。
如何做：
橫向切分的方式和縱向的方式都有適應的場景，因此可以考慮在互連網企業中部分部門中實施垂直化開發模式，這些部門人員素質較高，能夠從產品層面全局的考慮整體的發展，通過實際的參與各個業務線和各個層次的技術中間件開發，為橫向切分的部門工作做出改進和建議。這樣在高素質人才發展和網站規模化整體化發展之間找到平衡點，相互促進。
場景2：
F公司的任何一個技術框架都可以被挑戰和替換，只要用數字和測試結果作為有效的證據，大家都抱著對公司負責的態度來對待技術選型。因此在F公司中，技術的發展完全是最原始的優勝劣汰機制。
觀點：
這點其實很贊同，首先技術如果不是用數據來說話，采用自上而下的方式來決定選型，那么就是拍腦袋做事情。另一方面，如果技術不持續的按照用戶需求來優化和演進，那么一定會爛掉，最好的觸動不斷發展的方式，就是競爭。有人會擔心技術競爭會帶來資源消耗，其實爛掉的東西在被使用的過程中一樣在消耗。
如何做：
首先當然還是提倡積累，能夠在已有的技術基礎上不斷積累發展是最好的，其次也應該鼓勵創新，如果有足夠理由證明成熟的技術能夠替代現有技術，而現有技術又沒有發展的動力時，變革并不是壞事（也許這種壓力就會迫使原有技術實現者去更好服務客戶），最后就是給每個人都有改變任何一部分代碼的能力，因為依賴的不穩定也決定了上層系統的不穩定，作為一個產品來看，每個人是對產品負責，而不是對一個組件負責。
場景3：
沒有任何文檔。最多寫一點wiki。
觀點：
設計從簡，代碼需要更優雅，注釋需要更全面。文檔是代碼的骨架。
如何做：
應該有產品需求文檔，理解業務需求。技術文檔多半是總體性設計和一些協議描述，多一些代碼注釋和Demo，更利于學習和閱讀。
場景4：
應用都被編譯在一個包里，一臺機器就運行了諾大一個網站的所有功能，不存在服務器間的應用服務調用，都是本地服務方法調用（服務依賴較少）。
觀點：
這和Java類型的應用還有些差別，Java的第三方依賴較多，版本凌亂復雜，導致應用部署在一臺機器上很困難。但很多大型網站的系統設計慢慢地就將模塊分的很細，結果導致服務調用和依賴特別復雜，自身的可用性和穩定性變得難以估量。
如何做：
需要審視服務粒度的合理性及垂直化設計在不同系統中的應用，需要在可擴展和可用性及效率中差別對待不同系統設計，同時降低服務差異性，減少應用服務器由于應用差異導致無法復用的問題。
場景5：
任何一個應用或者中間件開發完成后，都會有一個監控應用伴隨誕生。（有些是直接通過已有工具實現，有些獨立實現）
觀點：
1：1的透明化開發比unit test來的還要重要，因為運行期的系統透明化是業務分析，系統優化，系統監控告警最基本的要求。
如何做：
最低代價就是將監控數據記錄打點，應用或者外部系統對數據進行計算和分析，最終提供結果給外部系統展現和處理。
場景6：
沒有測試團隊，任何開發都是測試人員，通過工具完成頁面，接口，集成測試。
觀點：
強大的測試工具框架為開發人員提供了測試的規范性和便利性，同時開發人員自身的責任感增強，也讓開發人員在測試過程中總結和思索開發設計的常規性錯誤，理解邊界問題。
如何做：
需要有專人專職來負責測試框架的有效性，當然對于這個人或者這么一個小團隊來說要求很高。可以借鑒的是，測試團隊應該有更加高效的方式自動化測試，同時應該將測試框架開放給開發人員，增強開發人員對產品質量的責任感。
場景7：
沒有線下的壓力測試和極限測試，線上引流和部分區域發布來做測試。
觀點：
一直認為線下的網絡環境，用戶數據的仿真度都難以模擬線上，因此很多壓力測試和極限測試的數據基本就不能成為依據。在數據透明化體系完成后，線上的任何改變都可以獲得數據的支持，這樣單獨或者對比的結果就是壓力測試或者AB測試的結果。
如何做：
系統透明化工作為基礎，結合Beta發布或者局部發布的模式來驗證和測試不同壓力下的新老系統。
場景8：
Hack Day，一個晚上通宵做出原型，第二天在全公司面前展現創意，用技術來說服有興趣的同事一起去做一些有創意的工作。F公司最典型的視頻項目就出自于Hack Day。
觀點：
通過自己努力和時間的投入，在公司給的平臺上展現，最后取得好的效果。
如何做：
公司給平臺，個人擠時間。
場景9：
公司中所有的開發人員都是Engineer，每個人可能不同Level，但是每個人的工作都是自己來考慮，上級M只是替Engineer去協調資源。此時任何Team的人如果有想法和創意，如果要做，也需要資源，只能靠自己去說服同事一起做，而M沒有權利否定或者強制Engineer去做任何工作。
觀點：
由于考核都是同事之間點到點的評價，因此其實M沒有任何實質性的技術管理職能在，任務分配和工作目標也是工程師自己需要去考慮的，主動權掌握在自己手中。工程師需要去考慮自己有限的工作時間中如何做有效的做出最有用的內容。能力越大責任越大，因此原本認為束縛工程師的方式，其實反而給工程師偷懶思考的機會。
如何做：
在工程師技術能力達到一定階層時，國內的公司可以考慮采用這樣的方式去管理他們，同時為他們提供更廣闊的技術空間去創新和滲透到他們希望滲透的產品中。
場景10：
對于問題從效率角度去考慮如何解決，而不是簡單的從資源角度去考慮。
觀點：
公司發展壯大，業務戰線不斷變長，往往第一就考慮需要資源，往往忽略了如何用技術提升效率。增加資源有時候反而是增加內耗和降低工作效率的誘因。
如何做：
壓力帶來動力，決策者需要判斷和觀察。
場景11：
每個新人進來都會進入新兵訓練營，每個人選擇自己有興趣加盟的兩到三個團隊，一個月內完成兩到三個團隊的一些線上問題修復，在熟悉業務的同時，也鍛煉了自己的能力，同時更加明確自己感興趣的團隊究竟是哪一個。
觀點：
這種方式可以最直接的讓新人了解業務，熟悉將來的方向，同時也是檢驗一個人能力的最有效的手段。
場景12：
不同Level的錯誤有不同的通報，產生較大問題時，全公司郵件通報，但考核并不看問題發生次數和嚴重程度（因為每個人都可以修改各個層次內容，多做多錯，少做少錯這種事情不應該鼓勵）。同時，任何過失需要描述四方面內容：現象，問題原因，解決方法，防范措施。范例：有一個同事修改了底層配置系統的部分代碼，結果導致全站系統2小時不可用，全公司通報。遂這個同事花了幾天時間全部重寫了底層配置系統代碼，為了防止別人和他犯一樣的錯誤，后遇人都笑談他重寫代碼的事，而不是那次問題。
觀點：
首先，大家都抱著樂觀的態度去看待犯錯，看到別人的總結，也是審視自己的工作。其次，最重要的是問題的解決和預防，這點是透明化問題的關鍵所在，也是驅動犯錯者改進自身不足的動力。
如何做：
倡導這種氛圍，提升工程師的責任感。
場景13：
對于所有代碼的更新時間有監控，很久沒有更新的代碼將會被提出來，作為爛掉的代碼告警全團隊。
觀點：
很多時候不是做減法不易，而是沒人知道什么時候該減什么。
時間有限，其實也沒談太多技術內部的東西，但是從周邊的這些內容聊下來，兩點讓我感覺和去年自己做的一些工作很類似，也很重要。產品責任感，系統透明化。
不論是業務或者技術的垂直化，測試工作前移，產品設計后移（在另外文章中有提到），技術工作自我定義，其實都是在考驗一個工程師對產品的責任感，不簡單的約束自己在某一個技術領域，在某一個產品環節，在某一個崗位職責，也許聽起來是一個較高Level的工程師（國內叫架構師）所需要考慮的，但其實也只有這樣的工程師才會稱得上是合格的工程師。
不論是1：1系統設計方式，線上仿真測試，豐富的監控系統，其實就是要求做每一個業務系統或者技術框架一定要做好透明化工作，系統透明化是對當前系統負責，對依賴這個系統的外部系統負責。當一個網站各個零部件都能被外部所觀察到的時候，出現問題不為人知，緩慢出現量變病化，業務模式AB結果都將變得一目了然。