学习
1 学习OOP时要结合OOD,OOA,否则是很难理解什么是面向对象设计。
2 了解UML
3 了解设计模式
4 学习开源项目
5 项目比较大时,可以先用UML作图，问题不清楚时，也要先画图。比较清楚解决方案时，可以先写测试用例，这样也可以把类的结构考虑清楚，自动解耦。
6 多看书，多去好的Blog，Msdn，少去论坛
7 数学是计算机的基础。
8 学校学习的计算机基础课是你不能忘记的。
9 每天要看些英文的资料，至少要保持住自己的英文水平。
10 合理的安排时间，做好计划。   

TDD：

如果要成为负责，高效的程序员一定要写测试用例，否则维护代码时，需求改变时就是你后悔的时候。

一、对复用你的代码的人、维护你的代码的人都是莫大的财富，如果没有测试用例，即使代码的结构很完美，耦合性很低，维护起来也是很难的。原因是，没有方便的测试方法，读代码要比读测试用例费力的多。
二、对自己以后的维护也方便。如果没有测试用例，随着时间的流逝，遗忘的会很多。即使自己维护，也是头疼的事情。更要命的是会产出对维护的恐惧和惰性。
三、测试用例一定要在写代码前写，不要试图为旧代码添加测试用例，那是不可能的。

 性能

除非看到性能受影响的迹象，否则不要过多考虑性能问题，通常架构的合理性要比性能重要，实现的简单性也比性能重要。改进性能的前提：
一、性能影响到程序的运行，或者客户对性能有严格的要求。
二、有证据表明此项改进能显著提高性能。
三、改进性能是比较简单的工作，如果改进很难实现并且改进后性能提高也很少就不应该花费时间在性能的改进上面。

态度

一、bug要发现一个解决一个，不要让它过夜。自己不要有侥幸的想法，事情总会向坏的方向发展。

二、语言只是工具，不要认为任何一种语言是最优的，只有最合适的。

设计以及实现细节

如果对某种模式还不是太熟悉，就不应该在项目中套用，而应该通过重构回归到模式。关于设计和设计模式：
一、    应用设计模式的目的是封装“变化点”，用以达到两个目的：在需求变化时通过简单的修改，能使旧的设计适应新的需求，增加了程序的灵活性；改进系统的设计，降低耦合提高复用度。要实现这种灵活性，通常要牺牲系统的性能，并且加大编码的难度，因此如果系统是稳定的，就没有必要应用设计模式，那样不会带来任何好处。
二、    要正确认识耦合性，完全解耦是不可能的，因此选择设计模式时要选择合适的，如果稍大的耦合不会带来问题，就应该选择轻量级的模式，虽然它的耦合度较大，但是它比重量级的模式易于实现和维护。合适的就是最好的，过犹不及。
三、    要重视依赖关系，依赖不能形成环，也应该尽量减少传递。
四、    要注意UML图的粒度，细节的东西应该用代码表示而不是图，同样如果要考察程序的逻辑是否合理也不应该通过读代码而是要通过图，我认为这是应该用图还是代码的分界点，再比它高的层次，都应该有图形的表示。
五、   要注意类之间的依赖，尽量做当把类从一个项目移动到另一个项目时，此类可以重用，而不必修改此类的内部实现。要如此，首先就应该保证：除了参数不应该允许其他依赖关系存在。
六、异常的抛出点要认真考虑，