参加微软学生夏令营是一种什么样的体验

这次见到了一些研究院的大牛。例如邹欣老师，可惜没去合影，相信以后还会有机会。例如芮勇副院长，经常看到他去各个论坛演讲。但目前并没有什么用，只有自己足够强大，认识大牛才有意义！最大的感悟是——自己是在是太弱了！由于技能树是在是枝丫少且细。暂且不说一些比较高大上的技术，就是简单的编程还不够扎实。许多语言只是入门级别。还有就是什么都得学，技多不压身！在夏令营期间，时常想帮忙却无能为力。只好陪着大牛队友熬夜。感谢我的强大队友们！希望下次参加类似的hackthon的活动的时候，我可以多分担点活。收获除了本来就应该有的增长了见识之类的收获，最重要的是认识了那么多来自各个学校的有趣、可爱的人。特别是我可爱的队友们，大家在一起奋斗的这段短暂的时光真是一笔宝贵的财富！希望将来还可以有机会聚在一起！

有不同的观点，有争论总是一件好事，这样可以引发大家的思考。所以，对于我的这篇博文，如果你赞同我的观点，我会感到高兴，如果你会去认真地深入思考，我也会高兴，如果你反对，没关系，可以讨论。在此之前，我想说明一下我观点里的这个“专职QA”是怎么定义的。其是很多公司成立的专门做测试的技术人员，仅测试不开发。这些QA对于软件开发技术并不熟悉，甚至不懂。我经历过一些公司都有专职的QA团队（专职的测试人员），自从上个公司我的开发团队在一个项目上被QA部门搞得一团糟，我越来越怀疑专职QA存在在意义。我的观点不一定对，但请让我鲜明地表达一下——我觉得是不需要全职的QA的，甚至不需要QA这一专职角色或部门，因为，不懂开发的人必然做不好测试。就像不懂开发的研发经理必然管不好研发团队一样。我越来越觉得Dev应该应该是做测试最合适的人选，这必然是未来的趋势 （因为我已经看到了中国程序员的进步，相比起10年前，今天的程序员已经是非常全面了，再来十年，必然证明我的观点是对的）。在我正在展开说明之前，我想引用两篇文章：两篇文章一篇是 “On testers and testing”(中文翻译)，本文的作者Sriram Krishnan是一名程序员，曾在Yahoo和微软工作过，开发过很多软件，曾被纽约时报报道，写过一本书，本文是他的一篇博客。他在文章中表达了这几个观点——大多数的开发团队并不需要一个独立的测试角色。即使要有，那么所有的开发时间比上所有的测试时间应该 >20:1的。。证据吗？光看看一些从古至今最成功的软件开发团队就知道了。不论是当今的Facebook，还是30年前最初的NT团队，很多伟大 的产品都是出自没有或很少测试人员的团队。开发人员应该测试自己的代码。没什么可说的。背后的道理并不重要。这包括单元测试，全覆盖的自动化测试或手工测试或组合测试。如果你的开发人员不能/不愿意或认为这“不归我管”，那你需要更好的程序员。另一篇文章是邹欣的“现代软件工程讲义 9 测试 QA 的角色和分工”，这是一篇很不错的文章。他在文章里提到了分工的必要性，比如第三方的鉴定机构，并且也指出了分工的一些问题，比如，画地为牢的分工，无明确责任的分工，等，这些问题直接命中了分工的要害。我隐约觉得，我和邹欣的很多观点是相同的，我们内容上是相同的，只是形式上还有分歧。另外，我的观点太鲜明了，从而容易导向极端的理解。你看，我们都同意，Dev要懂测试，QA要懂开发，只不过分工不同，既然你中有我，我中有你，那就不要分彼此了，一起携手开发测试吧。（另外，我个人觉得不懂开发的测试人员不可能测试得好） 我的故事我再说说我最糟糕的QA经历吧，这个公司的QA部门只做测试，他们的leader觉得所有的test design和test 的过程都不需要Dev参与，他们是独立于Dev之外的部门，他们几乎不关心Dev的设计和实现，他们只关心能跑通他们自己设计的test case。但是去执行Test Case的时候，又需要Dev的支持，尤其在环境设置，测试工具使用，确认是否是bug方面，全都在消耗着Dev的资源，最扯的是，他们对任何线上的问题 不负责，反正出了问题由Dev加班搞定。我有一次私自review他们的test case的时候，发现很多的test case这样写到 –“Expected Result：Make sure every thing is fine” ，WTF，什么叫“Every thing is fine”？！而在test case design的时候，没有说明test environment/configuration 是什么？没有说明test data在哪里？Test Case、Test Data、Test Configuration都没有版本控制，还有很多Test Case设计得非常冗余（多个Test Case只测试了一个功能），不懂得分析Function Point就做Test Design。另外，我不知道他们为什么那么热衷于设计一堆各式各样的Negative Test Case，而有很多Positive的Test Case没有覆盖到。为什么呢，因为他们不知道开发和设计的细节，所以没有办法设计出Effective的Test Case，只能从需求和表面上做黑盒。在做性能测试的时候，需要Dev手把手的教怎么做性能测试，如何找到系统性能极限，如何测试系统的latency，如何观察系统的负载（CPU，内存，网络带宽，磁盘和网卡I/O，内存换页……）如何做Soak Test，如何观察各个线程的资源使用情况，如何通过配置网络交换机来模拟各种网络错误，等等，等等。测试做得也不认真，大量的False Alarm，都是环境问题，比如：安装新版本后没有重启服务，没有使用新的配置文件，网络配置，等等，等等。在项目快要上线前的一周，我又私自查看了一下他们的Test Result，我看到5天的Soak Test 的内存使用一直往上涨，很明显的内存泄露，这个情况发生在2个月前，但是一直都没有报告，我只好和我的程序员每天都加班到凌晨，赶在上线前解决了这个问 题。但是，QA部门的同学们就像没发生什么事似的，依然正常上下班。哎……为什么会这样？我觉得有这么几点原因（和邹欣的观点一样）给了QA全部测试的权力，但是没有给相应的责任，QA没有体会过软件质量出问题后的痛苦（解决线上问题的压力），导致QA不会主动思考和改进。QA对Dev的开发过程和技术完全不了解，增加了很多QA和Dev的沟通。QA对软件项目的设计和实现要点不了解，导致了很多不有效的测试。注：我无意在这里贬低QA的能力工作。只是我看到了QA因为没有参与开发的一些现实问题。我的观点邹欣对于分工出现的问题给出了两点解决方法：充分授权和信任（Empower team members）各司其职，对项目共同负责（Establish clear accountability and shared responsibility）我的观点是， 理论上正确， *** 作上太虚了。这就像我们国家喊的“为人民服务”的口号一样，没有具体的方法，根本无法落实。我无意在这里贬低QA的工作，我也无意因为这个事走向另一个极端。但是，我在现在公司的经历，还有很多新兴公司的做法，我越来越觉得软件开发，真的不需要专职的QA，更不需要只写代码不懂做测试的专职的Dev。观点如下：1） 开发人员做测试更有效开发人员本来就要测试自己写的软件，如果开发人员不懂测试，或是对测试不专业，那么这就不是一个专业的开发人员。开发人员了解整个软件的设计和开发过程，开发人员是最清楚应该怎么测试的，这包括单元测试，功能测试，性能测试，回归测试，以及Soak Test 等。开发人员知道怎么测试是最有效的。开发人员知道所有的function point，知道fix一个bug后，哪些测试要做回归和验证，哪些不需要。开发人员的技术能力知道怎么才能更好的做测试。很多开发人员只喜欢写代码，不喜欢做测试，或是他们说，开发人员应该关注于开发，而不是测试。这个思路相当的错误。开发人员最应该关注的是软件质量，需要证明自己的开发成果的质量。开发人员如果都不知道怎么做测试，这个开发人员就是一个不合格的开发人员。另外，我始终不明白，为什么不做开发的QA会比Dev在测试上更专业？ 这一点都说不通啊。2）减少沟通，扯皮，和推诿想想下面的这些情况你是否似曾相识？QA 做的测试计划，测试案例设计，测试结果，总是需要Dev来评审和检查。QA在做测试的过程中，总是需要Dev对其测试的环境，配置，过程做指导。QA总是会和Dev争吵某个问题是不是BUG，争吵要不要解决。无论发现什么样的问题，总是Dev去解决，QA从不fix问题。我们总是能听到，线上发生问题的时候，Dev的抱怨QA这样的问题居然没测出来，QA也总会抱怨Dev代码太差，一点也不懂测试，没怎么测就给hand over 给QA了。QA总是会push Dev，这个bug再不fix，你就影响我的进度了。等等，等等。如果没有QA，那么就没有这么多事了，DEV自己的干出来的问题，自己处理，没什么好扯皮的。而一方面，QA说Dev不懂测试，另一方面Dev说QA不懂技术，而我们还要让他们隔离开来，各干各的，这一点都不利于把Dev和QA的代沟给填平了。要让Dev理解QA，让QA理解Dev，减少公说公有理，婆说婆有理的只站在自己立场上的沟通，只有一个方法，那就是让Dev来做测试，让QA来做开发。这样一样，大家都是程序员了。3）吃自己的狗食真的优秀的开发团队都是要吃自己狗食的。这句话的意思是——如果你不能切身体会到自己干的烂事，自己的痛苦，你就不会有想要去改进的动机。没有痛苦，就不会真正地去思考，没有真正的思考，就没有真正的进步。在我现在的公司，程序员要干几乎有的事，从需求分析，设计，编码，集成，测试，部署，运维，OnCall，从头到尾，因为：只有了解了测试的难度，你才明白怎么写出可测试的软件，怎么去做测试的自动化和测试系统。只有自己真正去运维自己的系统，你才知道怎么在程序里写日志，做监控，做统计……只有自己去使用自己的系统，你才明白用户的反馈，用户的想法，和用户的需求。所以，真正的工程师是能真正明白软件开发不单单只是coding，还更要明白整个软件工程。只明白或是只喜欢coding的，那只是码农，不能称之为工程师。4）其它问题关于SDET。全称是Software Development Engineer on Test。像微软，Google， Amazon都有这样的职位。但我不知道这样的职位在微软和Google的比例是多少，在Amazon是非常少的。那么像这样的懂开发的专职测试可以有 吗？我的答案是可以有！但是，我在想，如果一个人懂开发，为什么只让其专职做测试呢？这样的程序员分工合理吗？把程序分成两等公民有意义吗？试问有多少懂开发的程序员愿意只做测试开发呢？所以，SDET在实际的 *** 作中，更多的还是对开发不熟的测试人员。还是哪句话，不懂开发的人是做不好测试的。如果你说Dev对测试不专业，不细心，不认真，那么我们同样也无法保证QA的专业，细心和认真。在Dev上可能出现的问题，在QA也也会一样出现。而出了问题QA不会来加班解决，还是开发人员自己解决。所以，如果QA不用来解决问题，那么，QA怎么可能真正的细心和认真呢？如果你说不要QA的话，Dev人手会不够。你这样想一下，如果把你团队中现有的QA全部变成Dev，然后，大家一起开发，一起测试，亲密无间，沟通方便，你会不会觉得这样会更有效？你有没有发现，在重大问题上，Dev可以帮上QA的忙，但是QA帮不上Dev的忙。第三方中立，你会说人总是测不好自己写的东西，因为有思维定式。没错，我同意。但是如果是Dev交叉测试呢？你可能会说开发人员会有开发人员的思维定式。那这只能说明开发人员还不成熟，他们还不合格。没关系，只要吃自己的狗食，痛苦了，就会负责的。磨刀不误砍柴功。如果你开发的东西自己在用，那么自己就是自己天然的QA，如果有别的团队也在用你开发的模块，那么，别的团队也就很自然地在帮你做测试了，而且是最真实的测试。你可能会说吃狗食就是个笑话，因为如果是我，我把干烂的事，就离职走人了，让别人去吃我的狗食。这个在现实中 的确会发生，也是很现实的。但是想一想，你为什么在一开始让他把事干烂了？另外，如果你的团队在设计评审和代码评审里没有把好关，让某人把事给干烂了，那 么这个人的离职带来的问题还是这个团队来扛，于是整个团队都在吃自己的狗食，挺公平的。痛苦过一次，你的团队下次怎么干了，就不敢乱招人了，就不敢随意评 审代码了，就不敢让人只做一块东西了。最终还是没有逃脱吃狗食的范畴。关于系统集成测试。所谓集成测试，就是把多个开发团队开发的模块集中起来测试。因为开发人员可以无法看到全 局，不了解别个团队的系统，所以需要有统管全局的专职的QA进行测试。对这个方面，我并不反对，在实际 *** 作过程中，好像的确用专职的做集成测试的QA更有 效一些。不过，这还是不能让我停止去思考两个问题，1) 如果开发人员看不到全局，他能开发出更好的软件吗？2）这个全职的做集成测试的QA难道不能是各个团队的骨干Dev来组成吗？关于自动化测试。所谓自动化的意思是，这是一个机械的重复劳动。我想让测试人员思考一下，你是否在干这样的事？如果你正在干这样的事，那么，你要思考一下你的价值了。但凡是重复性比较高的机械性的劳动，总有一天都会被机器取代的。关于线上测试。我们都知道，无论自己内测的怎么样，到了用户那边，总是会有一些测试不到的东西。所以，有些公 司会整出个UAT，用户验收测试。做产品的公司会叫Beta测试。无论怎么样，你总是要上生产线做真正测试的。对于互联网企业来说，生产线上测试有的在玩 A/B测试，有的玩部分用户测试，比如，新上线的功能只有10%的用户可以访问得到，这样不会因为出问题让全部用户受到影响。做这种测试的人必然是开发人 员。好吧，我暂时写这么多，我会视大家的讨论再补充我的观点的。—– update —–一些人觉得我是在泄私愤，我能够理解为什么我会被这样误解，但是没有关系，很多新东西新观点总是会被误解的，我坦然面对。（全文完）

