关于程序员，您现在想要什么样的程序员，技术好的，会很多语言，熟悉当流行的设计模式，学历高的，经验足的等。
这样的人已经可以不当普通的程序员了，这样的人适合去救火。
现在的程序员缺什么？真的缺技术吗，还是缺乏业务知识？只要给1个月时间，就1个月去培训和实战开发，什么样的技术和语言他们学不会？技术都能学会，业务知识只是饭后的小菜而已。
有些公司分高级软件工程师和初级软件工程师，初级和高级差在哪里？也许这个高级工程师已经不会写代码了，但是可以肯定的是，让初级工程师设计一个类，肯定与高级工程师有很大的不同。
想要什么样的程序员，程序员缺什么，初级程序员和高级程序员差在哪。很多问题和现象，足以说明我们想要一个能写出简简单单代码的程序员，写的代码越简单越好，代码量越少越好，简单就是美。
但是简单很难，小时候认为幸福很简单，长大了却觉得简单很幸福。
我们在开发系统时，经常走进焦油坑，进去了就出不来了，后面又有很多压力把你推向焦油坑。为什么有这样的焦油坑，如何避免，我们就想到了解决此问题的那些程序员。
什么是焦油坑？陷阱，沼泽都差不多。
1 这**是谁写的？
2我需要详细的注释、详尽的文档、详细的…
3 不懂瞎改！
4一打开旧代码就头大，还不如我自己重新写一个
5 月月都有工作交接。
……
怎么办？
领导会说，为什么不能一次性把事情做好？知道产品质量是研发的生命线吗？
也许我们每天都想着把代码写好，写的不用再去维护。那是不可能的，活下去就要维护，不维护的话就不需要程序员。
把代码写好，写满注释，方便后期的维护。有几个人会看注释，有几个人会在修改代码后去修改注释，有几个人能忍受的了满屏幕绿色的注释。
把代码写好，最起码自己能看的懂自己的代码，以后就自己去维护。一个团队要是没有人员流动，那是件多么美好的事，但那也是件多么可怕的事，血液需要流动人才能活，流动太快那是再放血。
所以每个人都想着别人的代码写的简单，自己很容易能看懂，并且很简单的去修改和维护。所以说，简单才是美，有本书叫clean code，讲的是如何清减代码。
在上大学的时候，一个校外的软件公司来学校开一个报告会，会上软件公司的嘉宾讲他们招聘的软件工程师有多么的厉害，传说他写的代码别人都看不懂，我当时好天真的觉得他好牛啊。现在我在想，他的代码别人都看不懂，那万一他走了，是不是这个软件也就over了。
所谓的把代码写好，一次性把事情做好，就跟抗日战争片上演的“兄弟们，为了新中国冲啊！”。我们不是那些和尚，徒手可以把人撕开；我们不是那么厉害的八路军叔叔，徒手把手榴弹扔到空中炸下日本飞机；我们不是那传奇的小孩，一个石块把坦克打爆炸。如果没有丰富的经验和明确的自我认识，我们写代码也会像那些冲向枪口的兄弟们，牺牲的不仅是自己，也是公司的利益。
好的代码不容易写，也难一次性也好，所以重构是必须的。在有单元测试、集成测试的保护下，我们可以放心的对我们的代码做手术。
整天重构也不是好的方法，需要一定的人力和时间，人力和时间就是公司的血脉，不能浪费。所以我们尽量保证一次性代码的良好率。代码圈复杂度、review、代码分析都是检查代码的方法。
有很多技术可以检查我们的代码，让我们提交的代码保证一定的质量，但是这不是根本，根本是我们自身的习惯。
我们不能认为自己工作三五年了，写的代码肯定很有品味，我们要放低身段，想品尝别人的好茶，必须先把自己杯中的茶水倒掉。骄兵必死，不能像伟大的中国那样被一直所谓的倭寇打的人亡地黄，否则下次伟大的中国又要用几亿人的性命和几十年的时间去抗菲或抗越，也许不再有中国的存在了。我们必须重新的审视自己和认识自己，看看自己写的代码是不是很美很简单。
也许我们从来没有重视过所谓的magic number，魔法数字，很神奇，在人类的文明史上，最大的成就就是魔法数字，用1代表什么，用2代表什么。计算机中0为false1为true，这个已经被公认，人人皆知，很有魔力。但是如果自己和几个同事随意的定义-1为false，0为null，1为true，请问下次要是再来个新同事，他会知道吗？请问如果您的这个魔法数字在程序中跑来跑去，最后被用来计算，这是什么样的后果？请问您要是将此作为参数，我就不传这几个数字，您会怎么样，又要去判断，去抛异常么？2就是2,3就是3，请不要用它来代替什么，它什么都不能代替，要是能，您这位工程师也要即将被它替代。
枚举，我们有时候会用到，但是用到的很少。纵观.NET，里面的枚举数量也许比我们的工程师一辈子写的代码还多。枚举是个好东西，可以控制我们的输入，可以帮我我们去明白数字的意思。相比魔法数字，为何不用枚举？
类的命名，类是个对象，对象又是什么？如果不知道，即可回家养猪种田。我们最起码知道，对象是个东西，是个能去形容的东西，它有自己的名字，它是个名词，那么类必须是个名词，如果发现用动词去命名，为何不反省一下。也许我们对英文很头疼，但是我们有与英文相媲美的拼音呀，不懂英文名，拼音也是可以借用的。
方法的命名，方法是一个小工具，它要完成某个功能，所以它是个行为，它的命名应该是个动词，以动词作为前缀，如get，set，query等。
方法的返回值，我们有时只重视功能，不去管它返回值，只要能满足我的需求就行一个行为总是有个结果的，但是这个结果如何定义，是很有科学性的。对于方法的内部，需要校验参数，必要就throw exception。学会使用try
catch。
方法的排序，这个每个人都有自己的习惯，大部分人的习惯就是先来后到，先写的那个方法就在上面，后写的就继续往后续，杂乱无章；有点经验的人会用rengion把方法跟模块，有的人会把public方法放在一起因为别人要看到要用，把私有方法放在一起仅供自己看，慢慢的自己也会不满足于这种排列方式。其实我们应该遵循我们看代码的方式，将某些功能的放在一起，public方法下面紧跟的是其调用的private方法，不至于代码跳来跳去的。
注释，对这个仁者见仁智者见智，关键点的注释可以起到幻龙点睛的作用，但是冗余的注释会阻碍我们看代码。注释会有利有弊，利是方便我们读懂代码，弊是注释经常未与代码同步、注释代码显得代码难看。所以我们只需要关键的注释即可，我们要注意方法的命名，让人看后就懂得这个方法的作用是什么。