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