程序员应该知道的97件事-读书笔记

1. 谨慎行动
1. 技术债务就像一笔贷款。在短时间内，你能从中获得好处，可是，在清偿以前，你要付出利息。代码里的捷径使得新功能更难于加入，也会影响到代码重构。它们是软件缺陷和失败测试用例的滋生地，听任它们的时间越长，状况就会越糟糕。
2. 每每是状况不可收拾时，你才不得不对它们进行修正，而那时你已没有足够的时间，也承担不起由此带来的风险
3. 必须时刻追踪技术债务，尽快的或者当状况急剧恶化的时候，当即将其偿还。每当你无可奈何欠下了技术债务，就要当即记录到人物卡上或者等级到问题追踪系统里，以保证其不会被遗忘
2. 函数式编程原则的应用
1. 函数式编程能极大地提升你的代码质量
2. 引用透明性：函数无论在什么时候何地被调用，都保持一致的行为，一样的输入获得一样的输出结果
3. 试问本身“用户会怎么作”（你不能算是用户）
1. 咱们都爱假设别人的心思跟咱们同样，但事实上不是这回事。心理学上把这种心理状态叫作虚假同感误差(false consensus bias)。当人们的想法和行为跟咱们不一样时，咱们极可能会（在潜意识里）将他们归位“能力低下”的人
2. 用户卡住的时候，他们会缩小他们的注意力范围，因而更难以看到在屏幕其余区域上显示的解决方法。由于用户注意力范围缩小，使用tool tip的效果赛过点击帮助菜单
3. 用户都倾向于能用就好。他们一旦找到一种可用的方法，就会一直用下去，无论它有多么费劲。所以，提供一条显而易见的操做途径，要好过提供两三条捷径
4. 编码标准的自动化
1. 编码标准应该是动态的，不是一成不变的。随着项目的进展，项目需求的改变，一些在刚开始时显得灵活的标准可能在几个月后会变得不够灵活
5. 美在于简单
1. 风格之美、和谐、优雅及优美的节奏尽在于简单——柏拉图
2. 优美的代码有许多共同的属性，首要的一点就是简单。一个应用或一个系统不管有多么复杂，其中每一个单独的组成部门都保持着它的间接性。
3. 不管通过多少时间，干净、简单、可测试的代码保证了系统的可维护性，也确保了系统在整个生命周期里能快速开发升级
4. 美来自于简单，亦存在于简单
6. 在你重构以前
1. 重构代码的最佳起点就是清理已有的基础代码和基于这些代码写的测试
1. 咱们都以为本身能够比原有系统作得更好，这是由于咱们没有向原有系统中的错误学习
2. 避开重写一切的诱惑
1. 尽量多的重用代码是最好的选择，不管代码是多么的丑陋，毕竟它已经被测试过了，也被审查过了
2. 抛弃旧代码——尤为是存在于产品中的代码——也意味着抛弃了经年累月测试并实战过的代码，以及你还未知晓的周边代码和bug补丁。这会浪费大量的时间、精力和多年积累下来的知识
3. 逐步增长的小改动赛过一次性的大改动
4. 在每次迭代以后，要确保已有的测试用户都已经过
1. 假如已有的测试用例还没能覆盖到你所作的修改部分，那就增长新的测试用例
5. 我的好恶和利己主义不能参杂到开发中来
1. 若是代码的风格或结构不符合你的我的喜爱，你也不能把这看成代码重构的正当理由。即便你以为本身能够比上一个程序员作得更好，也不能将它做为重构的理由。
6. 新技术不是重构的充分理由
1. 关于重构的最差劲的理由之一就是当前代码跟咱们目前拥有的很酷的技术相比已经远远落后了，咱们相信用新的语言或框架来完成这些功能会更加优雅。
2. 除非成本效益分析结果代表这种新的语言或框架能在功能性、可维护性或生产力上会有显著的提高，不然，最好仍是弃之不用
7. 要记住人老是会犯错误的
1. 重构不能一直保证新代码会超过——或至关于——原先的代码
7. 谨防共享
1. 建立共享的代码库以前，应该仔细检查上下文环境
8. 童子军规则
1. 若各团队能把系统当成一个总体来维护，再也不“各人自扫门前雪”，咱们将看到软件系统里无可挽回的退化局面会终结，并且会逐渐变得更好
2. 把代码搞得一团糟的行为也应该像社会上乱丢垃圾行为同样不受待见，由于是该作的却没有作到的行为
3. 团队要相互帮助，相互清理代码，这对每个人都有好处，而不只仅是他们本身
9. 在责备别人以前先检查本身的代码
1. 假如使用的工具是一个被普遍使用的、成熟的，不一样技术领域都在用的产品，那就几乎没有理由去怀疑它的品质
2. 若是其余人报告说有问题，而你却没法重现时，那就走过去看看他们究竟是怎么操做的
10. 谨慎选择你的工具
1. 如今的应用程序不多从零开始构建的
2. 从小范围开始，只采用相对必需的工具
11. 领域语言里的代码
12. 代码就是设计
1. 大幅削减建形成本，致使的结果倒是质量恶化
2. 软件设计只有经过了一系列严格的测试验证以后才能算完成
3. 咱们的但愿在于改良的程序设计语言及设计的最佳实践
4. 伟大的设计是由伟大的设计者做出的，他们穷尽一辈子精通了该门技艺
13. 关于代码布局的麻烦事
1. 易于检索
2. 清晰的布局
3. 紧凑格式
14. 代码审查
1. 代码审查能提供改吗质量，下降差错率。一个组织很须要这样一个硬性的、正式的过程
2. 代码审查的目的不只仅是简单的更正代码错误，其目的应该是共享知识、创建统一的编码指导标准
3. 代码审查的时候态度要温和，确保评语是有建设性的，不是刻薄的
4. 在代码审查会议上，对代码格式应该不作评论
5. 主要着眼于在团队成员之间分享知识，抛开讽刺性的评语
15. 编写代码的理由
1. 避免使用可更改的全局变量，由于这会让全部使用它们的代码段产生依赖
16. 对注释的一个注释
17. 代码说不清，注释来补充
1. 没法给代码增长价值的注释就是噪音。那些只会 模仿代码的注释没法给读者提供更多的信息
2. 应该像对待代码同样对待注释。每一段注释应该为读者注入一些价值，不然纯粹就是浪费，还不如删除，或者干脆重写
18. 不断学习
1. 你须要为你本身的教育负起责任
2. 尽可能为本身找到一个导师。若是本身就是最厉害的家伙，那会阻碍你的修习之路。虽然你能够从其余人身上学到点什么，可是，在那些更聪明、经验更丰富的人身上，你能学到更多。若是找不到导师，就换一个地方
3. 每一年学习一门新的语言，至少要学用一门新的技术或工具。这能够帮助你拓宽新思路，充实你当前的技术储备
19. 易用不是一种能力
1. 好的API要遵循一致的抽象层次，并展示出它的一致性和对称性，最终组成一份表达充分的词汇表。
2. API应该提供一种表达充分的语言，给予上层一份丰富的词汇表，让它能据此请求和回复那些有用的问题
3. 易用而且通过深思熟虑的API词汇表能够致使上层使用富有表现力的、易于理解的代码
20. 早部署，常部署
1. 发布工程师(Release Engineer)
2. 按期在一个干净的环境中运行和测试安装过程，可让你检查出代码中那些基于开发或测试环境所作的假定是否合理
3. 把部署放到最后意味着那些围绕着部署假定的代码会变得更加复杂
4. 全部权衡事项宜早不宜迟
21. 区分业务异常和技术异常
1. 因为领域逻辑的缘由没法完成调用而产生的业务异常，是契约的一部分，抛出异常只是按原路径返回错误的一种替代方式，客户端应该知道而且随时准备处理它
22. 有针对性的勤加练习
1. 有针对性的勤加练习就是经过执行一项任务来提升自身的能力，关乎技巧和技术
2. 作有针对性的练习就是为了精通这项任务，并非完成任务
3. 有偿开发的首要目标是完成一个产品，而有针对性的练习的首要目标是提升你的水平。二者是不同的
4. 精英执行者也至少须要10000个小时的有针对性的联系才能成为专家
5. 伟大在很大程度上就是有意识选择的结果
6. 达到专家水平的主要因素就是花时间去作带有针对性的练习
7. 有针对性的练习意味着多练习你不擅长的东西
8. 学习改变你的东西，学习改变你行为的东西。祝你好运！
23. 领域特定语言
24. 不要怕搞砸
1. 熟练的外科医生都知道为了手术必需要开几道切口，可是，她也知道这切口都是临时的，会愈合的
2. 对于改变的麻痹式恐惧在开始时就会让你的项目陷入到这种投鼠忌器的状态
3. 做为一个外科医生，为了给痊愈腾出空间，她一点都不惧怕切除坏死组织
25. 不要在你的测试代码里装可爱
1. 在你的代码里写入文本的时候，不管是注释、日志、对话框或者测试数据，都要问一下本身若是这些公开出去的话会怎么样。这样会让你少脸红几回
26. 不要忽略那个错误
1. 不顾红灯亮起，继续前行，结果只会招致更大的损失。要在时机初现的时候就动手，把损失较少到最小
27. 不要只学习语言，还要了解它的文化内涵
28. 不要把程序钉死在老地方
29. 不要期望“魔法会在此发生”
1. 没有开发经验的经理会认为程序员作的事情很简单，而没有管理经验的程序员也认为经理所作的事情很简单
30. 不要重复你本身
1. 应用里的每一行代码都会被维护到，它们就是将来bug的潜在来源
2. DRY的要求是“在一个系统内，每一块知识必须有一个单一的、明确的、权威的表示”
3. 将重复的过程调用自动化
4. 凡有痛苦的手工过程存在的地方，均可以使用自动化，手工过程原本就应该被自动化和标准化
31. 别碰那些代码！
1. 开发人员——甚至是高级开发人员的访问权限都应该不能超越开发服务器
2. 如同开发人员不须要访问开发服务器以外的任何服务器同样，QA团队和用户也不须要接触开发服务器上的任何东西
3. 发布经理是惟一能访问这两台服务器的人
4. 不管在哪一种状况下——从根本上说，就是永远不要让开发人员有访问产品服务器的权限
5. 若是代码有问题，产品服务器不是修复它的地方
32. 封装行为，而不只仅是状态
33. 浮点数不是真正的数
1. 浮点数的精度是有限的，是能够穷尽的。甚至在分布范围内的间隔也不是均匀的
34. 开源助你实现雄心壮志
1. 经过给别人的软件编写测试代码，能让你学得更快，超过软件开发里其余任何一个活动
35. API设计的黄金法则
1. 锁定API：能够试着把绝大多数的类和方法都表上final，以此来阻止用户的重载或代码的滥用，避免将来你在更改选择时受到约束
2. 单元测试是实践中极端重要的一部分
3. API设计的黄金法则：只为你开发的API编写测试代码是不够的，你还必须给使用API的代码编写单元测试
36. 高手神话
1. 若是某人看上去像是个高手，那是由于他拥有多年的学习和思惟精炼过程的积累。“高手”往简单上讲就是一个有着无穷好奇心的聪明人
2. 咱们不须要高手，咱们须要能帮助其余人在他们领域里成为专家的专家
37. 加班加点，事倍功半
38. 如何使用bug跟踪器
1. 一个好的bug报告须要具有三样东西：
1. 若是重现该bug，尽量准确的描述，间隔多久后bug会再出现一次
2. 本应该发生什么，至少按你本身的看法来讲
3. 实际上发生了什么，或者至少是你记录到的尽量多的信息
2. bug不是工做的标准单元，不能像一行行代码那样精确地衡量着你的努力。（其实代码行也只是粗略衡量）
39. 代码的去芜存菁
1. 经过删除基础代码中那些使人不快的功能特性，下降了全局代码熵的水平
2. 编写代码是由于他们增长价值，而不是取悦你本身
3. 若是你如今不须要，那如今就不要写
4. 额外代码的编写和维护老是会花更长的时间。一团小小的额外代码“雪球”随着时间的推移会变成一项庞大的须要维护工做
5. 程序员发明了额外的需求，既不记录在文档里，也没通过讨论确认这个额外功能特性。这需求实际上就是捏造出来的。
6. 系统需求不是程序员设定的，而是客户要作的
40. 安装我吧
1. 记住，客户也下载了竞争对手的框架。你知道的，竞争对手老是在论坛里宣称他们的框架比你的好不少
41. 进程间通讯对应用程序响应的影响
1. 许多性能管理著做仍然执着于数据结构和算法，这些因素在某些状况下是会起一些做用，可是在现代多层企业应用中并不处于主导地位
2. 响应时间极大地依赖于对刺激做出响应的远程进程间通讯的数量。
3. 用于响应刺激的远程IPC数目越多，响应时间就会越大。如何减小？
1. 吝啬原则，优化进程间的接口，只为互动过程准备最小数量的正确的数据
2. 在可能的状况下，并行执行进程间通讯，这样总的响应时间会主要取决于时延最长的IPC
3. 缓存前次IPC的结果，未来的IPC就可能不用再执行，直接用命中的本地缓存来代替
42. 保持构建的整洁
1. 忽略事情也是脑力劳动
2. 来自于构建的警告是有用的。你要在开始注意到它们的时候就着手清除，不要等到最后“大扫除”的时候再去作
3. 让构建保持干净，不仅是消灭编译错误或者测试失败：警告信息也是“代码卫生”里重要且关键的一部分
43. 知道如何使用命令行工具
1. 设计良好的IDE不过就是一套命令行工具的图形化前端
44. 通晓两门以上编程语言
1. 一个程序员的编程技巧跟他能驾轻就熟处置的不一样编程范例数目直接相关
2. 只懂得一种语言的程序员会被那种语言禁锢住她的思想
3. 编程范式：过程式、面向对象、函数式、逻辑型、数据流……
4. 每一个程序员最好能在两种不一样的范式下有熟练的编程技能，理想一点就是掌握五种编程范式
5. 程序员应该对学习新语言始终保持着兴趣，特别是对于不熟悉的范式
45. 了解你的IDE
46. 了解你的局限性
1. 你的资源是有限的。你只有这么点时间、这点钱去作你的事情，包括还要花钱花时间让你的知识、技能和工具跟上时代。因此，你的工做要如此投入、如此快速、如此灵活、如此持久。你的工具也就这点威力，你的目标机器也就这点功率。所以，你不得不考虑一下你有限的资源
2. 对于小数组，线性查找颇有竞争力
47. 知道你下次提交的内容
1. 代码要在头脑里有着清晰的意图和有限且可达的目标
2. 知道你下次所要提交的东西。若是你没法完成，就丢弃掉更改，而后按照你已有的理解，定义出一项你确信能完成的新任务。只要有须要也要作一些投机试验，可是不要在无心之中陷入到投机模式中。
3. 千万不要把猜测获得的东西放入代码库里。
48. 大型、相关性的数据属于数据库
49. 学习外语
1. 付出总会有回报，时机迟早会来
2. 在今天，跟简单的编程实用工艺相比，大型项目更像是社会性的事业
3. 懂另一门语言，就是拥有了另外一个灵魂
4. 要懂得何时倾听，而不是交谈，要知道多数语言是没有文字的
5. 对于不可言说的，必须保持沉默——Ludwig Wittgenstein
50. 要学会估算
1. 估算就是对价值、数值、质量及其扩展项目做出近似的计算和判断。估算是基于实际数据和以往经验的实际衡量——在计算的时候不能让但愿和愿望掺杂进来。估算是一个近似值，估算是不可能精确地
2. 目标是对所要达到的商业目标的陈述
3. 承诺就是答应在某个日期或者某个事件发生之时，提交否和某个质量水平的指定功能
4. 估算、目标和承诺三者是相互独立的，可是，目标和承诺要基于合理的估算。
5. 软件估算的首要用途不是为了预测一个项目的产出成果，而是为了测定一个项目的目标是否足够现实，从而使项目处于控制之下实现这些目标。
6. 估算的用途是为了让适当的项目管理和计划成为可能，容许项目的各利益相关方基于现实目标做出承诺
51. 学着说“Hello, World”
52. 让你的项目能表达它本身
53. 连接器并不神秘
1. 要想知道可执行文件为何是这个大小，能够看一下连接器选择生成的map文件。map文件就是一张包含了可执行文件里全部符号及它们地址的列表。它告诉你库里的哪些模块连接进来了，以及每一个模块的大小。由此你就能看出可执行文件体积膨胀是从哪里发源的
54. 临时解决方案的寿命
1. 当系统里容纳了太多临时解决方案的时候，它的熵或者或内部复杂度会随之增长，而它的可维护性却在下降
2. 征服临时解决方案的最佳途径是让它们变得多余，提供一个更优雅、更有用的解决方案
55. 使接口易于正确使用，难于错误使用
1. 好的接口是易于正确使用，难以错误使用
2. 易用的接口看上去很天然，由于它们让你作你想作的事情
3. 要记住接口的存在是为了方便使用者，而不是实现者
56. 让不可见的更加显眼
1. 修复bug不能算是有进展。调试就是一种浪费。只有让浪费的时间暴露在关注之下，这样你才会认识到什么致使了时间的浪费，并开始检讨当初应该细心一点
2. 若是你的项目还处于可跟踪的状态之下，但仅仅一个星期以后，你却发现进度上已经延迟六个月了，这时你碰到问题了——最大的问题可能不是它长达六个月的延迟，而是有股隐形的力量已经强大到掩盖了项目延迟六个月这个事实
3. 单元测试的编写提供了该代码单元便于作单元测试的证据。它有助于揭示代码存在（或不存在）你但愿它能表现出的品质，例如低耦合和高内聚
4. 单元测试的运行提供了该代码行为的证据。它有助于揭示代码拥有（或不拥有）你所但愿的它在运行时能表现出的品质，例如健壮性和正确性
5. 可见性能让人充满信心，让人以为进展是真实的，而不是虚幻的，是有备而来的，而不是凭空想象的，是能够重复的，而不是偶尔为之的
57. 在并行系统中使用消息传递可得到更好的伸缩性
1. 人们一次次碰到的并发问题几乎都跟易变的共享内存有关系
2. 要么放弃并发，要么放弃共享内存
3. 数据流系统：在一个数据流系统里，没有明确的编程控制流，只有一系列有向图的算子，用数据路径相链接。创建起关系后，再把数据“灌”入系统
4. 要想充分驾驭计算机硬件内建的并行能力，使用消息传递是一条比共享内存编程更为成功的路径
58. 带给将来的消息
1. 每一行代码都是带给将来某我的的消息
59. 错失采用多态的机会
60. 奇闻轶事：测试人员是你的朋友
61. 二进制文件仅此一份
62. 有代码有真相
63. 拥有（及重构）构建脚本
1. 构建脚本也是代码。它们如此重要以致于你最好本身亲自来作
64. 结对编程，感觉流程
1. 在任务轮转到另外一个结对以前，你没必要非把它结束掉不可
2. 有告终对编程、合适的结对及任务的轮转方式，新来者会很快认识代码和其余团队成员
65. 特定领域类型赛过原始类型
1. 使用静态类型语言的话，可以从编译器那里获得一些帮助，而那些拥抱动态类型语言的人会更倾向于依赖他们的单元测试
66. 预防错误
1. 应该尊重用户的偏好来输入信息，而不是数据自己
2. 为全部动做提供不一样层次的撤消操做——尤为是那些可能会破坏和修改用户数据的操做
3. 用日志记录撤销动做，而且加以分析，凸显出界面的哪部分会诱导用户犯下无心识的错误
67. 专业程序员
1. 在专业程序员身上惟一最重要的一点就是我的责任感。专业程序员对他们的职业、估算、承诺的日程、错误和技艺都勇于负起责任，从不会把责任推卸到别人身上
2. 若是你是一名专家，你就要对本身的职业负责，对阅读和学习负责。你负责跟上这个行业和技术的发展。不少程序员都认为这应该由雇主来给他们培训。对不起，这错得离谱
3. 对于多数项目而言，问题跟踪系统的存在就是粗枝大叶的征兆。只有巨无霸型的系统才有bug列表，bug数量才会大到须要自动化管理
4. 专家是能够信赖的。他们对本身的职业负责，对代码的正常工做负责，对他们技艺的质量负责。即使是最后期限迫近，他们也不会放弃原则。事实上，随着压力增大，专家会更加有条不紊，他们认为这是正确的
68. 把一切都置于版本控制之下
1. 许多项目都有一个活跃的开发分支，以及一个或多个为当前正在支持的已发布版本所建立的维护分支
69. 放下鼠标，远离键盘
70. 阅读代码
71. 读懂人性
1. 相互理解的能力不是来自于共享的定义，而来自于共同的经验和生活方式
72. 常常从新发明轮子
1. 若是对软件开发中更深层次的东西一无所知，你就没有足够的能力创造出永恒之做
2. 从新发明轮子对于一个开发人员的教育和技能培养来讲很重要，就像健美运动员练举重同样
73. 抗拒单件模式的诱惑
1. 单件是值得抗拒的：
1. 单一实例的需求一般都是想象出来的。在许多状况下，它都是纯粹的投机，认为未来也不要更多的实例。在一个应用的设计里传播这种投机性，势必致使在某些时候会很痛苦。由于好的设计会拥抱需求的变化，而单件不会
2. 在概念上独立的代码单元之间，会因单件引起潜在的依赖关系。该问题的存在既由于这种关系难于察觉，又由于它们在单元之间产生了没必要要的耦合
3. 单件承载了不明显的持久状态，这会妨碍到单元测试。
4. 多线程会把更深的缺陷带给单件模式。
2. 单件的清理最后会变成挑战：
1. 对于明确的释放单件可能没有足够的支持。例如，在一个插件架构中，一个插件只有全部对象清理干净以后再卸载才是安全的
2. 没有命令用于程序退出时隐含的清理单件。
3. 必须把你对单件模式的使用限制在那些只要实例化一次的类里面。不要从任何代码那里来访问单件的全局访问点
74. 通向高性能之路布满了脏代码炸弹
1. 在咱们努力创造干净的代码过程当中，软件度量会成为一个威力强大的工具
75. 简单来自于删减
1. 挽回糟糕工做所耗费的时间会比预想的要多
2. 处置坏代码的最好方法是完全转变编程思路，坚持无情的代码重构、移动或者删除坏代码
3. 代码应该是简单的，它只有最小数量的变量、函数、声明和其余一些语言必需的句法。额外的行、额外的变量……额外的一切，应该当即清除掉。那里全部的，那里保留下来的，应该恰好足够完成任务、完成算法或者执行计算，除此以外的任何东西都是多余的。意外引入的没必要要噪音只会使得流程晦涩难懂，使得重要内容隐匿无踪
76. 单一职责原则
1. 单一职责原则：把全部会为同一个缘由而更改的东西聚集在一块儿，把全部会为不一样理由而更改的东西独立开来——优秀设计的最根本原则之一
77. 从Yes开始
1. 从yes开始实际上就是做为一名技术领导的核心内容
2. 一般，你会发现只要你知道提出要求时的背景，就会找到其余能够用来回应要求的方法
3. 若是你能表述出一个使人信服的理由来讲明为何这个功能要求跟现有产品格格不入，那么你就有可能就大家是否正在构建一个正确的产品进行一次破有建设性的沟通。不管此次沟通的结论是什么，每一个人都会更加关注这个产品是什么，以及不是什么
4. 从yes开始意味着你要和你的同事们并肩做战，而不是相互对立
78. 请转回去作自动化、自动化、自动化
79. 充分利用代码分析工具
1. 不要让测试成为质量保证的终点——充分利用现有的分析工具，也不要惧怕推出你本身的工具
80. 为必需行为测试，而不是偶发行为
1. 测试的一个常见缺点就是与实现细节焊死在一块儿，而这些细节都是偶然的，跟所要求的功能关系不大
2. 白盒测试用代码结构来决定什么是测试用例所须要的
81. 测试要严密而具体
1. 构造软件设计的方式有两个：一个是让它足够简单，没有明显的缺陷；另外一个是让它变得很是复杂，以致于看不出有什么缺陷——Tony Hoare (快速排序的发明人，1980年得到图灵奖)
82. 在睡觉的时候（或度周末的时候）进行测试
1. 将横跨不一样部门和团队的服务器组成池，确保资源可以充分利用
83. 软件开发的工程严密性来自测试
1. 测试是通向软件可再生产性和高质量的真正途径，咱们把回头争论是否要进行测试的行为视为极不专业的作法
84. 关于状态的思想
85. 一人技短，二人技长
1. 仅仅做为一名技术专家已经不够了，你还必须高效的与其余人一块儿工做
86. 错上加错就是貌似正确（而且难以纠正）
87. 我写代码为人人，人人为我写代码
1. 创造软件是技术活动和社会活动的混合
2. 咱们和每一个人一块儿分担着提升成功可能性的责任
3. 咱们不多不多会写只给本身用的代码
88. Unix工具是你的好朋友
89. 使用正确的算法和数据结构
90. 冗长的日志会让你睡不安枕
1. 太多的日志等于没有日志
91. WET掩盖了性能瓶颈
1. DRY - Don't Repeat Yourself
2. WET - Write Every Time
3. DRY能够帮助咱们找出并修复性能瓶颈，这在WET代码里是很难发现的
92. 当程序员和测试人员开始合做的时候
93. 编写代码时要像余生都要给它提供支持同样
1. 你会发现多年前编写的代码依然影响着你的职业生涯，无论你是否乐意这样。
2. 你的身后流下了一条鲜明的轨迹，其中蕴含你的知识、态度、主张、专业主义、诚意以及对于你设计编写的每个方法、类、模块的投入程度
94. 使用实例编写小函数
95. 测试为人而写
96. 你应该关心你的代码
1. 贫乏的技术基础之上不会产生好的程序员
2. 好的程序员依赖于采用专业途径，即便有现实世界的束缚和软件工厂的压力，也一直想着写出最好的软件
3. 与其余程序员一块儿和气共事。没有一个程序员是一座孤岛。几乎没有程序员是单枪匹马工做的；多数工做都是程序员抱团做战的
4. 你要但愿团队有可能写出最好的软件，而不是让你本身显得很聪明
97. 心口不一的客户
1. 不要简单的用客户的言辞来重申他们告诉你想要的是什么。在与客户谈话过程当中，要换他们的言辞，而后从他们的反应里判断
2. 在交谈中使用可视化目标有助于加大注意力的广度，提升信息的保持率