在西雅圖亞馬遜工作是種什么體驗？
很多互聯網小伙伴都關心工作和生活如何balance。
可在國內略顯內卷的環(huán)境下，原本合理的需求都成了奢求。
相比之下，外企似乎更容易實現快樂工作，認真生活。
今天和大家分享一位好朋友GXSC在西雅圖亞馬遜總部多年的工作體驗，看看他如何從懵懂新人成長為職場老炮。
全文內容較長，可以先收藏，或根據標題選擇性閱讀。
入職純屬偶然
我其實本來是想一直留在學校讀書， 然后以后教書的。來西雅圖的亞馬遜純屬偶然。
這些年在亞馬遜做開發(fā)， 感受最深刻的就是學到了很多東西?；仡^看剛入職的時候， 當時還真是很多事情都不懂。所以現在也不敢說自己懂什么。畢竟過個幾年再看， 現在還是什么都不懂。我開始有時候還會以為自己是個工程師、以為做SDE的真的是做software development engineering。
這不是說所有的剛入職的應屆生跟我當時一樣什么都不懂。今年遇到一個本科實習生， 對于開發(fā)和管理上的見解非常深入， 不比某些SDE III弱。不知道他怎么領悟的。
最開始工作時我喜歡做些operations方面的苦活。因為當時覺得在西雅圖10來萬年薪已經很高了。組里大家不想干的活我就多做點才對得起這工資。當時組里同事對這個做法經常表示不解...因為一般當時最好的項目開發(fā)的活一般都是給實習生和SDE I做的。這樣可以讓這些新人多寫code， 在做code review的時候就可以更方便培養(yǎng)他們的設計靈感。當然這些我當時都不懂。我當時看我們SDE III一直在干一些又累又沒人欣賞的臟活累活， 所以我也干。
那個組做的系統當時并不容易理解。問題也多。我入組之前據說每晚得手動重啟才不會把內存跑沒。但是我反正新手， 也不知道問題所在。我還以為干這行就是這樣。
后來做了一年多之后組里做了幾次系統重構。新版本比老版本好懂多了， 也穩(wěn)定多了， 我才開始感受到什么叫“好系統”。
之后大概有一兩年， 做了不少系統設計， 學了很多銷售領域相關的知識， 但是并沒有抓到要領。當時也沒意識到系統設計最重要的就是要好懂。那時候做設計主要靠靈感。等到換了組， 遇到了更難懂的系統、更大的設計問題， 才慢慢開始通過讀書和找專家咨詢來更正式地學習開發(fā)和管理。學習初期犯了很多設計、領導方面的錯誤。也沒人跟我追究。這些錯誤對公司和組造成的傷害我到現在才明白。但是也沒人跟我提過。有次我跟經理提到這些問題， 經理跟我說：“沒有人是通過一直做出正確的選擇來學習的?！?/span>
這些年也遇到幾個比較普通的經理（雖然我也很喜歡他們， 但是當時不知道好經理是什么）， 當時對薪水和職位就看得比較重?，F在遇到了很好的經理， 可以從他那里學到很多開發(fā)、管理、以及銷售領域相關的知識。對于薪水和職位就反而看得沒那么重了。
即使是很普通的經理， 也都很關注我的成長。有的給我找mentor， 還有的帶我去跟客戶和領域方面的專家接觸、學習， 帶著我建立我自己的職業(yè)網絡。
我也遇到過兩個很差的經理。一般這種經理都不會很關心手下員工的成長（也有的是沒時間管）。一般這種經理都不會在一個組留太久。大概幾個月到一年半就會被轉走。
亞馬遜里只要你知道怎么操作， 很多事情可以大膽去做。其實級別越低，話語權越高。因為級別低的就算說錯了、做錯了也是理所當然。所以想說什么、想做什么， 只要目的是好的， 都可以大膽去嘗試。當然了， 別違法。
接下來談一下幾件大家可能會比較關心的事情。
1. 關于是否應該來亞馬遜
如果你不是太缺錢（比如學生債很重之類的）， 亞馬遜西雅圖總部是一個適合職業(yè)成長的地方。亞馬遜的應屆生起薪不比別的類似公司低， 所以如果負債太重， 這類公司可能都不適合你。
不管你是什么專業(yè)， 都可以從這里的SDE I做起?，F在亞馬遜招的本科生中， 有很多理科非CS專業(yè)的。我也見過很多文科、醫(yī)科的， 讀個半年的電腦碩士就來亞馬遜當SDE實習生的。
個人而言非常喜歡這樣的員工。他們的思維模式往往非常靈活，可以給公司帶來不同的視角。如果你背景就是CS， 也很好。這樣上手快， 也有時間多學一些別的專業(yè)的東西。
傳統上，亞馬遜大多數組會給新SDE I甚至實習生從頭到尾的"ownership" （近三年某些部門有一些變化， 之后會提到）。很多新人會去與客戶談項目、設計系統。一直到最后的購買硬件、發(fā)布功能、系統， 都可能是新人在主導的。這個ownership不應該被曲解為加班加點趕活。只是說這個實習生或者SDE I擁有整個項目最高的話語權。
比如我今年就看到一個組的實習生， 在花了幾周與他的客戶討論和深入分析之后， 成功說服他的組員去放棄他的實習生項目。他的經理之后又花時間跟他一起開始了一個完全不同的項目。這種自主能力是亞馬遜強調的ownership。
這里同時要注意， 自主和自私是不同的！有人來幫著做項目是好事。如何有效利用他人的幫助， 也是自主能力的一部分。
這種待遇在別的公司會比較少。這也是為什么有工作經驗之后， 想面試進亞馬遜難度反而會很高。一般工作經驗3-5年的人， 面試亞馬遜SDE II失敗率很高。因為這個階段的普通程序員是很少會做項目規(guī)劃和系統設計的。然而亞馬遜的員工有很多從實習生就在做這些。
反之也同理。我聽說過不少起亞馬遜SDE II跳槽到微軟當Principal Engineer的事情。
當然并不是所有組都是這么好。這點之后會詳細討論。
2. 關于亞馬遜中國
亞馬遜中國的開發(fā)，現在的確不夠自主。以前其實亞馬遜印度也是全部都得聽西雅圖的命令。一方面是因為不是總部， 另一方面是印度文化上比較隨和。
后來有一年派去印度一個Principal Engineer， 帶領一群人建立這方面的思想， 最后改變了印度一些部門的文化。雖然有些部門還是老樣， 但是很多印度部門已經自主化， 完全可以和西雅圖這邊的想法抗衡。個人希望這種文化也可以傳播到中國。
3. 關于oncall
個人而言很喜歡oncall。oncall是學習機會。軟件行業(yè)里大多工作都是在已有的老系統基礎上開發(fā)的。oncall可以讓我們學習到老系統在開發(fā)和成長過程中所犯的錯誤， 進而在自己做開發(fā)時能夠有更好的質量和效率。
對于做新功能開發(fā)的人而言， 不去了解自己寫的程序長期的隱患， 就是失去了能夠讓自己進化的學習機會。
工作中有時能遇到只喜歡開發(fā)新東西的員工。我對這種傾向不鼓勵。但是亞馬遜里的確也有組是專門這樣做， 做完了程序給別的組做operations (oncall)。因為沒有后顧之憂， 這樣的程序很難保證質量。
如果一個新人加入了一個比較好的組， 這個新人很可能經常對于自己前一個月寫的程序悔恨不已。組里會給新人犯錯的機會。而犯的錯通常會在oncall時被發(fā)現。
4. 關于組與組之間的差異
當時我入職的時候， 有人專門講過這件事情：亞馬遜的組的規(guī)劃是以達爾文主義為中心的。所以每個組都是自主的個體， 任意發(fā)展。發(fā)展得好的就可以發(fā)揚光大， 發(fā)展得不好的就會被重組。
這是組和組之間體驗不同的最大原因。
這個原因導致一個組好不好， 和它的經理、系統、開發(fā)者， 有直接關系。很多人對于Software Development Manager (SDM)的理解有誤區(qū)， 以為就是看大家效率、監(jiān)視一下項目進度、然后有時候給人升個職、有時候給人來個PIP...換句話說以為SDM只是個管人事、管項目日程的。這個誤解來源于很多人對于項目“成功”的定義的誤解：
亞馬遜項目的成功的定義不僅僅是“解決了問題”， 更是“培養(yǎng)了人才”。
也就是說亞馬遜SDM的核心任務是培養(yǎng)SDE。好的SDM其實是很少的。因為好的SDM必須有能力從各方面去培養(yǎng)手下的SDE。如果一個SDM手下有個SDE III， 這個SDM的能力至少得接近于Principal Engineer才能夠有效培養(yǎng)他。
我已經有幾年沒遇到特別好的SDM了，直到最近才又遇到特別好的SDM。這幾年遇到過很多比較普通的SDM。大致上普通SDM分兩種：
一種往往只有管理經驗， 卻對軟件開發(fā)的各種流程、系統設計、以及其工作的商業(yè)領域并不是特別了解。這樣容易給組里帶來一些非最優(yōu)的項目和解決途徑。而且很難領會到怎么有效管理SDE - 因為不懂什么樣的開發(fā)流程適合他現有的處境。這處境包括小組的商務、包括組員的能力、包括與外組的關系等等。更糟糕的就是這樣的SDM往往不懂得如何輔導他的SDE。
另一種雖然是SDE的背景， 但是缺乏管理經驗， 經常擋在員工道上。比如有的會micromanage他最能自主的員工、卻忘記管那些不能自主的員工。
這兩種SDM都可以通過學習來進步。
所以如果在亞馬遜工作， 并對自己的組經理不滿意， 可以多了解了解別的組的一些做法， 用以改進自己的組、輔助自己的經理的進步。
一般沒有人會阻止我們去做這些。當然了， 我們也需要有足夠的工具去理解現有問題和實行改變。
做這些改變的過程， 也是我們學習的機會。具體的工具有很多。比如《Peopleware》就是一本這方面很不錯的教材。
這里稍微提下PM的問題。有些朋友提到被PM趕活。 這是近三年在有些部門開始有的問題。 我所了解的一些組以前PM很少。這些年PM開始多了一些。一個好的組會知道自己什么時候需要PM， 什么時候需要cross-functional的SDE。并根據情況在這之間轉換。通常一個組需要有大量合作時， 會需要一個PM。而好的PM應該促進SDE與客戶的交流， 而不能總是直接自己去交流了， 然后給SDE丟requirements。SDE不理解客戶具體的問題會導致解決方案難以適應未來的需求。主要的原因是SDE是最后做軟件模型的人。如果SDE理解客戶的具體問題， 就更能預測長期的需求， 進而會做出更合適的模型。所以所謂的系統設計， 設計的是所從事的領域的模型。對一個領域越了解， 系統就可以設計越能適應未來的需求。
如果發(fā)現組里PM不是在輔助項目， 而是在趕著別人干活， 并且搶了所有對外交流的活， 最好的做法是和自己的SDM一起重新定義PM的角色。這個重新定義的過程中， SDE和SDM應該積極去參與和做一些之前PM干的活， 比較自然地進行角色改變。好的PM可以促進各組之間的合作， 以及幫助大家擴張視野。
少數組所做領域相關的活都給PM在干， 導致SDE無法學習自己所工作的組的領域相關知識。比如一個SDE可能在推銷組做了兩年關于推銷的程序， 但是完全不懂得基本的推銷方案、無法自主解決基本的推銷領域的問題。
這導致這些組里PM權勢越來越大...還養(yǎng)成了少數經理什么項目不論大小都要看PRFAQ/BRD的惡習。不是說不應該寫PRFAQ或者BRD。好的組在項目復雜時、投資比較多時， 也是要寫的。但是當時比起PM， 更可能是經理帶著SDE寫， 而且是不需要寫就不寫?，F在有些組是能寫就寫， 而且全是PM在寫。這些與亞馬遜end to end ownership的理念背道而馳， 也與亞馬遜frugality和bias for action的理念背道而馳。
5. 關于薪酬
SDE I其實在很多地方都是看作是暫時的一個角色， 不可長久。一旦自主能力開發(fā)好了， 就是SDE II。SDE I如果做得好， 頂多底薪增加1.9%左右（我第一年好像只漲了0.1%還是多少）。但是SDE II做得好， 底薪可以每年增長6%左右（少數可以增長8%-13%）， 直到增長到SDE II薪水封頂。
SDE II開始， 薪水慢慢向股票(RSU)轉變。亞馬遜給股票時會假設明年這個股票會漲。所以每年給的股數可能都比去年少。這個雖然有時會比較惡心， 最后交稅時還是可以看到每年錢在往上漲的。
由于級別比較少， SDE II開始， 每個級別薪水區(qū)間可以很大。西雅圖有的SDE II可能一年就10多萬， 有的可能20多萬， 有的接近30萬。這與亞馬遜股票浮動關系很大。
總之至少2018年， 就我個人了解：
SDE I: 13萬到15萬之間
SDE II: 14萬到28萬之間
SDE III: 16萬到???之間
Principal Engineer: 據說比同級別的經理賺得多...
在美國， 員工之間討論薪酬是被National Labor Relations Act保護的。阻礙員工討論薪酬是違法的。所以大家也可以入職之后找同事了解一下別人的薪酬。薪酬隱私化是美國傳統企業(yè)為了削弱員工的議價能力而制造的文化。但是如果你的同事不想討論， 還是要尊重別人的。
我覺得亞馬遜應該是喜歡留那些以長遠目光看問題的人。貝索斯曾經說， 如果你計劃做得長， 競爭對手就少。大多數競爭對手都在看每3個月的財報， 少數可以以三五年做計劃。如果你做計劃做到12年以上， 就沒有人跟你比了。
所以只要你愿意放長線， 亞馬遜給的報酬還是還可以的。
比如，如果一個員工是2012年大學畢業(yè)入職， 光他當年4萬的signing bonus在2016年全部vest時就已經成了20多萬。如果他到2018年都沒賣， 就是40萬了。
不過話說回來，如果有一個好的成長的機會， 長期的職業(yè)發(fā)展比這些短期的薪酬要重要。
6. 關于升職
之前提到亞馬遜級別比較少。其實升到SDE II是件很不錯的成就。升上去了， 你可以拿拿別的公司的Offer看看給多少。一般可能會被亞馬遜當年給你的工資多一倍左右。
但是從另一個角度講，最好著重于成長，而不是升職。亞馬遜某部門這兩年就出了一個問題：很多系統被設計得過度復雜。后來調查時發(fā)現， 都是因為設計復雜了容易忽悠人好升職。升上去的人， 很多不稱職。
但是大家不要忘了，亞馬遜是會PIP人的！能力差的經理一般專PIP那些工作不久的SDE I。其實SDE I是最不該PIP的。因為SDE I破壞力最小， 而且最容易訓練。
職位越高， 越容易遇到經驗比較足的經理。這些經理會著重審核SDE III和Principal。有個部門今年一年就開除了兩個SDE III和一個Principal。
所以比起升職， 更重要的是成長。做得好總是會加薪的。做得不好， 升職了飯碗都不一定能保住。
當然SDE I也不要怕PIP。只要你做得好， 學得多， 你就不怕PIP。出PIP是件很光榮的事情。因為一個經理去PIP一個人， 代表著這個經理認為：
這個人造成傷害很大 這個人無法被訓練
也就是說， PIP的確是用來開除人的。
但是如果被PIP的人出了PIP， 就很可能這個經理看錯了。如果一個經理把一個好員工當成壞員工， 最后被開除的很可能是這個經理。所以在亞馬遜， PIP是雙向的。
7. 關于工作與生活
這個也是一個純粹看經理和個人態(tài)度的事情。好的經理著重于提高效率， 壞的經理著重于增加坐班時間。如果遇到一個壞的經理， 那就得想辦法訓練他， 或者跟他的經理反應這方面的問題。亞馬遜的小組里， 往往經理比SDE走得快。所以實在無法訓練的經理跟上面反應一下把他轉走就好。
我最開始的一個組比較幸運， 組里效率比較高?；旧现形绲焦?， 午飯一兩個小時，下午5點準時回家。然而工作成就感很高。談項目、解決問題、做開發(fā)，都速度很快。一個中型項目往往也就幾周的事情。而且一兩個人能搞定。每個項目都有時間重構現有系統來讓之后的項目更容易。
這個組當年是沒人想當經理的，因為這個組的經理很累。所有的SDE他都得指導。每天得考慮怎么樣和SDE一起優(yōu)化開發(fā)流程、幫手下的SDE聯系上客戶、賣項目給高層、應對客戶非項目相關的問題。遇到SDE正在走彎路時還得很小心的誘導他走上正軌， 而不是否定他的工作。我們郵箱里24小時都可以看到他在發(fā)新的郵件， 不是催活兒， 而是幫組里解決一些瑣碎的問題， 幫組員推脫一些客戶不合理的要求， 找法務部幫組員研究新功能的合法性等等。這個經理是一個好經理。雖然我最近發(fā)現，有些非常罕見的經理可以做到同樣的事情而不會像他那么累。
后來到的一個組就不太行了。常常連續(xù)周末加班幾個月。全組人都加班， 什么都做不出來。有兩年時間我的休假儲蓄都是滿的——有假沒時間休。這樣的情況一直持續(xù)到了換經理之后我才知道之前經理做法上的問題。但是我要是當時就知道這些問題和解決方式， 可能就會給那個經理一些反饋， 讓他進行一些改善了。
8. 關于個人用硬件
每年亞馬遜都會從員工那里汲取意見。硬件是2016年以前最大的抱怨之一。大家都覺得可以frugal， 但是frugal和cheap是兩回事。太小氣反而會浪費——員工每年開機、修電腦浪費的那些時間相對應的工資都可以給每個員工買好幾臺電腦了。所以2016年開始亞馬遜給所有開發(fā)人員重新配了新的硬件。包括最新的手提電腦。最低配也是SSD和16G內存?，F在我的Windows Laptop開機就十幾秒。Mac不清楚。
硬件改善也包括重新配置顯示器?？梢赃x擇雙21寸顯示器和單寬屏34寸的曲面顯示器。寬屏顯示器做Code Review很好用。雙單屏做開發(fā)比較方便?？磦€人喜好了。
最近新入職的小朋友表示只能選雙顯示器。這是因為34寸的沒貨了?？梢哉襂T Support那塊申請。大概要等兩個月。
新入公司員工可以選擇用Mac或者PC。這個主要看習慣。有些組會推薦新人用Mac， 但是如果你沒用過Mac， 最好別入坑。Mac可以直接進行開發(fā)， 不用連到Linux主機上。但是這樣開發(fā)問題比較多。
PC是帶Docking Station的， 很容易就可以和鍵盤、鼠標、顯示器連起來。Mac的Dock得另購， 不一定能報銷（跟自己老板商量）。沒有Dock的話， 這些顯示器、鼠標、鍵盤、電源、耳機什么的就得一條一條插...
寫程序主要是在Linux上進行。但是有些組至少一半的活都并不是寫程序。做設計、寫文檔、處理數據， 都是在PC上比較容易。因為Microsoft Project, Visio, Excel之類的軟件， 在Windows上安裝比較容易。
當你選好硬件之后， 5年后可以換新的手提電腦。如果你弄壞了或者想換個Mac， 公司會給你換個舊的電腦。同時5年的排期會重置。如果出現2016年大更新的話， 倒是可以免去排期。弄壞電腦的方式有很多種。我見過人潑咖啡的， 也見過直接用升降桌壓裂的。
新員工標準配置是帶一張升降桌的。我用的還是老款的木頭Door Desk...主要是我喜歡這樣的， 也方便我在辦公桌附近搭別的東西。如果剛入職你沒弄到升降桌，并且想要升降桌，一定要趕緊跟老板提，因為新員工換硬件比較容易。老員工以前換個升降桌得搞好幾個月。不知道最近有沒有什么改動。
9. 關于移民
移民這個事情好像不是亞馬遜說了算的。以前只有SDE II能辦綠卡。
2017年開始SDE I只要經理同意也可以辦。當然不是一進公司就立馬辦。好像是要工作幾個月才行。現在美國這個情況， 以后移民會怎么樣誰也說不準。
10. 關于職業(yè)發(fā)展
前面提了一些如何應對經理、小組的問題。這些是主要成長的方式。在亞馬遜其他的學習機會也很多。比如Principal of Amazon的演講(POA)， 以及各種"Learning Series"。POA并不需要是Principal Engineer才能去演講， 也經常有SDE III去講。
個人覺得， 早期的POA質量比較高。會談一些比較基礎的東西。比如我一直對SSL不是很了解， 當時就是從一個老POA里學的， 總算學懂了一時（現在又忘了）。還有關于Consensus Algorithm， 也是從2007年的老POA里學的。從2007年的演講都可以從內網上找到。最近的POA和Learning Series有部分偏見比較重。往往讓聽眾拿著一個解決方式去找問題。這種做法容易造成之前提到的系統過度復雜化的問題。
比如有一次有個人談Data Oriented Design時， 恨不得把主程序都用data來表達。自己干脆只寫這些數據的解析程序。這不是不行，但是在大多數場合是過分復雜的。這人為了讓大家不提意見， 一開始發(fā)言就是"There is no silver bullet"， 來堵大家嘴， 但是到最后也沒提這個設計的隱患以及它不該被使用的場合。只提了句："It might not fit your use case." 但是"which use case"恰恰應該是他整個演講最重要的部分。
還有一次是我沒聽到的， 但是后來遇到某個組里的人， 他們已經有以event driven的方式做的一些系統， 非常好打理...但是其中一個SDE III拼命想做Process Oriented Architecture。我從來沒聽說個這種結構...聽他的描述， 這個做法根本不適合他們的問題領域， 反而感覺是把系統做得更脆弱...后來才從他們組另外一個SDE III那里聽說， 這人之前跑去看了一個Process Oriented Architecture的Principals of Amazon演講...然后就盯著不放了...
那么話說回來， 職業(yè)發(fā)展到底怎么樣做最好呢？這個可能真的得看人。但是我現在工作年數也不久， 還處于職業(yè)初期（前10年初期， 10-20年中期， 20-30年后期）， 所以一方面只對SDE早期的成長有一些了解， 另也方面也只對我看到的一些SDE有一些想法。這只是一家之言， 不能以偏概全。具體上， 有些做法我也提不上來對哪些人不合適， 有些也許根本就是壞的做法， 只是我現在不知道而已?？梢源蟾畔氲降木褪侨绻悴辉趤嗰R遜， 你的公司也許很難接受下面這些做法。因為有些公司看待開發(fā)者的方式就是“程序員”。他們不會希望“程序員”去干涉商務， 也不需要“程序員”去建立商務模型。
在Adam Barr的新書《The Problem With Software: Why Smart Engineers Write Bad Code》 中， Barr提到， 程序員成長中一個最大的問題就是很多東西都是自學的，導致很多程序員不知道自己不懂什么， 而且還比較自信。這樣容易導致理解錯問題、學錯方向。一個常見的錯誤就是過分注意程序性能而忽略可讀性。這里很推薦在入職前后讀一下這本書， 相信對大家的職業(yè)發(fā)展會有幫助。
10.1 入職
從入職到一年左右， 一般的SDE I最大的學習機會是寫程序。一方面寫程序本身是一種思維、建模上的鍛煉（熟能生巧）， 另一方面， 小組訓練新人最有效的地方是Code Review。
Code Review里面別人提意見多是好事。當然也要多想想、問問為什么。一般的SDE II提的意見大概有一半不一定是對的...我之前就經常提錯誤的意見。最近遇到有些SDE III甚至Principal Engineer在Code Review上提的也不一定對。有時候他們是故意的——因為想看新人的自主能力。如果別人提的是對的， 下次就盡量不要犯同樣的錯誤了。
Code Review的主要目的是培養(yǎng)SDE的習慣， 次要目的是提高程序質量。有些組（比如我的）有時候拿Code Review來保證程序的正確...這個做法...怎么說呢...Code Review有可能保證程序正確嗎？有時候的確能找到一些bug， 但是要通過Code Review要保證程序沒有bug， 按我一位mentor的說法， "it is an impossibly high bar." 寫程序沒bug是不可能的， 更何況讀別人寫的。讀程序比寫程序可難多了。
那么除了寫程序、讓別人Code Review、做別人的Code Review， 另外一個學習的方式就是把自己組里的程序多讀讀。這個是很累的。我一般最多讀幾個class就懶得繼續(xù)了。只有在oncall的時候為了debug一些問題才能一直讀下去， 因為有目標。這是為什么oncall也是學習很重要的一部分。不是為了debug， 漫無目的地讀程序， 實在是太難受了。
除了這些， 可以考慮看一些2007年左右的POA演講， 鞏固一下基礎。雖然我看了之后還做了筆記都很難記得多少。但是以后遇到的時候會比較有用。新的POA我覺得應該敬而遠之。但是帶著懷疑的態(tài)度去看看也可以。偶爾還是會有好的。
我看到不少新入職的朋友所在的組里的軟件質量并不是特別好。組員給他們做的Code Review也不好。但是因為他們是新入職， 所以也意識不到。可以考慮讀一下《Effective Java》的目錄和《Head First Design Patterns》。前者在目錄里有什么好奇的可以進去讀下。后者是一本很適合初學者的培養(yǎng)審美的書。實在遇到一些組里吵架的問題， 比如怎么寫test， 怎么做dependency injection之類的， 還可以參考Martin Fowler的博客（直接google相關話題和"Martin Fowler"）。
入公司需要學的第一個設計模式可能就是Dependency Injection了。MSDN上對于Inversion of Control還有Dependency Injection的解釋非常清楚?？梢钥紤]看看。可能還會因為這個需要去學Guice或者Spring IoC Container。
10.2 寫了讀了很多程序， 什么算程序寫得好？
之前提到培養(yǎng)審美， 這里想解釋一下程序好看是什么意思。
要理解什么， 首先要理解大多數SDE做的并不是high-tech。我們大多不會在IEEE之類的發(fā)表論文。即使在學術界的時候發(fā)表過， 現在也沒在發(fā)表。大多數SDE的工作是用商務模型所定義的程序來實現以前由人實現的商務功能的自動化。
程序作為商務模型的一個展現方式是寫給人看的， 不是寫給電腦看的。電腦看binary就可以了。電腦不在乎我們的設計， 也不在乎我們的結構。對電腦而言， Service Oriented Architecture是一種不有效利用資源的規(guī)劃程序的方式。偶爾我們要擔心一下程序是不是太浪費資源， 但是大多數時候程序是寫給人看的。如果我們優(yōu)化的是給電腦看我們的程序， 那么所有的程序都該用匯編寫， 而且都應該是monolithic的（比如渲染引擎之類的）。
這種商務程序好不好主要在于是不是容易懂。有些程序過于復雜難懂， 看起來寫得很高級， 其實是寫得不好。
用“以后看這個程序的人會很蠢而且很懶”的心態(tài)下寫程序可以預防這個問題。假設未來看這個程序的是未來的自己， 就很難會故意把程序寫的太復雜。在優(yōu)化程序設計時， 通常優(yōu)化的也就是可讀性。一個程序容易懂可以減少這個程序被改變、替換時的痛苦， 也就進而讓商務模型得到了extensibility，flexibility和復雜度上的scalability。容易懂也就可以讓浪費資源的步驟更明顯， 更容易優(yōu)化， 也就容易提高系統運作的scalability。容易懂也就讓我們更容易debug， 于是bug就更少， 就可以增加reliablity。容易懂也就讓我們更容易看到bottleneck， 也就是更容易增加availability。所以有多容易懂是測量一個程序好不好的主要方面。
10.3 程序容易懂了，那商務模型本身怎么做？
模型是某事物的一個表達方式(representation)。
同一個事物可以有很多的表達方式。每一個表達方式就是一個模型。模型之間不同的地方在于它省略的部分。一件事物的完整表達就是它自己本身。
通過省略不同的部分， 不同的模型會更適合不同的用途。
過于精細的模型雖然可以完成原本事物的本職， 但是往往很難懂， 也很難改變。過于粗糙的模型雖然容易懂， 但是卻不能完成原本事物的職能。
所以在建模時， 我們會試圖把復雜的事物分割之后分別建模， 保證每個部分都比較容易懂， 而又能照顧到細節(jié)。這許多被分割的模型之間的關系， 就是一個更抽象的模型。
想要給一個領域的商務問題建模， 就得了解這些需要解決、需要自動化的問題。
程序寫熟、習慣養(yǎng)好這段時間， 慢慢也要了解自己的領域。做物流， 就得了解物流優(yōu)化方式；做定價， 就得了解定價策略。具體的一些建模方面的東西我自己也做不太好， 但是大體方向是針對問題。
建模方面的技術可以參考 Eric Evans的《Domain Driven Design》。這書很枯燥， 不好讀， 但是很有用。入門考慮先讀Sam Newman的《Building Microservices》和Fred Brooks的經典《The Mythical Man-Month》 。后面這兩本讀起來不會腦殼疼。
以前有人提過這么個事：
很多在SDE II或者SDE III經驗級別的人找他做design review時， 會拿6頁的設計文件過去。6頁除了一個自然段講問題， 其他全是問題的解決方法。他看了之后先會說：“寫得很好”(因為不想讓別人不高興)， 然后說：“你用了多少篇幅寫解法， 用同樣的篇幅去寫問題”。別人再來時， 寫了6頁問題。這時他說：“現在你列出這個問題的所有解法， 只是列出來， 不要去想細節(jié)， 也別管多蠢”。然后別人列出來了。然后他這時說：“現在做所有解法的trade-off analysis”。于是別人做了trade-off analysis。然后...然后就沒有然后了。他跟我解釋說：“最后他們選了哪個解法， 我其實不在乎，因為肯定錯不到哪去。”
在過程的結尾， 這些SDE會對自己的領域更了解， 往往會做出比reivewer能做的更好的選擇。
用這種方式產生的6頁的設計文件的結構大概是這樣的：
前5頁講問題， 最后1頁總結解法的選擇，外加6-20頁的appendix列出所有解法、它們的trade-off analysis、以及更多的問題的研究。
這個過程， 通常是一系列Principal Consultation的過程。這個過程中， Principal Engineer會帶著SDE建立問題的模型， 但是不會給任何答案（有位Principal Engineer提到， 當Principal最痛苦的就是明明知道答案但是卻不能告訴別人...）。SDE會需要去見這個Principal Engineer很多次。這與亞馬遜里有名的Principal Review是不同的。Principal Review通常是一個完整的文檔拿去給一群Principal Engineer看一遍...這個做法很不受歡迎， 因為Principal Engineer很難糾正一個已經投資很多的設計。Principal Consult最開始的時候一般并沒有6頁文檔。差不多半頁描述一下大概的問題就夠了，越短越好。這樣意味著少走很多彎路， 也意味著你在盡早讓Principal Engineer了解你解決的問題， 幫助你學習， 而不是在自以為已經解決之后想去找Principal Engineer“蓋個章”。
Principal Consult的過程通常能讓人學到很多建模的技巧， 以及自己商務領域的知識。做Principal Consultation是不需要看級別的。一般SDE II就可以去做。SDE I也可以去。當然大多數情況下， 先從最便宜的人用起， 比如自己組里的SDE。不夠用了再往上走。
做了這類活動的SDE對設計基本上有了一定了解， 可以針對問題來設計解決方案。差不多看看最近的一些POA演講也不會有什么危害了。
小結
我發(fā)現我這么多年， 就像一個故意餓自己的人。不給自己失敗的機會， 讓自己沒有足夠的信息、經驗去總結和分析。開始接受失敗后， 我熬出來的分析能力， 讓我能夠由少量失敗去得到比常人多得多的成長。
這不代表你應該如此。正面地去鍛煉， 去得到經驗， 好好消化， 比這樣變態(tài)的培養(yǎng)可能更有效。你的案例會更多， 你的分析也會更到位。
長期地去訓練某個能力、體驗失敗、并反省， 其實是只有少數人能做到的。像我， 在工作了近十年后，才總算有了失敗的勇氣。
至于亞馬遜， 我會把我的附近做好、改善局部問題。事實證明， 亞馬遜的內部還是會注意到問題， 并且勇于改變的。但是這些改變往往有些延遲。而且局部問題根據情況不同， 可能需要更久才能真正改善。