摘自：《97 Things Every Programmer Should Know》
ONE
谨慎行动
技术债务就像一笔贷款。在短期内，你能从中得到好处，但是，在清偿之前，你要付出利息。代码里的捷径使得新功能更难于加入，也会影响到代码重构。它们是软件缺陷和失败测试用例的滋生地，放任它们的时间越长，情况就会越糟糕。
往往是情况不可收拾时，你才不得不对它们进行修正，而那时你已没有足够的时间，也承担不起由此带来的风险
必须时刻追踪技术债务，尽快的或者当情况急剧恶化的时候，立即将其偿还。每当你迫不得已欠下了技术债务，就要立即记录到人物卡上或者等级到问题追踪系统里，以保证其不会被遗忘
TWO
试问自己“用户会怎么做”（你不能算是用户）
我们都爱假设别人的心思跟我们一样，但事实上不是这回事。心理学上把这种心理状态叫做虚假同感偏差(false consensus bias)。当人们的想法和行为跟我们不同时，我们很可能会（在潜意识里）将他们归位“能力低下”的人
用户卡住的时候，他们会缩小他们的注意力范围，于是更难以看到在屏幕其他区域上显示的解决方法。因为用户注意力范围缩小，使用tool tip的效果胜过点击帮助菜单
用户都倾向于能用就好。他们一旦找到一种可用的方法，就会一直用下去，不管它有多么费劲。因此，提供一条显而易见的操作途径，要好过提供两三条捷径
THREE
美在于简单
风格之美、和谐、优雅及优美的节奏尽在于简单——柏拉图
优美的代码有许多共同的属性，首要的一点就是简单。一个应用或一个系统无论有多么复杂，其中每个单独的组成部门都保持着它的间接性。
无论经过多少时间，干净、简单、可测试的代码保证了系统的可维护性，也确保了系统在整个生命周期里能快速开发升级
美来自于简单，亦存在于简单
FOUR
简单来自于删减
挽回糟糕工作所耗费的时间会比预想的要多
处置坏代码的最好方法是彻底转变编程思路，坚持无情的代码重构、移动或者删除坏代码
代码应该是简单的，它只有最小数量的变量、函数、声明和其他一些语言必需的句法。额外的行、额外的变量……额外的一切，应该立即清除掉。那里所有的，那里保留下来的，应该刚好足够完成任务、完成算法或者执行计算，除此之外的任何东西都是多余的。意外引入的不必要噪音只会使得流程晦涩难懂，使得重要内容隐匿无踪
FIVE
不断学习
你需要为你自己的教育负起责任
尽量为自己找到一个导师。如果自己就是最厉害的家伙，那会阻碍你的修习之路。虽然你可以从其他人身上学到点什么，但是，在那些更聪明、经验更丰富的人身上，你能学到更多。如果找不到导师，就换一个地方
每年学习一门新的语言，至少要学用一门新的技术或工具。这可以帮助你拓宽新思路，充实你当前的技术储备
SIX
不要怕搞砸
熟练的外科医生都知道为了手术必须要开几道切口，但是，她也知道这切口都是临时的，会愈合的
对于改变的麻痹式恐惧在开始时就会让你的项目陷入到这种投鼠忌器的状态
作为一个外科医生，为了给痊愈腾出空间，她一点都不害怕切除坏死组织
SEVEN
不要重复你自己
应用里的每一行代码都会被维护到，它们就是未来bug的潜在来源
DRY的要求是“在一个系统内，每一块知识必须有一个单一的、明确的、权威的表示”
将重复的过程调用自动化
凡是有痛苦的手工过程存在的地方，都可以使用自动化，手工过程本来就应该被自动化和标准化
EIGHT
通晓两门以上编程语言
一个程序员的编程技巧跟他能得心应手处置的不同编程范例数目直接相关
只懂得一种语言的程序员会被那种语言禁锢住他的思想
编程范式：过程式、面向对象、函数式、逻辑型、数据流……
每个程序员最好能在两种不同的范式下有熟练的编程技能，理想一点就是掌握五种编程范式
程序员应该对学习新语言始终保持着兴趣，特别是对于不熟悉的范式
NINE
要学会估算
估算就是对价值、数值、质量及其扩展项目作出近似的计算和判断。估算是基于实际数据和以往经验的实际衡量——在计算的时候不能让希望和愿望掺杂进来。估算是一个近似值，估算是不可能精确地
目标是对所要达到的商业目标的陈述
承诺就是答应在某个日期或者某个事件发生之时，提交否和某个质量水平的指定功能
估算、目标和承诺三者是相互独立的，但是，目标和承诺要基于合理的估算。
软件估算的首要用途不是为了预测一个项目的产出成果，而是为了测定一个项目的目标是否足够现实，从而使项目处于控制之下实现这些目标。
估算的用途是为了让适当的项目管理和计划成为可能，允许项目的各利益相关方基于现实目标作出承诺
TEN
你应该关心你的代码
贫乏的技术基础之上不会产生好的程序员
好的程序员依赖于采用专业途径，即使有现实世界的束缚和软件工厂的压力，也一直想着写出最好的软件
与其他程序员一起和睦共事。没有一个程序员是一座孤岛。几乎没有程序员是单枪匹马工作的；多数工作都是程序员抱团作战的
你要希望团队有可能写出最好的软件，而不是让你自己显得很聪明