接触过原文后的解决方案：

1 将每段英文冒号和三角标记之间的空格改成Tab，再设置一下悬挂缩进到三角标记的位置（我这里看是 5 字符），可以达到图一中的效果；

2 将格式设置为：“段落左对齐制表符-15字符-无前导符，悬挂缩进459字符，对齐方式左对齐”也可以达到图一中的样式。

文本缩进位置就是每一段第二行缩进的距离，对齐位置就是1981开始的位置（项目符号之后文字开始的位置），他们之间的长度差就是1986到三角的尺寸，这个你可以试一下，手动调整一下。

走出软件作坊 （作者阿朱，如今是京东技术学院负责人）

冒号课堂 （作者郑晖，貌似在做ios独立开发）

程序员的自我修养 （第一作者俞甲子，创办了两个游戏公司，第一个已经成功卖掉。第三作者潘爱民，目前是阿里云首席架构师）

软件调试 （作者张银奎）

Windows内核原理与实现 （作者潘爱民）

Python源码剖析 （作者陈儒）

还有不少好作者，就不一一列举了。推荐我近年来合作出版的好书的作者：

@吴军 （见：吴军博士是一个怎样的人？）

@邹欣 （见：邹欣老师怎样给学生上课和如何成为一名踏实靠谱、勤奋刻苦、高瞻远瞩、能言善辩又脾气棒棒的程序员？ ）

