如何成为一个优秀的程序员
入工程师程序员一行，怎么才能成为以一当十，当五十的优秀程序员呢，我想还是那句老话"业精于勤而荒于嬉"，勤 是指勤于思考，并知行合一。
一个优秀程序员和业余程序员的区别
今天早上，刷微信看到伯乐在线上MeteorSeed的这篇狼与哈士奇文章。发现是应该把优秀的软件工程师和业余的软件工程师列一个对比出来，砥砺自己！ 祝愿每一个人都可超越优秀的工程师成为卓越的工程师。（ps 其实现实中狼和二哈这两种动物我都很喜欢！ ）
| 优秀工程师 | 业余工程师 |
|---|---|
| 他们写代码像写一篇优秀的文章，凡人都可看懂，却又字字珠玑，像一个艺术品 | 他们只是写出机器可以理解的代码。 |
| 他们的代码风格统一并有描述性，除非必要不加额外注释。 | 他们的代码依靠注释读懂。 |
| 他们不仅在工作时间，在业余时间也会写代码。 | 他们只在工作时间写代码。 |
| 他们会看大量的书籍，阅读大量技术资料，当然也会看视频。 | 他们只会阅读别人的博客，自己从来不写。 |
| 他们不仅阅读别人的博客，他们自己也会写博客，他们认为分享知识是快乐的。 | 他们只会阅读别人的博客，自己从来不写。 |
| 他们不仅关注进度而且更关注代码的质量，提供现实的进度方案，在上司面前坚持自己的意见。 | 他们关注的仅仅是进度。 |
| 他们复用代码而不是复制代码。 | 他们仅仅是复制代码。 |
| 遇到问题他们会尝试自己解决，访问社区，然后才会询问同伴。 | 遇到问题他们会直接问同伴。 |
| 他们总是认为自己还能做的更好，并对那些巨人由衷地敬佩。 | 他们总是认为自己会的很多，喜欢用海量的“精通”来装点自己的简历，假装高手。 |
| 他们经常在思索如何能够解耦，用灵动的设计应对突然到来的变更。 | 他们每天沉寂在C+V的死循环中，并不断地抱怨需求变更。 |
| 当掌握某种代码的写法，他们看到的往往是背后深层次的问题，并向专业水准看齐。 | 他们会因为学会了某种代码的写法，而骄傲自满。 |
| 他们会对不合理的需求说不，并在工作中尝试影响他们的领导。 | 他们一边在被动地接受需求，一边在抱怨不合理的需求。 |
| 他们会经常重构自己的代码，并维护自己的缺陷核对表。 | 他们不会检查自己的代码，在测试暴露缺陷之前，他们往往难以发现。 |
| 他们认为提高代码质量是自己的责任，并为自己的过失而负责。 | 他们不认为自己要为代码质量负责，那应该是管理者和测试的事情。 |
| 他们在拿到任务后，会在行动之前，进行分析和计划，而不是马上编码。 | 他们在拿到任务后会直接开始工作。 |
| 他们往往会认真阅读项目文档。 | 他们往往具有文档恐惧症。 |
| 他们和希望提高软件开发技能的人为伍，参加高手交流会，加入某个社区参与技术讨论。 | 他们并不崇拜专业人士。 |
| 他们敢于承认错误。 | 他们擅长推卸责任。 |
| 他们将警告与错误同等对待。 | 他们对编译警告弃之不理。 |
| 他们在构建自己彻底理解的程序。 | 他们只是在写可以运行的程序。 |
| 他们将不喜欢的任务认为是对自身的磨砺。 | 他们会拖延不喜欢的任务。 |
| 他们往往坚持自己的设计。 | 他们更容易放弃自己的设计。 |
| 他们的编程往往深入语言，触及思想。 | 他们的编程往往止步于编码的表象。 |
| 他们往往站在整体来考虑问题 | 他们往往只关注目前 |
| 他们往往一边测试一边开发，保证新加入的代码模块的正确性，及早发现问题 | 他们往往把发现问题寄希望于最后的测试或者想当然的认为自己的代码没有什么大问题 |
