普通码农和CTO之间的差距

虚心

学习的第一步是——“我不懂”。一个空是水杯才能装水，如果是满的就没有办法装水了。“自我肯定”是一种非常难克服的习惯，经常会有朋友看到某个技术或者实现之后不假思索的是——“好烂”；如果问他烂在哪里几乎说不出个所以然来。

最近微软发布了。NetCore，如果你有机会看到这个标题的文章不妨看一下评论。各种“喷子”从“性能”、“道德”、“微软很坏”、“PHP是最好的”等各种无厘头开喷。这似乎是程序员们的通病，对于一个自己没有好感的东西（比如：国产或者微软，这两个最容易拉仇恨）会各种毫无理性的嘲讽。这种狭隘的胸襟往往会影响自己成长。

不要待在舒适区

心理舒适区，是指人们习惯的一些心理模式，是你感到熟悉、驾轻就熟时的心理状态。人在这个“区域”是非常“舒适”的一切驾轻就熟，工作轻轻松松；一旦走出这个“区域”就会感到不安全、焦虑，甚至恐惧。

一些人拥有“5年工作经验”甚至“8年工作经验”，仔细聊下来你会发现他们可能是“一年工作经验用八年”。他们用的工具是一万年的Eclipse（甚至不愿意接受新版本的Eclipse）；他们的编码风格非常具有浓郁的“历史感”；他们习惯用一些“自己”（或者公司的）一些“框架”来做开发。这就是很长时间待在“舒适区”的结果。失去对新技术的追求和探索，一味的否定或者找各种不靠谱的借口开脱会让自己的只是越来越陈旧，目光越来越狭隘直到有一天突然发现——舒适区已经没了，才真正的陷入恐慌。

勇敢的走出“舒适区”去探索新的技术，新的方法；把“非舒适区”转换成舒适区会拓展我们的知识面。这种不断探索的精神最后可能发展到——不仅仅停留在探索“IT技术”上，开始各种折腾，比如折腾电子制作、折腾写小说、折腾研究曲艺、折腾评书（好吧，后面两项是我的爱好）。

经常思考

“写程序的康德”，这个公众号的寓意就是思考，我的出发点是发一些东西可以让大家多思考（希望我达到这个目的了）。

解决完一个问题后我们要经常“回头看看”，我们要学习的不是“解决具体问题的办法”而不是“解决问题的方法”。很多朋友通过网络或者同事帮助解决完一个问题之后就没有然后了，不会去主动分析问题的原因，解决办法、原理。这样的“经验”不能算经验，最多算“经历”，没有究根问底的对一个问题进行分析，思考，不能算“解决问题”。

多读代码

最好的学习方式是“山寨”。程序员和程序员之间交流最直接的方式不是UML，不是XXX文档，而是——代码，无论是架构、设计、技巧、规范都蕴含在代码中。

OpenSource运动给世界的开发人员提供了一个巨大的仓库，里面有各种各样的项目，质量参差不齐。通过阅读优秀的代码可以提高你的见识、分析能力。这里推荐几份靠谱的代码：

Java并发包，混并发界你要是没听过DougLea那你算白混了，老爷子说得上是学术、工程两届通吃。文有提笔能写论文，武能键盘码程序的全才。java.util.concurrent依旧经典，无论是API还是性能都叱咤风云多年屹立不倒。（只要你用线程、锁这种并发模型，java的并发库分分钟秒杀所有）

Guava，比起apachecommons包它非常现代化。google的招牌这个就不必多说了。

apacheroller，如果你需要一个JavaEE的正确姿势，那么我推荐这个，除了有些显老之外没有别的缺点。Apache的招牌也是非常硬的。

做业余项目

做一个业余项目可以给我们更大的自由，在这个项目中我们可以尝试新技术，新方法，完全有自己决定所有的技术。如果一不小心，你的项目对很多人带来帮助那会给你带来更多的机会。

做一个业余项目是非常锻炼个人能力的事情，当我们在吐槽xxx技术不行的时候不妨自己在业余项目中尝试一下，或许你会理解作者的难处；当我们觉得xxx技术简直是非常酷的时候不妨自己在业余项目中尝试一下，或许你会发现它除了能写一个helloworld之外真的没有办法干别的事情了。

和别人交流

自己学会一个技术是一回事，帮助别人学会是另一回事。在工作中帮助同事解决问题往往可以给我们带来更大的收获（也会收获更大的成就感）。

和别人交流技术可以帮助我们提高两方面的能力：