@刘未鹏 （见：刘未鹏是谁？ ）

程序员需要学习的知识地很多的，需要不断的看书学习，才能不断的提升自己。下面是由我给大家带来关于程序员必读的书籍，希望对大家有帮助!

程序员必读的书籍

1重构：改善既有代码的设计(软件开发的不朽经典)

何为重构，一言以蔽之，就是在不改变外部行为的前提下，有条不紊地改善代码。本书虽然使用Java语言书写示例代码，但是其概念与思想同样适合 于其他语言。书中，作者以一些平淡无奇，甚至带有坏味道的代码开始，一步一步地修改转变成更加灵活，可重用的代码。通过书中的示例，你会清楚地明白什么才 是整洁的代码。重构其实依然成为 经验 丰富的程序员的必备技能，当你想要改善重构代码时，读一读这本书就会让你有章可循，豁然开朗。

2代码整洁之道(Robert C Martin力作，韩磊献译)

这是我最喜欢的一本书，不止一次我将它推荐给我的同事，读者还有学生。我认为它可以称得上软件开发与编码方便最好的一本书。Bob大叔我想无需做介绍，他写 过一个关于敏捷开发的系列书籍，我的书架上就有他的 《代码整洁之道》 , 《程序员的职业素养》 ， 《敏捷软件开发(原则模式与实践)》 ， 《敏捷软件开发(原则模式与实践)》 ， 《UML for Java For Programmers》 ， 《Extreme Programming in Practice》等这些书籍。虽然他的这些书有点老旧，但是这些书仍然很有价值，纵使数十年之后，这些书依旧受用，尤其是在面向对象编程方面。 本书不仅仅是告诉你要做什么，还教会你什么不能做。书中有关于代码味道的一个章节，全面列举了大多数程序员遇到的各种错误，其后的章节则详细描述如何纠正 这些错误。比如如何将过长的switch声明转换成遵循开放闭合原则的模型，如何利用集成和多态。再次啰嗦一下，这本书确实值得每个程序员拥有。和上本书 一样，书中的例子使用Java语言，但依然适合使用其他面向对象编程语言的开发者阅读。想要撸的一手好码，这本书必不可少。

