数据类的问题：
1.工作如果可以手动完成，那就手动操作。你会对如何着手处理它产生一种直觉。
2.收集范例。从一个数据表开始，突出显示你现有的数据。
3.让它在一个案例中起作用，然后你才可以为所有的案例工作
4.在算法本身中构建调试输出。您应该能够转储每个步骤的中间结果，并通过文本编辑器或web浏览器手动检查它们。
5.不要使用单元测试——除非你能定义什么是正确的行为，否则它们是无用的，而当你在做这种编程的时候，你就不能这么做。
一个大型的不熟悉的代码库的维护编程:
1.看一下文件大小。最大的文件通常会包含代码的实质内容。
2.单步执行调试器的程序，从主调度循环开始。你会学到很多关于控制流的知识。
3.查找数据结构，尤其是那些作为参数传递给许多函数的数据结构。大多数程序都有一小部分关键的数据结构，找到它们并将自己定位到其他部分会变得容易得多。
4.编写单元测试。它们是确认您对理解代码实际上是如何工作的最好方法。
5.删除代码，看看能有什么破坏。(但不要坚持它!)
性能工作:
0.不要去做，除非你已经做了，而且对用户来说太慢了。对于你需要改进多少，什么时候停止要有一个性能目标。
1.在所有事儿之前(即使是性能分析!),构建一组代表典型实际应用的基准。不要让你的性能倒退，除非你很确定你被困在最难的地方，同时有一个更好的全球解决方案。(如果是这样的话，你可以在VCS中给你的分支贴上标签，这样你就可以在错误的时候撤回你的改变。.)
2.许多性能瓶颈存在于系统交集处。在任何RPC框架中收集定时统计数据，并一些方法来传播和可视化在每个服务器上进行访问请求的时间，以及请求中的哪些部分是并行的，哪些部分是关键路径。
3.轮廓.
4.通常你可以通过避免不必要的工作获得大的初始胜利。缓存您最大的计算，并延迟评估通常不需要的东西。
5.不要忽视恒定因素。有时，具有渐近差性能的算法在实践中会表现得更好，因为它有更好的缓存局部性。
你可以在被称为lot的函数中识别出它。
6.当您拥有一个flat profile，通过更改数据结构，通常仍然可以获得非常显著的收益。注意内存的使用;经常性的通过较少的缓存压力去收缩的内存需求会显著地加快了系统速度。注意位置，把常用的数据放在一起。如果你的语言允许(不是说你，Java)，消除对值的限制。
一般守则：
1.不要随性的建系统.确保你的每一个功能都有客户使用。
2.仔细控制你的依赖性。您为某个效用函数插入的库可能已经帮助您节省了一个小时实施效用函数的时间，但它增加了更多的可以出错的点，版本控制，安全性，日志记录，意外的进程死亡。
3.当你在为自己或者小团队开发，让问题先积累下然后一起修复（或者丢到代码库并且开始新的）。当你在为一个大型的系统开发，永远不要让问题累计；代码库应该总是保持干净。这是一个阅读者的结果，写作比率-这是读者的一个结果:写作比——启动代码写得比阅读要多得多，所以可读性很重要，但是成熟的代码读起来比写得多。