提高技术理解的深度，如果我们想把一个技术讲个别人听首先要自己把它的每个知识点搞清楚。比如我们可能对HTTP协议并不陌生，但是真的要讲给别人听怎么讲？HTTP协议和TCP协议什么关系？HTTP协议有那些支持的方法？什么是无状态？为什么设计成无状态？Session和Cookie是什么关系、什么样的工作原理？看似很简单的问题，其实蕴含着很多知识点，通过“交流”我们会对曾经认为——“我会了”的技术有更加深刻的理解。

提高表达能力，表达能力不是一朝一夕练出来的，也没有固定的技巧可循，它完全是一项“实践性”技能。通过交流我们可以不断的磨练自己的沟通技巧，如果我们能把一个技术讲清楚那么我们的沟通能力应该足够我们搞定“萌妹子”的。^_^

学习技术而不是工具

在新框架，新方法，新工具横行的今天我们很难判断出哪些是“技术”，哪些是“工具”。我个人认为程序员不存在——Java程序员、Python程序员、Android程序员、iOS程序员，这些前缀都是“工具”，后面的“程序员”三个字才是技术。让一个人号称做Web的去做Android为此离职的人真的不在少说，他们的理由通常是：我是做JavaWeb的，不是做Android的。但是如果有一天Web没了怎么办？甚至有一天Java没了怎么办？（不是危言耸听，Java最近的负面新闻太多。以Oracle的无耻性格放弃它也是干得出的，不要以为名气大就不会被干掉，被干掉OpenSolaris、OpenOffice、Mysql个个历史悠久，名气大。）

那么究竟什么是“技术”？答案：数据结构、操作系统、计算机体系结构、数据库原理、编译器工作原理、软件工程方法论等。我们的所有的工作都是这些理论的实践，通过这些实践我们发现问题通过刨根问底的方式回到“理论”，这样一套追踪下来保证大家醍醐灌顶，豁然开朗，欲仙欲死，爽到爆。

举个例子，Spring都不陌生。但是它是什么？会有人用AOP、IoC来回答，那么继续追问AOP和IoC是什么？会有人举出一些例子来说明AOP和IoC。但是这些都不是答案，Spring是容器，不信可以去看官方文档开头写的

TheSpringFrameworkisaJavaplatformthatprovidescomprehensiveinfrastructuresupportfordevelopingJavaapplications.

Spring是一套Java平台的基础架构，继续翻跳过AOP和IoC之后迎来第一个模块“2.2.1”叫CoreContainer（包括spring-core、spring-beans、spring-context、spring-context-support模块）；第三部分的第一个章节（7章）叫TheIoCcontainer。所有IoCContainer是任何一个spring模块都必须依赖的基础技术，它是整个Spring的创新点和关键所在。如果你继续探索（可能需要很长一段时间），你会发现什么是组件，什么是容器，什么是生命周期管理，在这个过程中会不断的加深你对Spring的理解，也会升华你对组件开发的理解，对软件设计的理解。（在这个xxxinAction，xxx技术内幕，xxx深入浅出的时代，我要推荐一本老书《ExpertOne-on-OneJ2EEDevelopmentwithoutEJB》，作者RodJohnson，没错Spring的缔造者。有选择的看一些章节，通过“考古”你可能会发现Spring设计的动机究竟是什么。该书已经绝版，请自行搜索电子版）

我的一个经历

我刚入职的时候公司所有的Service都返回一个这样的类：

err表示是否出错，代码里面还定义了一堆的错误代码；data表示实际执行的结果。所以每次调用都要执行一个if判断，如果错误代码不存在还需要自己新增一个。虽然我的项目经理告诉我这个方法就是“标准”，但是我觉得这个写法太low了。所以等到我能自己决定怎么写的时候，我写下了下面的代码：

我的实践告诉我，没有正常人喜欢用“错误代码”，世界上不可能还有比这更恶心；也没有一个正常人喜欢强制类型转换。所以新的Result里面用isSuccess表示是否执行成功，如果失败则错误消息通过errorMessage返回；用泛型解决了Object强制转换的问题，。

当然，后来我用了异常。因为我觉得没有正常人喜欢用if来不停的判断，看起来就像C语言一样“二”。函数的执行结果并不是很明显，每次都要get一下才能拿到结果。所以我用异常来处理错误，如果出错则抛出“RuntimeException”；函数的执行结果通过函数的返回值返回。

这些变化不是一天、两天内产生的，也不是一两年内产生的。随着自己知识的积累，技术的演进我们总是会发现“新方法”，需要我们不断的“否定”->“尝试”->“否定”->“尝试”。