3代码大全

两届Software Jolt Award震撼大奖得主!软件开发世界的地图，经典中的经典

想必这本书大家都曾阅读过，这就是鼎鼎大名的《代码大全》，从某个角度看，它其实就是C++版的《代码整洁之道》。本书的目标就是帮开发者使用 做高质的代码写出更好的软件。同样书中也涉及了编程中常见问题和最佳实践。这本书也可以称得上是必读书籍，尤其是对于C和C++程序员。《代码大全(第2 版)》中所论述的技术不仅填补了初级与高级编程实践之间的空白，而且也为程序员们提供了一个有关软件开发技术的信息来源。《代码大全(第2版)》对经验丰 富的程序员、技术带头人、自学的程序员及没有太多编程经验的学生都是大有裨益的。可以说，只要您具有一定的编程基础，想成为一名优秀的程序员，阅读《代码 大全(第2版)》都不会让您失望。

4单元测试的艺术

世界级软件开发大师，设计模式和敏捷开发先驱，“Bob大叔”Robert C Martin强力推荐

如果非要做一件改善项目，提高开发者水平的事情，我想那就是让开发者掌握单元测试的能力。对于专业的开发者来说，单元测试是一项必备的技能，多数的程序员 却不具备TDD(测试驱动开发)的能力。我虽然在不太遵循TDD这种模式，但是也会为自己写的或维护的代码编写单元测试。对于工程来说，开源项目基本都严 格遵守执行单元测试，而很多商业的工程则在单元测试方面有所缺失。一个拥有单元测试的项目会变得更加容易维护和更改。本书会介绍成功的项目与失败项目的差 别，可维护的代码库与不可维护的代码库之间的区别。本书示例为NET代码，但这并不会影响你了解单元测试。如果你是一名技术负责人或者项目负责人，这本 书可以帮你更好地把控项目代码质量。如果你看Java更舒服的话，也可以看一看这本书 《JUnit实战(第2版)》 。

