书籍介绍
本书总共有49个栏目，以一位微软内部人士的视角，揭示了关于软件编码、软件测试和项目管理的残酷现实。作者文笔犀利，见解独到，对软件行业内的很多常见问题提出了解决方案，并提供了最佳实践。通过阅读本书，你将了解到：怎样提高软件的质量和价值；怎样切合实际地管理项目的时间表、风险和规范书；怎样为常见的低效率开发瘦身；怎样应用过程改进方法，避免固执盲从；怎样驱动一个成功的、令你自己满意的职业生涯；以及怎样发展并管理一个欣欣向荣的团队。.
本书提出的观点，是作者对过去在软件行业6个不同的公司、28年的工作经验的一次总结。本书不仅是微软内部员工的必读之书，它也同样适合于软件行业内其他所有的工程师和管理者阅读。
AI导读
核心看点
- 微软内部视角揭示编码测试管理残酷现实
- 49个栏目提供软件工程最佳实践与解决方案
- 作者28年经验总结，涵盖团队管理与职业发展
适合谁读
- 软件工程师及项目经理，寻求提升开发效率
- IT行业管理者，希望优化团队流程与沟通
- 对微软内部开发文化及工程实践感兴趣的读者
读前提醒
- 文章集形式较散，建议分散阅读并整理心得
- 部分术语翻译生硬，可结合英文原版理解
- 微软大厂语境与小团队不同，需辩证吸收
读者共识
- 见解犀利独到，贴近一线开发真实痛点
- 相比《代码大全》更侧重管理与工程实践
- 翻译质量一般，但核心观点极具参考价值
本导读基于书籍简介、目录、原文摘录、短评和书评生成，不等同于全文精读。
精彩摘录
- "分诊的五条黄金法则："
- "任何大型组织都会有成为自身文化牺牲品的危险。关于业务模式及行为准则的神话想当然地成为金科玉律。任何组织都会存在这种倾向，但对于需要不断创新才能兴旺的技术公司来说，这却是致命杀手"
- "。所以人们常常认为某一层次的高效方法应该应用到其他层次上，悲剧就这样产生了。准则就是：小型、紧凑的团队跟大型松散的组织动作方式不同，应相应地选择适合你的方法。."
- "。不光只是开发时间表，不要相信依赖方所说的任何事情。如果他们坐在隔壁房间，他们告诉你外面正在下雨，你首先要做的是到自己的窗口去看一下。"
- "如果你坚持让开发人员遵从“功能交付日期”，那他们为了准时交付可能会撒谎。他们会隐瞒自己的工作状态，会在质量和完成度上给你虚假信息。"
- "因为，如果他们随大流，他们就不用承担什么责任，这些懦夫也不会因为项目失败负多大责任。"
- "真正的问题不是任务估算，真正的问题是接受这份估算"
- "规矩的目的是想减少风险"
用户评论
开发人员能遇到的所有事情，另外，我很喜欢他的写作风格
很棒的一本书，介绍了微软内部的最佳实践。尤其是成为“优秀管理者”的两个基本要素，很简单，很实用，这么多年来一直鼓舞着我！
本来这应该是很轻松的书，关于项目，开发，和工程，但是由于翻译不能表现出那种轻松调侃的语气，读来有些不畅快。而且是来自微软，一个庞大而且规范的场合，与我们的小作坊语境不同。
有点意思
匆匆翻阅，木有《代码大全》那样爽。大概是因为还是学生，没有真正接触项目，所以无法产生共鸣。
本书由一篇篇独立文章构成，虽然书籍组织时已给这些文章归了类，但整体上还是比较散，阅读时虽然能不停的感觉到新启示，但读完后却没几个想法能自然的回忆起。这可能和阅读方法有关。这种文章集不大适合一口气一气呵成的读，分散开，单篇单篇的阅读和整理心得，可能会好些。回头抽几篇单篇细读下试试。
Make it simple, make complex possible
作者见解独到，读后还是很有收获的。“重写的代码实际上将比当前的丑陋代码带来更多的Bug。因为当前的丑陋代码是在第一次编写的基础上，经过了几个月甚至是几年的测试和修复之后才达到的质量水准”，这一段很有体会啊。
有时候重写是必要的。重写可以提高代码的性能、扩展性、可靠性、安全性、或者对于新技术的适应能力。在这些情况下，应该把重写当作一个功能来对待；像处理其他功能一样，写一份规范书，然后为它制定时间表。“否则，不要做代码重写这种愚蠢的事情，它只会重新引入一大堆令人讨厌的Bug，而且还对客户价值没有丝毫的贡献。” 规范书检查清单。维持一个在线的知识仓库。如何成为一个优秀管理者--我服务于人，避免团队成员之间的比较。不要给他们任何理由去进行相互竞争。
收藏