完美代码(让你编出无懈可击的完美代码)(china-pub全国首发)
点击看大图基本信息
- 原书名： Solid Code
- 原出版社： Microsoft Press
- 作者： (美)Donis Marshall John Bruno [作译者介绍]
- 译者： 徐旭铭
- 丛书名： 开发人员专业技术丛书
- 出版社：机械工业出版社
- ISBN：9787111292401
- 上架时间：2010-1-29
- 出版日期：2010 年1月
- 开本：16开
- 页码：229
- 版次：1-1
- 所属分类：
计算机 > 软件与程序设计 > 综合 > 程序(设计)理论
编辑推荐
采用一流的工程实践来帮助你编写更健壮、无错的代码。两位微软的.NET开发专家与你分享优化软件开发生命周期的真实案例和经过实战考验的解决方案——从避免代价昂贵的编程陷阱，到提高开发团队整体效率的方法等。无论你是来自哪个层次的托管代码程序员，都能在这里找到设计、原型开发、实现、调试以及测试的技巧，进一步提升代码的品质。
推荐阅读
内容简介回到顶部↑
本书简单明了地介绍了软件开发中的最佳实践，展示了工程流程在编写优质代码上的重要性以及测试的重要性，总结了很多资深工程师的经验教训，并提供了很多真实案例。书中介绍的经验可以应用到产品开发周期的每个环节，从设计到开发以及最后的发布和维护。本书的中心思想就是要在设计和实现的过程中改进代码质量，包括类建模、性能、安全性、内存使用以及调试，帮助读者构建完美的项目。本书适合专业及业余程序员阅读。
采用一流的工程实践来帮助你编写更健壮、无错的代码。两位微软的.net开发专家与你分享优化软件开发生命周期的真实案例和经过实战考验的解决方案——从避免代价昂贵的编程陷阱，到提高开发团队整体效率的方法等。无论你是来自哪个层次的托管代码程序员，都能在这里找到设计、原型开发、实现、调试以及测试的技巧，进一步提升代码的品质。
本书涉及开发流程中每一个阶段的优化（从设计到测试），以及如何开发出更优质的应用程序软件：
通过元编程来降低代码的复杂度，同时还能增加灵活性和可维护性。
把性能当做一项功能，并且在开发周期中对它进行管理。
为应用程序的伸缩性采取各种最佳实践。
通过预防性的安全措施来抵御各种恶意攻击。
在运行之前通过防御性编程来捕捉错误。
在每日工程流程里植入自动化构建、代码分析和测试等工作。
实现更好的源码控制管理和提交流程。
建立一套质量驱动、基于里程碑的项目节奏，并最终产生更好的结果。
采用一流的工程实践来帮助你编写更健壮、无错的代码。两位微软的.net开发专家与你分享优化软件开发生命周期的真实案例和经过实战考验的解决方案——从避免代价昂贵的编程陷阱，到提高开发团队整体效率的方法等。无论你是来自哪个层次的托管代码程序员，都能在这里找到设计、原型开发、实现、调试以及测试的技巧，进一步提升代码的品质。
本书涉及开发流程中每一个阶段的优化（从设计到测试），以及如何开发出更优质的应用程序软件：
通过元编程来降低代码的复杂度，同时还能增加灵活性和可维护性。
把性能当做一项功能，并且在开发周期中对它进行管理。
为应用程序的伸缩性采取各种最佳实践。
通过预防性的安全措施来抵御各种恶意攻击。
在运行之前通过防御性编程来捕捉错误。
在每日工程流程里植入自动化构建、代码分析和测试等工作。
实现更好的源码控制管理和提交流程。
建立一套质量驱动、基于里程碑的项目节奏，并最终产生更好的结果。
作译者回到顶部↑
本书提供作译者介绍
Donis Marshall 是Debuglive.com的CEO，他管理的专家软件工程师团队开发出第一个基于Web的Windows应用程序调试器。凭借20年的开发经验以及深厚的微软.NET背景，他编写了好几本书，其中包括《Programming Microsoft Visual C# 2008: The Language and .NET Security Programming》。Donis还是一名培训师和咨询师，专门讲授并主持关于.NET编程、调试、安全性以及设计和架构的研讨会。
John Bruno 是微软的资深程序经理，有着超过10年的应用开发经验，他擅长使用微软.NET技术来设计并构建可扩展的.. << 查看详细
John Bruno 是微软的资深程序经理，有着超过10年的应用开发经验，他擅长使用微软.NET技术来设计并构建可扩展的.. << 查看详细
目录回到顶部↑
专家推荐
序
前言
第1章敏捷世界里的代码质量
1.1软件开发的传统方法
1.2软件开发的敏捷方法
1.2.1scrum
1.2.2extreme programming
1.2.3测试驱动开发
1.3尽早进行质量控制
1.4微软内幕：windows live hotmail工程
1.4.1工程准则
1.4.2成功的关键因素
1.5编写坚实代码的方法
1.5.1专注设计
1.5.2防御和调试
1.5.3分析与测试
1.5.4改进流程和态度
1.6总结
1.7本章要点
序
前言
第1章敏捷世界里的代码质量
1.1软件开发的传统方法
1.2软件开发的敏捷方法
1.2.1scrum
1.2.2extreme programming
1.2.3测试驱动开发
1.3尽早进行质量控制
1.4微软内幕：windows live hotmail工程
1.4.1工程准则
1.4.2成功的关键因素
1.5编写坚实代码的方法
1.5.1专注设计
1.5.2防御和调试
1.5.3分析与测试
1.5.4改进流程和态度
1.6总结
1.7本章要点
前言回到顶部↑
在过去多年里软件开发已经有了很大的演化。编程语言和快速开发工具（比如NET和 Visual Studio 2008）的进步让软件工业可以构建更高质量的软件，速度更快，成本更低，更新更频繁。尽管这种对软件和工具以及过程演化的需求日益增加，但构建和发布高质量的软件对于软件项目的所有参与者，特别是程序员来说，仍然是一项艰难的工作。幸运的是，本书包含了应用程序工程师在开发健壮的代码中所需要的工程实践、过程、策略和技术等一切最佳要素。
本书探讨了软件开发中几乎每一个方面所需的最佳实践，以达到更高的代码质量。这本书提供了来自资深工程师的实践经验，可以应用到产品开发周期里的每一个环节：设计，构造原型，实现，调试，测试。这些宝贵的资料和建议还进一步得到了来自真实世界实例的支持，这些来自微软内部的工程团队包括了（但不限于）Windows Live Hotmail和Live Search团队。
本书的读者
本书适合软件开发里每一个环节的参与者阅读。特别是那些在构建高质量软件方面寻求最佳实践和建议的应用程序工程师。书中很多部分都展示了工程流程在编写优质代码上的重要性。其他部分则着重于测试的重要性。本书的中心思想就是要在设计和实现的过程中改进代码质量，包括类建模、性能、安全性、内存使用以及调试。
专业和业余程序员都可以阅读本书。我们假设读者对编程概念和C#面向对象编程具有基本的理解，而水平则没有要求。本书主要是关于托管代码应用程序开发的最佳实践，书里所探讨的话题应该能引起各级托管代码程序员的共鸣。
本书的组织
本书的组织形式和应用程序开发生命周期非常相似。各个章并不是分割成很多部分，而是根据四个关键的原则组织在一起。第1章里列出了这些原则：专注设计、防御和调试，分析与测试，以及改进流程和态度。
·专注设计 本书最重要的主题之一就是：经过深思熟虑的设计是提升产品整体质量的重要途径。为了支持这一主题，我们将探讨很多不同的实践，例如类设计和原型开发、元编程、性能、伸缩性以及安全性等话题。
·防御和调试 出色的设计是构建高质量软件应用的关键，但是理解那些会阻碍发布无错代码的陷阱的重要性也同样不能忽视。根据这一原则，我们要讨论的话题包括内存管理、防御性编程技术以及调试。
·分析与测试 即使最伟大的程序员遵循了所有推荐的最佳实践，他仍然会写出有bug的代码。因此，讨论如何进行代码分析以及测试的方法是进一步提升代码质量的重要环节。
·改进流程和态度 除了最佳实践以外，工程的流程和文化也能对产品的质量产生巨大的影响。我们探讨了提升团队的效率以及追求质量几个重要话题。
系统要求
至少要有以下的软件和硬件环境才能在32位Windows环境下编译执行本书中的示例代码：
·Windows Vista，Windows Server 2003 with Service Pack 1，Windows Server 2008，或者Windows XP with Service Pack 2。
·Visual Studio 2008 Team System。
·2.0GHz CPU，推荐2.6 GHz CPU。
·512MB内存，推荐1GB内存。
·8 GB 硬盘安装空间，推荐20GB硬盘空间。
·CD-ROM 或 DVD-ROM驱动器。
·微软或兼容鼠标。
本书探讨了软件开发中几乎每一个方面所需的最佳实践，以达到更高的代码质量。这本书提供了来自资深工程师的实践经验，可以应用到产品开发周期里的每一个环节：设计，构造原型，实现，调试，测试。这些宝贵的资料和建议还进一步得到了来自真实世界实例的支持，这些来自微软内部的工程团队包括了（但不限于）Windows Live Hotmail和Live Search团队。
本书的读者
本书适合软件开发里每一个环节的参与者阅读。特别是那些在构建高质量软件方面寻求最佳实践和建议的应用程序工程师。书中很多部分都展示了工程流程在编写优质代码上的重要性。其他部分则着重于测试的重要性。本书的中心思想就是要在设计和实现的过程中改进代码质量，包括类建模、性能、安全性、内存使用以及调试。
专业和业余程序员都可以阅读本书。我们假设读者对编程概念和C#面向对象编程具有基本的理解，而水平则没有要求。本书主要是关于托管代码应用程序开发的最佳实践，书里所探讨的话题应该能引起各级托管代码程序员的共鸣。
本书的组织
本书的组织形式和应用程序开发生命周期非常相似。各个章并不是分割成很多部分，而是根据四个关键的原则组织在一起。第1章里列出了这些原则：专注设计、防御和调试，分析与测试，以及改进流程和态度。
·专注设计 本书最重要的主题之一就是：经过深思熟虑的设计是提升产品整体质量的重要途径。为了支持这一主题，我们将探讨很多不同的实践，例如类设计和原型开发、元编程、性能、伸缩性以及安全性等话题。
·防御和调试 出色的设计是构建高质量软件应用的关键，但是理解那些会阻碍发布无错代码的陷阱的重要性也同样不能忽视。根据这一原则，我们要讨论的话题包括内存管理、防御性编程技术以及调试。
·分析与测试 即使最伟大的程序员遵循了所有推荐的最佳实践，他仍然会写出有bug的代码。因此，讨论如何进行代码分析以及测试的方法是进一步提升代码质量的重要环节。
·改进流程和态度 除了最佳实践以外，工程的流程和文化也能对产品的质量产生巨大的影响。我们探讨了提升团队的效率以及追求质量几个重要话题。
系统要求
至少要有以下的软件和硬件环境才能在32位Windows环境下编译执行本书中的示例代码：
·Windows Vista，Windows Server 2003 with Service Pack 1，Windows Server 2008，或者Windows XP with Service Pack 2。
·Visual Studio 2008 Team System。
·2.0GHz CPU，推荐2.6 GHz CPU。
·512MB内存，推荐1GB内存。
·8 GB 硬盘安装空间，推荐20GB硬盘空间。
·CD-ROM 或 DVD-ROM驱动器。
·微软或兼容鼠标。
序言回到顶部↑
软件工程和传统意义上的工程完全不同。作为一名软件程序员，我非常自豪可以自称是一名工程师。工程师能够通过细致的计划思考并制造出一次就能工作的东西。所以，在我的职业里包含“工程师”这个词实在是一件很酷的事情。
我们先来看看要是把普通的软件工程方法应用到航空工程里会发生什么事情。一驾飞机正停在登机口等待乘客登机，这时一名航空工程师(不管是一时兴起还是被老板强迫)打算要换掉尾翼部分。毕竟那只是一个尾翼而已，直接把它弄下来换一个上去就好了。绝对没问题，绝对能行!要是航空工程采用和软件工程一样的流程的话，我估计乘客都会瞬间逃离飞机的。但是，这类改变在软件项目的世界里基本上每天都要发生。过去有种白相矛盾的老笑话说是“军事情报”，我觉得“软件工程”也属于这类范畴(这种笑话就是把两个矛盾或者互斥的问放在一起，通常都是为了幽默搞笑——译者注)。而更让人头疼的是，虽然软件真的是在“统治”这个世界，但是几乎所有人在创建它时所采用的方法无一可以称得上是“工程”。
为什么我敢说我现在正在使用的计算机可以正常工作，但是我正在使用的程序(Microsoft Word)却可能会搞乱我列表的自动编号呢?我这么说可能会得罪我那些电子工程的朋友，但是我还是要说，因为硬件比较简单。电子工程师要对付的只是很有限的输入，不像软件工程师要面对几乎无限可能的输入。
管理学也认为电子工程是“真正的工程”，所以管理的时候可以给予适当的时间和资源。而软件业，作为一个独特的领域，还算不上成熟，它真正存在的时间不是很长。其实说起来，我比软件这个行业年轻不了多少，所以我“不成熟”的看法才能透露出这些问题。要是我和电子工程一样老的话，那么现在我就该躺在坟墓里写书了。
软件开发的另一个难题有时候是软件工程师自己。老实说，成为一名软件工程师的门槛还是很低的。我就是一个现成的例子：在获得计算机科学学士学位之前，我就已经是一名全职的软件工程师了。当初获得这份写程序的工作只不过是因为我在面试的时候“特别能吹”而已。我的老板根本就不在乎我没有受过正规的教育，毕竟我要求的工资比较低。
在所有真正的工程领域里，你都必须先获得认证资格后才能在名字里加上专业工程师(Pro-fessional Engineer，PE)的头衔。在软件行业里就没这种规定。其中一部分原因是这个行业太年轻了，没有人知道在从业之前应该必须掌握什么知识才能成为一个软件工程师。而在其他领域里，专业工程师通常意味着大量管理上的责任。如果一名有资格的工程师觉得一个设计是行不通的，她就不会在计划书上签名，项目也就不可以进行下去。这就迫使管理层在做计划的过程中更加严谨。同时，如果签收了一个项目，那就代表专业工程师愿意在出错的时候承担道义和法律上的责任。你有没有准备好承受你的软件设计所带来的道义和法律上的责任呢?只要我们的行业还没有达到那种程度，我们就不能真正自称是传统意义上的工程师。
在我从业近20年的岁月里，软件开发行业已经有了长足的进步。管理高层终于意识到软件项目的失败会给公司带来巨大的损失。有兴趣的话可以看一下Robert Charette在《IEEE Spectrum》2005年9月一期(／http：／／www．spectrum．ieee．org／sep05／1685)上发表的文章《为什么软件会失败?》(Why SoftwareFails?)里列出的重大失败。正因为代价是如此之大，所以有些管理高层终于第一次开始正视问题，并为软件项目的启动、计划和实现提供真正的资源。虽然我们要走的路还很长，但是这种来自管理层的真正介入是我在这个行业里看到的最大的变化之一。
在实际工作的层面上，软件开发里最喜人的变化是几乎所有的程序员都开始意识到测试代码的重要性。现在已经很少能听到一个程序员直接把代码扔给QA组还期望能一切正常了。这对我们这个行业来说是一个巨大的进步，它让很多团队终于能够按期达到所要求的品质。作为一个把整个职业生涯都投入在调试和性能调节上的人，我真的对我们的行业在测试上变得成熟而感到欣慰。和所有好的改变一样，专注测试虽然是从个人做起，但是它的好处却可以影响到整个组织。
还有一个进步就是我们的工具和环境变得越来越好。在．NET下，测试代码变得非常容易，这也就意味着更多人将参与测试。另外，抽象层正在逐渐上移，所以我们不再需要在计算机上处理所有的事情。例如，如果你需要调用一个Web服务，你不需要手动打开一个端口，编写TCP／IP包，调用网络驱动程序，等待数据返回，然后解析返回数据。这一切现在只要一个方法调用就可以完成。这种更好的抽象层让我们可以把时间花在软件项目中更重要的部分：真正的需求和帮助用户解决问题。
在软件开发真正成为工程领域之前，我们还有很长的路要走，但是这些信号都是很令人鼓舞的。我觉得，当我们最终开始把测试当做是一门专业的时候(把它看得和开发一样，甚至更重要的)，就又会发生巨大的变革。尽管在我退休之前大概是看不到软件工程的这一转变了，不过我对现在的发展十分有信心。让我们一起学习，努力推动，这样总有一天我们可以自称是真正的工程师。
本书是把软件纳入工程领域里重要的一步。书店里关于编程的书最多的是两种，一种是泛泛而谈的软件管理类，另一种是面面俱到的技术揭秘类，对于后一种，我总是不太喜欢。当然这种书有它们的用处，有时候也很有帮助，但是我们缺乏的是专门讨论真实世界里团队软件开发的书籍。这种技术在项目中所占的比重很小，但是它对软件项目的发布是最大的挑战。本书在管理书籍和技术书籍之间做到了出色的平衡。从如何进行软件建模，到安全性设计，再到防御性编程，Donis和John向你展示了可以改进开发工作的各种最佳实践。阅读本书就像是在一位顶极的开发经理的带领下体验一个出色的项目，就像是和出色的同事一起工作。
这本书写得非常出彩，我特别喜欢它重点强调的计划和准备工作。我公司(Wintellect)曾经为很多项目救火，大多都是由于它们最初糟糕的计划所导致的后果。／细细研读这些章节，你就可以避免那些可能浪费你大量金钱和时间的错误。这本书指出的另一个问题是把性能调节和安全性分析留到项目的最后阶段。正如书中第4章的标题所指出的，“性能也是功能”。在那些章节中，箴言的价值都是无可估量的。最后，书里还强调了即使代码已经进入了维护阶段，还是能从先前的编码和调试中获取益处。即使像我这样在这个领域里耕耘了将近20年的人，还是从这本书里学到了很多好的方法。
不仅每个程序员都应该读一读这本书，而且公司里的其他人也可以读一读。向你的经理，经理的经理，甚至经理的经理的经理推荐这本书吧!不管是什么公司，我经常会被管理高层问到的一个问题就是：“微软是怎么开发软件的?”在这本书里，大多数章节中都有一个微软内幕小节，让你的老板看看就可以知道微软是如何解决那些当今最大型的应用程序中的问题的。开始阅读吧!现在轮到你来帮助我们的行业向真正的工程标准迈进了。
John Robbins
Wintellect联合创始人
我们先来看看要是把普通的软件工程方法应用到航空工程里会发生什么事情。一驾飞机正停在登机口等待乘客登机，这时一名航空工程师(不管是一时兴起还是被老板强迫)打算要换掉尾翼部分。毕竟那只是一个尾翼而已，直接把它弄下来换一个上去就好了。绝对没问题，绝对能行!要是航空工程采用和软件工程一样的流程的话，我估计乘客都会瞬间逃离飞机的。但是，这类改变在软件项目的世界里基本上每天都要发生。过去有种白相矛盾的老笑话说是“军事情报”，我觉得“软件工程”也属于这类范畴(这种笑话就是把两个矛盾或者互斥的问放在一起，通常都是为了幽默搞笑——译者注)。而更让人头疼的是，虽然软件真的是在“统治”这个世界，但是几乎所有人在创建它时所采用的方法无一可以称得上是“工程”。
为什么我敢说我现在正在使用的计算机可以正常工作，但是我正在使用的程序(Microsoft Word)却可能会搞乱我列表的自动编号呢?我这么说可能会得罪我那些电子工程的朋友，但是我还是要说，因为硬件比较简单。电子工程师要对付的只是很有限的输入，不像软件工程师要面对几乎无限可能的输入。
管理学也认为电子工程是“真正的工程”，所以管理的时候可以给予适当的时间和资源。而软件业，作为一个独特的领域，还算不上成熟，它真正存在的时间不是很长。其实说起来，我比软件这个行业年轻不了多少，所以我“不成熟”的看法才能透露出这些问题。要是我和电子工程一样老的话，那么现在我就该躺在坟墓里写书了。
软件开发的另一个难题有时候是软件工程师自己。老实说，成为一名软件工程师的门槛还是很低的。我就是一个现成的例子：在获得计算机科学学士学位之前，我就已经是一名全职的软件工程师了。当初获得这份写程序的工作只不过是因为我在面试的时候“特别能吹”而已。我的老板根本就不在乎我没有受过正规的教育，毕竟我要求的工资比较低。
在所有真正的工程领域里，你都必须先获得认证资格后才能在名字里加上专业工程师(Pro-fessional Engineer，PE)的头衔。在软件行业里就没这种规定。其中一部分原因是这个行业太年轻了，没有人知道在从业之前应该必须掌握什么知识才能成为一个软件工程师。而在其他领域里，专业工程师通常意味着大量管理上的责任。如果一名有资格的工程师觉得一个设计是行不通的，她就不会在计划书上签名，项目也就不可以进行下去。这就迫使管理层在做计划的过程中更加严谨。同时，如果签收了一个项目，那就代表专业工程师愿意在出错的时候承担道义和法律上的责任。你有没有准备好承受你的软件设计所带来的道义和法律上的责任呢?只要我们的行业还没有达到那种程度，我们就不能真正自称是传统意义上的工程师。
在我从业近20年的岁月里，软件开发行业已经有了长足的进步。管理高层终于意识到软件项目的失败会给公司带来巨大的损失。有兴趣的话可以看一下Robert Charette在《IEEE Spectrum》2005年9月一期(／http：／／www．spectrum．ieee．org／sep05／1685)上发表的文章《为什么软件会失败?》(Why SoftwareFails?)里列出的重大失败。正因为代价是如此之大，所以有些管理高层终于第一次开始正视问题，并为软件项目的启动、计划和实现提供真正的资源。虽然我们要走的路还很长，但是这种来自管理层的真正介入是我在这个行业里看到的最大的变化之一。
在实际工作的层面上，软件开发里最喜人的变化是几乎所有的程序员都开始意识到测试代码的重要性。现在已经很少能听到一个程序员直接把代码扔给QA组还期望能一切正常了。这对我们这个行业来说是一个巨大的进步，它让很多团队终于能够按期达到所要求的品质。作为一个把整个职业生涯都投入在调试和性能调节上的人，我真的对我们的行业在测试上变得成熟而感到欣慰。和所有好的改变一样，专注测试虽然是从个人做起，但是它的好处却可以影响到整个组织。
还有一个进步就是我们的工具和环境变得越来越好。在．NET下，测试代码变得非常容易，这也就意味着更多人将参与测试。另外，抽象层正在逐渐上移，所以我们不再需要在计算机上处理所有的事情。例如，如果你需要调用一个Web服务，你不需要手动打开一个端口，编写TCP／IP包，调用网络驱动程序，等待数据返回，然后解析返回数据。这一切现在只要一个方法调用就可以完成。这种更好的抽象层让我们可以把时间花在软件项目中更重要的部分：真正的需求和帮助用户解决问题。
在软件开发真正成为工程领域之前，我们还有很长的路要走，但是这些信号都是很令人鼓舞的。我觉得，当我们最终开始把测试当做是一门专业的时候(把它看得和开发一样，甚至更重要的)，就又会发生巨大的变革。尽管在我退休之前大概是看不到软件工程的这一转变了，不过我对现在的发展十分有信心。让我们一起学习，努力推动，这样总有一天我们可以自称是真正的工程师。
本书是把软件纳入工程领域里重要的一步。书店里关于编程的书最多的是两种，一种是泛泛而谈的软件管理类，另一种是面面俱到的技术揭秘类，对于后一种，我总是不太喜欢。当然这种书有它们的用处，有时候也很有帮助，但是我们缺乏的是专门讨论真实世界里团队软件开发的书籍。这种技术在项目中所占的比重很小，但是它对软件项目的发布是最大的挑战。本书在管理书籍和技术书籍之间做到了出色的平衡。从如何进行软件建模，到安全性设计，再到防御性编程，Donis和John向你展示了可以改进开发工作的各种最佳实践。阅读本书就像是在一位顶极的开发经理的带领下体验一个出色的项目，就像是和出色的同事一起工作。
这本书写得非常出彩，我特别喜欢它重点强调的计划和准备工作。我公司(Wintellect)曾经为很多项目救火，大多都是由于它们最初糟糕的计划所导致的后果。／细细研读这些章节，你就可以避免那些可能浪费你大量金钱和时间的错误。这本书指出的另一个问题是把性能调节和安全性分析留到项目的最后阶段。正如书中第4章的标题所指出的，“性能也是功能”。在那些章节中，箴言的价值都是无可估量的。最后，书里还强调了即使代码已经进入了维护阶段，还是能从先前的编码和调试中获取益处。即使像我这样在这个领域里耕耘了将近20年的人，还是从这本书里学到了很多好的方法。
不仅每个程序员都应该读一读这本书，而且公司里的其他人也可以读一读。向你的经理，经理的经理，甚至经理的经理的经理推荐这本书吧!不管是什么公司，我经常会被管理高层问到的一个问题就是：“微软是怎么开发软件的?”在这本书里，大多数章节中都有一个微软内幕小节，让你的老板看看就可以知道微软是如何解决那些当今最大型的应用程序中的问题的。开始阅读吧!现在轮到你来帮助我们的行业向真正的工程标准迈进了。
John Robbins
Wintellect联合创始人
媒体评论回到顶部↑
《完美代码》在管理书籍和技术书籍之间做到了出色的平衡。从如何进行软件建模，到安全性设计，再到防御性编程，本书展示了可以改进开发工作的各种最佳实践。
——Wintellect联合创始人，John Robbins
《完美代码》不仅仅是一本关于代码的书，它阐述了如何开发一个健壮的项目。这本书简单明了地介绍了软件开发中的最佳实践，并提供了很多实际产品中的案例和经验教训，帮助读者构建完美的项目——从设计到开发，以及最后的发布和维护。
——微软，软件开发工程师，Jason Blankman
作为一名有20年经验的软件工程师，能让我每过几年就重读一遍的书并不多见，而《完美代码》就是其中之一，每次温故都能知新。
——微软，软件开发工程师，Don Reamey
对任何专业软件工程师来说，《完美代码》的价值都是无法衡量的，书中到处都是可以立刻投入使用的实践经验。《完美代码》绝对是一本让你爱不释手的必读书籍。
——AJISoftware执行股东，微软区域总裁，John Alexander
《完美代码》对任何IT从业人员来说都是必读书籍，特别是如果你打算使用托管代码的话。它不仅涵盖了工程上的最佳实践，还通过已经过实践检验的案例来展示它们。
——微软，发布经理，Andres Juarez
这本书提供了在高效软件开发过程中的最佳实践，因此可以避免很多典型的程序员错误。作者提供了可实践的检测错误的方案，并解释了微软是如何进行软件开发和测试的。
——微软，测试经理，Venkat B．Iyer
无论你是新手还是专家，任何级别的程序员都可以阅读本书。它为优秀的开发实践提供了坚实的基础，不管开发团队的规模是大还是小，甚至只有一名程序员，也应该采用书中的经验。
——独立软件工程师，John Macnight
——Wintellect联合创始人，John Robbins
《完美代码》不仅仅是一本关于代码的书，它阐述了如何开发一个健壮的项目。这本书简单明了地介绍了软件开发中的最佳实践，并提供了很多实际产品中的案例和经验教训，帮助读者构建完美的项目——从设计到开发，以及最后的发布和维护。
——微软，软件开发工程师，Jason Blankman
作为一名有20年经验的软件工程师，能让我每过几年就重读一遍的书并不多见，而《完美代码》就是其中之一，每次温故都能知新。
——微软，软件开发工程师，Don Reamey
对任何专业软件工程师来说，《完美代码》的价值都是无法衡量的，书中到处都是可以立刻投入使用的实践经验。《完美代码》绝对是一本让你爱不释手的必读书籍。
——AJISoftware执行股东，微软区域总裁，John Alexander
《完美代码》对任何IT从业人员来说都是必读书籍，特别是如果你打算使用托管代码的话。它不仅涵盖了工程上的最佳实践，还通过已经过实践检验的案例来展示它们。
——微软，发布经理，Andres Juarez
这本书提供了在高效软件开发过程中的最佳实践，因此可以避免很多典型的程序员错误。作者提供了可实践的检测错误的方案，并解释了微软是如何进行软件开发和测试的。
——微软，测试经理，Venkat B．Iyer
无论你是新手还是专家，任何级别的程序员都可以阅读本书。它为优秀的开发实践提供了坚实的基础，不管开发团队的规模是大还是小，甚至只有一名程序员，也应该采用书中的经验。
——独立软件工程师，John Macnight
)
加载中...