5精益软件开发管理之道

《精益软件开发管理之道》是一本软件开发 方法 学的书。作者从24个不同的视角，在更大的空间、时间、行业、 文化 背景下，考察了敏捷和精益方法。 《精益软件开发管理之道》详细阐述了敏捷和精益开发方法取得成功的深层原因。《精益软件开发管理之道》包括以下内容：系统思考，以适当足够的方式关注客 户;技术杰出，介绍了杰出软件开发的基础-低耦合的架构、测试驱动的开发过程等;可靠交付，讨论了工作流和日程计划，以及反馈的重要作用;无情改进，讨论 了所有精益组织的基本特点：持续不断、永不满足的改进;卓越的人，卓越的结果来自于卓越的人;一致的领导，讨论在领导团队中达成一致。

6设计模式：可复用面向对象软件的基础

这本书要么你读过，要么就是听说过，这就是经典的GOF(Gang of Four 中文译为_)设计模式一书。该书作者为四人，分别是Eric Gamma, Richard Helm, Ralph Johnson, 和John Vissides。四位顶尖的面向对象领域专家精心选取了最具价值的设计实践，加以分类整理和命名，并用简洁而易于重用的形式表达出来。本书已经成为面向 对象技术人员的圣经和词典，书中定义的23个模式逐渐成为开发界技术交流所必备的基础知识和语汇。使用这些设计模式，我们可以设计出灵活，优雅和可重用的 可扩展的设计。

