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