惨痛教训

1. 无论如何, 一定要想办法能单步跟踪;
2. 无论如何, 一定要有很方便的测试数据;
3. 对于引用同一个名字的UserControl, 它们很可能不是同一个文件！！！
4. 对于看着很奇怪的问题， 应该把它写下来， 把前提和结果都详细写下来， 再仔细看前提。 大部分奇怪的结果是因为你错误的前提造成的——你的前提之中， 就有了一部分是由于粗心而弄错的， 它们实际上并不是你想象的样子
5. 对于人名, 如果用户保存时包含了单引号或者双引号, 会引起意想不到的错误, 应该禁止;
6. 如果一个业务功能，逻辑相当之复杂，以致于要写很多代码来完成，而且易于出错。应试首先试着想：是否能从业务的角度来简化，而不是死盯技术。
   

----------------------------------------------------------------------------

1. 对于Producation, 一定慎之又慎 , 如是能只改query 的, 尽量不要修改insert/update, 即使原有的设计有漏洞;
2. 对于producation, 最好是能直接以用户的身份登录, 在项目刚开始设计时就做到这一点, 否则出了错误很难远程模拟和排除; 在用户反馈有错误时, 第一步就是进以用户身份登录直接查看, 模拟用户的操作, 取得一个直观的感觉; 做完这个看不出问题来, 才应该去查找DB和代码;
3. 对于需要修改代码或者跟踪调试的部分, 应该连接上镜像数据库, 再调试.