7细说PHP

51CTO“最受读者喜爱的原创IT技术图书”奖

《细说PHP》编写的宗旨是让读者能拥有一本PHP方面的学习和开发使用的最好书籍，对所罗列出的每个知识点都进行了细化和延伸，并力求讲解到位，让读 者可以轻松地读懂。对于几乎每个知识点都有对应且详实的可运行的代码配套，对所有实例代码都附有详细注释、说明及运行效果图。另外在每个章节的最后还为读 者安排了大量的和本章知识点配套的授课课件及自测试题(附加在光盘中)，能更好地帮助读者掌握理论知识点，提高实际编程能力，寓学于练。对于入门与提高 PHP技术起到关键作用。

《细说PHP》作者高洛峰。现任北京LAMP兄弟连[1](易第优 教育 )教学总监，五年软件开发工作经验，四年IT教学工作经验。曾在多家上市企业担任过技 术总监、项目经理、高级软件工程师等职务，具有扎实的技术功底。国内资深的高级技术认证讲师，从事IT培训以来累计授课长达6000课时以上，培训近千名 学员成功走向IT岗位，具有丰富的IT教学经验。

程序员的专业技术书

1、《数学之美》第二版

获奖畅销书《数学之美》第一版荣获国家图书馆第八届文津图书奖。

第一版入选广电总局“2014年向全国青少年推荐百种优秀图书书目”，荣获2012-2013年度全行业优秀畅销书。

信息领域大学生必读好书，央视新闻推荐的学科敲门砖。

新版增加了大数据和机器学习等最新内容，以满足人们对当下技术的学习需求;同时，根据专家和读者的反馈更正了错漏，并更新了部分内容。

《数 学之美》第一版上市后深受广大读者欢迎，并荣获国家图书馆第八届文津图书奖。读者说，读了《数学之美》，才发现大学时学的数学知识，比如马尔科夫链、矩阵 计算，甚至余弦函数原来都如此亲切，并且栩栩如生，才发现自然语言和信息处理这么有趣。而今，数学在信息产业中的应用越来越广泛，因此，作者在第二版中增 加了一些内容，尤其是针对大数据和机器学习的内容，以便满足人们对当下技术的学习需求。

2、文明之光 第三册

吴军博士继获奖畅销书《浪潮之巅》、《数学之美》之后的跨界之作

为您讲述他眼中的超越上下五千年的人类文明史

随文津奖得主一起体会科技与人文之美

