======今天更新了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「惯的！
