======今天更新了amazon砍掉測試團隊的原因，請往下拉到更2 *\(^o^)/*=======
額，被陳皓本人點贊了，看來我這個是正確的標準答案（大誤+汗）
為什麽很多的關註很少的贊T_T，請大家給予我繼續寫得元氣呀～～ ↖(▔^▔)↗
8年amazon老兵，先來占個坑，( ^ω^ ) , 在大家都看好我轉TPM的情況下，依舊毅然決然的堅持走技術和coder的路線（雖然亞麻升級SDEIII 登天樣難... T_T，很多人轉管理也是因為技術觸頂)，天天跟著research scientist研究model，真的比當TPM有意思太多了！
沒想到陳皓也在platform幹過… 當時我在platform工作的時候，真的以為自己已經掌握了這世界上最先進的科技了，grid computing，MPI，LSF，高效能計算，讓科學模型並列跑在上千個core的機群上的黑科技，亦可賽踢的！客戶都是什麽 美國航天局，氣象局，對了還有神6；各種高大上…
然而來了amazon才真的開拓了眼界… 也是為什麽在這裏一呆就是8年 （在什麽組，真的真的很重要）話說原來在中國office時候跟陳皓在同一層，經常遇到，直到他走了才知道他那麽有名…
陳皓所謂：「世界前沿的軟體設計架構和解決方案，以及做技術的態度和工程的方法，我的眼界、腦洞和視野都巨大的開啟，並且在技術管理、工程管理、產品管理、人員管理、公司管理等等管理方面的思維有了質的提升」
有人看的話， 有時間可以稍微介紹下。 ^_−☆
-------------------------------更1 ------------------------------
貌似由於這個回答被不少人關註了 -_- 於是也下決心好好完成這個回答，補上這個坑。
坑留得比較大... =_= 沒有大塊的時間放在知乎這裏，所以會分多次update這個回答，既然承諾介紹下「
世界前沿的軟體設計架構和解決方案，以及做技術的態度和工程的方法
」（羞） 自然答案所包括的內容也遠超問題「寫工業級別程式碼是怎樣一種體驗?」 本身了。
首先，為什麽需要「 世界前沿的軟體設計架構和解決方案，以及做技術的態度和工程的方法 」，是這次更新要談的問題。我們不能用手術刀在市場買肉切牛肉， 也不會用核彈來拆出拆遷建築。如果你是一個為了「高精尖」來提高自己逼格而不管要解決的問題而使用「高精尖」的人，那我們可以說是話不投機了，以後的很多內容估計也會引起您的不適，請及時關閉本答案。
先介紹一下個人背景，我的技能棧和輪子有所不同，輪子感覺上屬於精研PL，技能點集中一個自己喜歡的方向往技能樹深處點下去的型別；而我則非常分散， 一些主要的技能點列在了這個回答裏：後端所謂復雜的問題是什麽？ - 阿萊克西斯的回答 所以看問題的角度會有不同，之後有機會也想說一下程式設計師的發展路線，深度優先/廣度優先，分別適合什麽樣的人。
再說一下現在的工作的大環境，我只在platform和amazon呆過，platform做的算得上軍工級傳統軟體了（maybe？）；而amazon則是完全不同的互聯網畫風，所以對傳統行業，互聯網行業也算得上都有涉獵；我所在的組/部門更是互聯網公司中的另類，那就是
：探索型領域。
另外一個核心角色加入了進來，那就是RS（Research Scientist），也就是你們可愛的曾博 @大勃勃 的角色；探索型領域有個特點， 那就是會失敗， 經常失敗，因為沒人知道什麽是對的；客戶只會說， 我要最好的馬，什麽是「最好的」，不知道，你去找吧。我想讓XXXX的利潤最大化，怎樣才能最大化，怎麽就算最大化了，不知道，你去找吧。很多時候客戶（或領導）想讓你把月亮摘下來，然而一開始誰都不知道這是一個把月亮摘下來的「不可能完成的任務」， 去做吧，你得到的「需求」也許一開始就錯了。所以做了幾個月1年的計畫，可能一天就砍掉了（終於探索到，證明了「這是不可能的任務了」），可能寫了幾個月的程式碼，開一次會，就要全部刪掉重來（因為探索到solution就是錯的）。
但是，探索型領域，卻是往往是一個大公司的：
核心競爭力
，為什麽近年來FLAG都開始狂招RS，不在探索中持續前進，就在探索中衰落，現在這個年代，能抱著自己的老飯碗，自己的已有優勢吃5年都是不可能的事情了，想要在競爭中生存，不僅要去探索，還要付出比別人小的代價來最大的換取探索的成果。因為大家也都在探索在進步，只是進步是不行的，要比別人進步的快，才能存活！（在探索這方面，國內的阿裏做的非常好） 在探索型領域中，精英的RS和SDE將是核心人員，而其他比如產品經理，dev manager則成為輔助。在這樣一個充滿挑戰，激動人心的領域，擔任一個精英怪的角色，正是吸引我這樣一個數學系出身，曾經想轉行學經濟的SDE，在這裏一呆就是8年的原因
好的，接下來就要開始講在這樣的環境下，怎麽來進行：
raise question->raise solution->design->coding->test->verify->meet new problem-> raise question 這個無限的迴圈了，敏捷開發的流程在這裏大放異彩，莫名其妙的奇葩問題不斷展現，各種各種的黑科技始現魔力；正如陳皓文中所說，問題環環相扣，技術問題歸根結底也許是公司文化問題，讓我們期待下一期， 走近科學。。。。
（我會再回來的。。。 老婆留給我的自由活動時間已經到了。。。看孩子去了。。。）
對於程式設計師來說，怎樣才算是在寫有「技術含量」的程式碼？ - 阿萊克西斯的回答
留一個簡介我技術三觀的回答吧。。。也許看了你們就發現咱們道不同不相為謀了。。。如果是這樣， 請大量對本回答點選反對。。。我也就不用填這個坑了。。。。（好好回答問題。。。太累了。。）
---------------------------更2-----------------------
今天恰巧看到這麽一個問題，
微軟Windows團隊的程式設計師品質在下降嗎？ - Microsoft Windows
微軟的大大們紛紛表示把鍋甩給
砍掉
QA團隊，吃瓜群眾紛紛表示QA必不可少，批評敏捷鼓吹QA DEV結合就是瞎搞，於是在某回答下評論了一下。寫得比較長，不如就貼這裏當作更新了吧 ( ^ω^ ) 寶寶我真是機智呀 ～ ～
（認真臉）從amazon的角度來說下這個問題，amazon大振幅裁減了QA團隊，主要由於：
第一：非常嚴格的要求SDE寫UT，因為能把UT覆蓋率提高本身也體現了程式設計的flexibility，當程式品質由於UT提高之後，很多團隊發現QA不僅沒什麽幫助，因為測出bug的機率大大降低，反而成為了團隊的累贅，因為communication是需要消耗團隊精力的，amazon的two pizza team保證了交流的範圍和效率，一個復雜的feature，甚至scientific model需要SDE，QA同時深刻理解，當然沒有只需要SDE深刻理解來的有效率，靈活而敏捷。對於非常需要fast prototyping，拿到反饋來revise產品，design，甚至大方向的探索型計畫來說，多一倍的溝通效率就是競爭中生與死的區別。這時要balance，出bug的機率，bug的影響的cost，和引入QA團隊的cost。那麽權衡之下，大多數非bug敏感的團隊發現都是可以取消QA團隊的。當然出bug就致命，直接死的團隊，一個bug就是million dollar損失的團隊，還是保留了QA團隊的。當然UT cover0也不代表系統沒bug，end to end的manual test還是可以增加系統健壯性。however…The trend recently has been away from any large-scale manual testing, in favor of automating as much as possible. ——引自【building microservice】任何的manual的，厚重的test流程，都會增加「變化」的成本；這裏關鍵要認識到：
要麽犧牲開發探索敏捷靈活性，來增加系統的confidence level，要麽犧牲一些confidence level，增加系統敏捷性。測試不是簡單的有或者沒有，而是從0到100的程度，需要你根據自己的系統的實際情況做出選擇！
其二：Amazon強調SDE要有ownership，自己做出的東西，自己就要負責到底。做design就直接要考慮testability（一個不可測，或者很難測的系統，必然是沒有經過domain，tech concern separation的，必定是一個不靈活的design），考慮到以後怎麽maintain，考慮到怎麽部署怎麽release。如果總是想著出了錯，第一個背鍋的不是自己，那麽系統品質怎麽能嚴格保證呢？怎麽才能方便的test，或者說怎樣很容易的定義/驗證程式的正確性，本身就是design必不可少的一部份呀～ 因為design要做到： A good system, doesn't only work well, it SHOULD also be seen work well. 這就是所謂的系統透明性原則了， 你寫code做design的時候考慮到了麽？ ( ^ω^ )
其三：很多時候， 不想被厚重的測試限制，那麽可以用monitor來增加系統的confidence level而不太影響系統敏捷性。A mazon就是大量的使用了各種各樣的monitor framework，讓SDE自己來定義和監視系統的執行時正確性。很多組一個QA都沒有，系統健壯性全靠UT，SDE手測加上monitor，也活的好好的，對有責任心的SDE來說，測試也必然成為他的必點技能之一（融入到他的design和coding之中了）。對於一部份組和部門來說，這基本就夠了
總結： 不要被方法步驟迷住了雙眼，測試的目標是為了系統正確性，而系統正確性不僅僅可以靠測試還可以靠monitor；系統的正確性健壯性的目標又是為了核心競爭力，那麽當核心競爭力可以透過剪裁系統正確性來提高的話，那麽犧牲正確性又有何不可？還是那句話，直追你的目標，忘記你在用劍，才能使出最高的劍法，不滯於物，才能隨心所欲，登峰造極～
欲知後事如何，且聽下回分解( ^ω^ )
（下次來講下怎樣拿需求，和PM的關系，怎樣向上管理PM，要知道，SDE才是計畫的真正核心！）
補充：本來不想趟「
windows10到底應不應該砍QA
」這個問題的渾水，因為我也說了，測試和系統敏捷性，甚至公司戰略目標，這個balance要就事論事，才能決定。就win10被罵這個問題來說，」 被使用者罵「或者擡高來點說」系統正確性「也只是公司競爭力的眾多衡量因素中的一個罷了。
簡單
來說，如果砍掉過多的「正確性保證」（就是QA）能得到x，失去y，那麽這是不是一個好的決定完全取決於x和y誰大。但是這麽大個事兒，誰說的準呢？（知乎的屁民從使用者體驗的角度來思考，那肯定是品質大過天了） 所以我也沒有直接就說「砍得好」， 「win完全不需要QA」 這個話，只是希望大家分析問題能再上幾個高度來思考，從系統靈活性，健壯性的trade off來思考， 甚至從公司戰略目標，和多種影響戰略目標的因素（測試或者系統健壯性只是其中之一）來思考。不過評論區有人上來就「你的認識太過膚淺和片面」，不是就事論事的說話，而是寫些情緒性的東西。那我就對「win10要不要砍QA」這個問題再加些「膚淺和片面」的評論：
1. 砍QA到底是得是失，x和y到底那個大，沒試驗之前（易地處之，人家做這個決定的時候可不是像大家這樣做馬後炮），這麽大個事兒，誰說的準呢？至少微軟CEO和一眾高管做出了和知乎上的屁民不同的決定不是麽？ 你是看到了win10被很多人罵，但是萬一這件事本身就是高層取舍中的」棄子「呢？西洋棋，高手過招，只要國王沒死， 皇後都可以舍棄（IBM為了
前進演化
連X86伺服器都給賣了，憑什麽微軟就不能把資源更多的集中在Azure上邊？到底微軟的什麽業務是微軟再次偉大的希望？）；還是要從企業發展的大局來看啊。
2. 大局怎麽看？ 微軟近些年是變好了還是變壞了？（別扯別的，咱就看股價）微軟沒點「大」變化，下場就是IBM，摩托羅拉，諾基亞，朗訊。管理層敢於這麽大膽嘗試，我給微軟10000個贊！看好微軟的未來！
3. 微軟的」有些「SDE啊，都」xx「慣的！
