作为一个程序员的检讨

1.     不要磨灭对技术追求的热情。
先和大家分享一个笑话，很多人都会问，如果你中了彩票，你会做什么？一个码农说，如果我中了彩票，我会做一个开开心心的码农，做一个apache开源项目的commiter。在培训上，一个讲师提到一句话，作为一个专业的码农，是不能只把编程作为你的工作，否则你永远都只是一个菜鸟码农！在平安这个万事求稳的环境下，技术
创新显得不太重要，至少不是需求范围内的，很多同事对新技术的追求热情都被磨灭掉了，但是，对于一个程序猿来说，技术就是最基础能力了，无论你以后想走什么路线，别以为你想着以后走管理路线，就不用管技术了，至少你的技术好就不至于被你的手下忽悠吧，一个好的管理者，是需要对技术有前瞻性的能力的。在这里推荐
一本杂志《程序员》，是CSDN出的，每个月一本，如果家里有PAD的话，下载一个应用，可以免费看，不过最近的两个月的还是要收费的。看这些杂志，可以让你对最近的新技术有大概的了解，而不至于听到别人讲，你只能一脸迷糊！

2.       不要用面向对象的语言写面向过程的程序。
财务系统，很多代码都是用pkg实现的，可能是因为这个原因，导致很多同事都按照写pkg的方式去写java程序。面向过程的语言，都是一堆IF ELSE嵌套去实现逻辑的，而面向对象则是华丽丽的链式调用，这个就是两种思想的根本区别。在大学的时候，一个教授和我说，其实用C语言也可以写出面向对象的程序，当时我很不理解，现在就有所领悟了。其实java的语法不难，但是《thinking in java》却是一本很厚的书，这本书里所描述的不仅仅是java的语法，还有面向对象的思想，这也许就是为什么thinking injava是thinking，而不叫coding in java或者programging in java的原因吧。所以写面向对象的程序不仅仅是语言的本身，而是要领悟这种思想。关于这个，推荐大家看一下设计模式，而且不仅仅只看一遍，当你的代码量积累到一定程度，回头再看这本书，你会有新的领悟，并且能够从运用设计模式来重构你的代码中体会到很大的乐趣。

3.       需求开发与单元测试，有借必有贷。
借用一下财务的概念，有借必有贷，借贷平衡。如果需求开发是借方的话，那单元测试就是贷方，这两个事情是需要一起做的，要不然就出现借贷不平的情况。也许你会觉得，写单元测试和浪费时间，浪费人力，但是往往好的项目中，单元测试的代码量是与需求的代码量相当，甚至更多的，这样可以保证项目的寿命更长，在往后的需求开发中，就不会出现“不敢改原来代码”这种现象，因为前人的测试案例的回归覆盖，会使得你更有信心去改原来的代码。在这里，强调一下，不要为了写单元测试而写单元测试，要结合实际的案例，通过不断地补充案例，这样才能更好的维护项目。

4.       分享一下自己看书的一些心德。
很多人都会有这样的经历，突然间头脑一热，就想看一本书，但是看着看着，看到不懂的地方越来越多，然后就放弃了，特别是技术方面的书，针对这种情况，分享一下我的看书心德。看一门技术的书，不要一头就扎进去，一点一点的看，要看目录然后以浏览的方式看，遇到章节中不懂的地方，马上跳过去看下一节，或者下一章，在浏览的过程，先对知识点有个大概的了解，或者只要记住有这么一回事就行，等正本书都浏览完了，对正本书都有一个大概认识后，再回头细看，不懂的再跳过，经过多次循环，你就能把书看完了。另外应用驱动学习，在应用的过程中，碰到你看过的技术点，你再回头去看那本书，你就会觉得更有味道，并且自己能在工作中用上那个知识点，兴趣就会慢慢培养起来。

最后自己检视一下自己下面几个问题：
1.       在写代码的过程中，你会因为起一个类或者方法的名字而纠结半天么？
2.       写java程序的时候，你会因为某个地方写的不好，或者高内聚，低耦合的设计不够彻底而重构一下你的代码么？
3.       写程序就像说话，你有经常想着提高自己的表达能力么？
4.       你家里电脑有eclipse等开发集成工具么？你最近打开过它么？
5.       你会在洗澡或者上厕所的时候想一个技术问题或者功能实现问题，并且在那个时刻你茅塞顿开么？