作 者所选的创作素材来自于十几年来在世界各地的所见所闻，对其内容都有着深刻的体会和认识。《文明之光》系列第三册每个章节依然相对独立，书中全景式地展现 了人类文明发展历程中的多样性。内容涉及音乐、美术、计算机、互联网、金融、硅谷对世界科技发展的启迪、微粒子和宇宙天文学、环境保护八个专题。

3、构建之法：现代软件工程

“做中学 Learning By Doing”的现代方式教授软件工程

李未院士鼎力推荐，众多软工教师一致好评

微软研发总监邹欣力作

推荐软件工程专业学子阅读，了解软件工程真正内涵，懂得“工程”二字真正含义，知道软件工程和计算机科学的区别。了解之后，就知道为何软件工程是就业含金量较高的行业了。

书中设想了大量的场景“学”和“习”，并且用了大量的类比，非常生动有趣。这本教材也对软件工程课老师提出了更高的要求;对学生而言，同样面临着要付出怎样的努力才能学到“干货”的选择。

《构建之法：现代软件工程》共分17章，对照美国ACM/IEEE2013年新出版的计算机科学教学指导 (Computer ScienceCurricula 2013)中的软件工程相关部分，这本教材覆盖了其中大多数Core-Tier1和Core-Tier2的内容。可以说，全书对软件工程内容的覆盖不逊于 任何一本现行的教材，同时讲述了业界最新实践方法。

程序员看的好书籍

1《哥德尔、埃舍尔、巴赫》

豆瓣评分：94 分

作者简介：道格拉斯·理查·郝夫斯台特，中文名侯世达，美国学者、作家。他的主要研究领域包括意识、类比、艺术创造、文学翻译以及数学和物理学探索。 因其著作《哥德尔、埃舍尔、巴赫》获得普立兹奖(非小说类别)和美国国家经典奖(科学类别)。

推荐理由：这是一部天书。在数学，绘画，音乐和 故事 中畅游，却在探讨哲学中最深刻的问题：意识和灵魂如何产生，从哲学角度探讨人工智能和人类智能。当你看完书后，也许你具体记不得太多细节，但是不经意间你会发现它已经深深地影响了你的世界观。

2《算法导论》

豆瓣评分：94 分

作者简介：托马斯·科尔曼，达特茅斯学院计算机科学系教授、系主任;查尔斯·雷瑟尔森，麻省理工学院计算机科学与电气工程系教授，他目前主持 MIT 超级计算技术研究组，并是 MIT 计算机科学和人工智能实验室计算理论研究组的成员;罗纳德·李维斯特，现任麻省理工学院电子工程和计算机科学系安德鲁与厄纳·维特尔比(Andrew and Erna Viterbi)教授。他是 MIT 计算机科学和人工智能实验室的成员，并领导着其中的信息安全和隐私中心。他现在担任国家密码学会的负责人;克利福德·斯坦，哥伦比亚大学计算机科学系和工业工程与运筹学系教授，他还是工业工程与运筹学系的系主任。

推荐理由：这本书深入浅出，全面地介绍了计算机算法。对每一个算法的分析既易于理解又十分有趣，并保持了数学严谨性。本书的设计目标全面，适用于多种用途。涵盖的内容有：算法在计算中的作用，概率分析和随机算法的介绍。书中专门讨论了线性规划，介绍了动态规划的两个应用，随机化和线性规划技术的近似算法等，还有有关递归求解、快速排序中用到的划分方法与期望线性时间顺序统计算法，以及对贪心算法元素的讨论。此书还介绍了对强连通子图算法正确性的证明，对哈密顿回路和子集求和问题的 NP 完全性的证明等内容。

1 程序员们的专业技术书分享

2 linux程序员必看书籍推荐

3 java程序员必看的书籍推荐

4 清华大学推荐的青少年阅读书目

5 文艺青年必看的书

以上就是关于参加微软学生夏令营是一种什么样的体验全部的内容，包括:参加微软学生夏令营是一种什么样的体验、我们需要专职的 QA 吗、如何在Word中设置多重悬挂缩进等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！