下面是我作为一名程序猿经过10几年时间总结出的一些有关于软件开发的经验规则：
开发
1.从小事做起，然后再扩展
不管是创建一个新的系统，还是加入功能到现有的系统中，我总是从一个简单到差点儿没有不论什么所需功能的版本号启动，然后再一步一步地解决这个问题，直到惬意为止。我从来没有妄想过可以一步登天。相反，我一边开发一边学习，同一时候新掌握的信息还可以用于解决方式中。
我非常喜欢John Gall的这句话：“复杂系统总是源于简单系统的演化。”
2.一次仅仅改变一件事
当我们在开发时。碰到測试失败和功能无效的情况，假设你一次仅仅研究一个问题，那将会更easy找到问题的关键。换言之，就是使用短迭代。必须确保这个问题解决之后。再转移到还有一个问题上。
这适用于向下提交。
假设在你加入新功能之前须要先重构代码。那么先提交重构。然后再加入新的功能。
3.尽早地加入日志记录和错误处理
在开发新系统时，我做的第一件事就是加入日志和错误处理，由于这两者从一開始就很实用。假设系统不能照常工作。那么你就须要知道程序中发生了什么——这是日志的作用。错误处理也是如此——错误和异常越早处理越好。
4.每一行新代码必须至少运行一次
在你真正完毕一个功能之前。你必须对它进行測试。不然，你怎么知道它是不是依照你的想法在运行呢？通常情况下，最好的方法是通过自己主动測试。但并不是总是如此。只是。无论怎么说，每一行新代码必须至少运行一次。
5.在总体測试之前先进行模块測试
先进行部分模块測试可以节省时间。
通常说来，我们在整合不同的模块时也会出现故障。比如模块之间的接口不匹配。可是假设我们可以信任各个组件的话，那么跟踪集成问题就会变得简单得多。
6.全部事情所花费的时间总是比你预期的要长
特别是在编程中，即使一切进展顺利，我们也非常难对功能所需的时间做出正确的预算。
而且。开发软件时碰到各种意想不到的问题是非经常见的。
侯世达定律事实上道出了真谛：做事所花费的时间总是比你预期的要长，即使你在预期中已经考虑了侯世达定律。
7.先了解现有的代码
大多数的编码都须要以某种方式改变现有的代码。即使是新功能，也须要适应现有的程序。
所以。在你加进去新的内容前，首先须要了解当前的解决方式。否则。你一不小心就非常有可能会打破现有的功能。这意味着。阅读代码和编写代码都是必要的技能。这也是为什么看似微小的变化仍可能须要非常长时间才干解决的原因之中的一个——你首先必须了解上下文。
8.阅读和执行
幸运的是，对于理解代码，我们有两种互补的方法。
你能够阅读代码，也能够执行代码。执行代码的确是个很棒的好方法。
所以，请确保充分利用这两种方法。
故障排除
9.bug总是难免的
我不喜欢那些宣称软件开发能够“一蹴而就”的高谈阔论。不论你再怎么费尽心机，bug总是难免的。最好能够做成能够高速故障排除、修复bug和部署修复的系统。
10.解决故障报告
每一个开发者都应该花时间去处理来自客户的故障报告，并修复bug。这能让你更好地理解客户的意图，明确怎样使用系统，知道排除故障的难易程度，了解系统的设计情况。这也是为自己的开发成果负责的好方法。
11.重现问题
修复bug的第一步就是重现问题。然后你得确保修复之后，问题可以彻彻底底地消失。
这样一个简单的规则可以确保你不会误将非问题当作是问题，并确保解决方式真的可以奏效。
12.修复已知错误，然后再看看有没有遗漏的地方
有时候，可能同一时候存在着几个不同的问题。它们之间的互相作用。可能会让你毫无头绪，束手无策。不要纠结于搞清楚发生了什么，先去解决全部已知的问题，然后再看看还有什么不正确的地方。
13.没有巧合
在測试和故障排除时。不要相信会出现什么巧合。就像你改变了定时器的值。那么就会改变系统重新启动的频率。所以一切都并不是是巧合。
加入新功能，还有一个不相干的功能变慢了？这绝对不是巧合。
相反，是你应该细致调查的内容。
14.关联时间戳
在故障排除时，事件的时间戳能够作为你的好帮手。寻找偶数增量。比如，假设系统重新启动了，而且刚刚发出过一个3000毫秒左右的请求。那么可能是触发了某个定时器，才导致出现重新启动的动作。
团队合作
15.面对面的交流最有效
当我们须要讨论怎样解决这个问题时，那么面对面的交流比视频、打电话和电子邮件都要好。
16.橡皮鸭法
遇到你绞尽脑汁也解决不了的问题时，最好还是找一个同事，然后将问题解释给他们听。
非常多时候，当你在叙述时，即使你的同事一言不发，你可能也会突然灵光乍现找到问题的关键。
17.问问题
阅读和执行代码往往很有助于指出代码的目的和它的工作原理。可是假设你有机会咨询那些更为了解的人（比如原来的程序猿）。那么千万不要错过。
18.共享荣誉
不要贪图荣誉，该是谁的就是谁的。比如：“Marcus想出了这个主意……”（假设真是他想的话）。而不要说“我们想出的……”。
其它
19.尝试
假设你不知道某种编程语言功能的工作原理。那么最好还是写一个小程序来理解它是怎样工作的。
这相同适用于測试你正在开发的系统。假设我将參数设置为-1，会发生什么？当我在重新启动系统时，假设服务当掉，会发生什么？以此来研究它的工作原理。
20.带着问题睡觉
假设你正在解决一个非常难的问题，那么最好还是带着问题睡觉。
有科学研究表明。这样做尽管你表明上并没有在主动思考，但你的潜意思却这么做了。其结果就是，第二天再去研究问题，解决方式已经呼之欲出了。
21.跳槽
不要害怕跳槽。和不同的人共事。开发不同的产品，感受不同的公司文化是很有意思的。
22.不断学习
我们须要不断地学习和了解软件开发。你能够尝试不同的编程语言和工具，阅读软件开发的书籍，接受MOOC课程。相信我，量变才干达到质的飞跃，这些小小的学习积累。终有一天会大大地提高你的知识和能力。
希望这些经验能对大家实用。如有不当之处，敬请指正。