关于 代码重构和测试
当需要为程序添加一个功能，而代码的现有结构无法很方便地达到目的，那就先重构那个程序，使功能的添加比较容易进行，然后再添加那个功能。
重构前，先检查自己是否有一个可以依靠的测试机制。即有较完善的自测规范、测试用例和覆盖率较高的单元测试。
重构的每个步伐要尽量小，如果犯下错误，容易发现，必要时也便于roll back代码。
注意代码的可读性。
重构：对软件内部结构的一种调整,目的是在不改变软件外在表现的前提下，提高代码的可读性，可理解程度，降低维护和修改成本。
数不过三，三则重构。当项目中多次出现重复代码时就要考虑怎么提取和重构这些模块了。
接口的设计要考虑清楚，要兼顾稳定和扩展性，不要过早发布接口。谨慎修改代码的各种规范，使重构的过程更加顺畅，不要进行到了一半再折回来修改以前的代码。
当需要撰写注释时，先尝试重构代码使注释显得多余。
确保所有测试都完全自动化，让它们检查自己的测试结果。简而言之，即编写尽可能完善的单元测试。
一套测试就是一个强大的bug检测器，能够大大缩减查找bug所需要的时间。
频繁地进行测试。每次测试请把测试也考虑进去--每天至少执行测试一次。
每当收到bug报告，可以考虑先写一个单元测试来暴露这个bug。
编写未臻完善的测试并实际运行，好过对完美测试的无尽等待。
考虑可能出错的边界条件，把测试火力集中在那儿。实际编码中，经常有80%的代码用于处理占所有测试用例20%的边界条件。
在可预期的可能出错的地方，检查是否抛出了预期的异常。
不要因为测试无法捕获所有bug不就写测试，因为测试的确可以捕捉到到大多数bug。
关于程序员的学习技能
-
一个程序员在工作中用到的基本技术：
- 单元测试
- 功能测试
- 源码管理
- 持续集成
- MVC框架
- ...
刚开始的时候需要认真的一点点学，确实比较慢，但是学的越多，站的就越高，眼界就越宽，在学习编程的道路上就像有了加速度，越跑越快
关于需求分析的步骤
1）什么人会使用这个系统？
2）不同的人将会使用这个系统的什么功能？
3）还有哪些不确定或不具体的需求点？
4）哪些需求对技术提出了怎样的要求？
5）系统的大致架构应该如何考虑？
具体分析详述见 张传波先生的博客
一个优秀的设计应该具备的特点
1）优秀的设计都是需求驱动的，不熟悉需求就做出来的设计是不靠谱的.
2）优秀的设计应该是当前团队能理解能实现的，太超前的设计项目团队做不出来，这个设计只能是摆设.
3）优秀的设计应充分考虑当前各种限制条件，适当做出平衡，能保证达成项目的目标.
4）优秀的设计能尽量降低项目的整体工作量，让整个项目更加可控.
每次开需评需要扪心自问的两个问题
1）这个项目的主要需求？
2）这些需求，设计上是如何考虑实现的？
个人对标管理
