程序员差异详解
程序员的好坏，一方面体现在编程能力上，比如并不是每个程序员都有编写一个编译器程序的能力；另一方面，体现在程序设计方面，即使在没有太多编程技能要求的领域下，比如开发一个订单管理模块，只要需求明确，具有一定的编程经验，大家都能开发出这样一个程序，但优秀的程序员和糟糕的程序员之间，依然有巨大的差别。
在软件设计开发这个领域，好的设计和坏的设计最大的差别就体现在应对需求变更的能力上。而好的程序员和差的程序员的一个重要区别，就是对待需求变更的态度。差的程序员害怕需求变更，因为每次针对需求变更而开发的代码都会导致无尽的 bug；好的程序员则欢迎需求变更，因为他们一开始就针对需求变更进行了软件设计，如果没有需求变更，他们优秀的设计就没有了用武之地，产生一拳落空的感觉。这两种不同态度的背后，是设计能力的差异。
应对需求变更最好的办法就是一开始的设计就是针对需求变更的，并在开发过程中根据真实的需求变更不断重构代码，保持代码对需求变更的灵活性。
我们在开始设计的时候就需要考虑程序如何应对需求变更，并因此指导自己进行软件设计，在开发过程中，需要敏锐地察觉到哪些地方正在变得腐坏，然后用设计原则去判断问题是什么，再用设计模式去重构代码解决问题。
技术实力详解
理解评估技术实力的基本原则后，我们知道了需要解决的问题复杂度越高，技术实力就越高。在这个基础上，我把技术实力分为两大类 6 分类：
硬实力：真正解决问题的能力，别人可以看出来的能力，技术实力按照“点、线、面、体”的 4 个分类逐层上升；
软实力：比硬实力更厉害但也更虚的能力，简单来说，要想解决问题首先得发现问题，但很多时候问题并不是一目了然的，需要有一定的技术洞察力。软实力主要包括 2 个核心能力：发现问题、技术创新。
硬实力-技术点
“点”就是某个具体的技术，用来解决某个具体的问题，例如使用 JDBC 从数据库读取数据，目的是解决数据掉电丢失的问题；使用 Java 多线程，目的是为了解决大量用户并发访问的吞吐量和时延问题。掌握了技术点，就可以开始基本的业务功能开发了。
硬实力-技术线
“线”就是一系列相关的技术点组成，每个技术点都是为了解决某个问题。例如：
为了完成一个用户请求，开发框架首先要有路由 router 功能，路由到具体 Controller 后，Controller 进行业务逻辑处理，处理过程中可能会使用 JDBC 来读取数据，访问 Redis 读取缓存等，这一连串的技术每个都解决了一个问题点，串起来就完成了一个业务功能的处理过程。
为了定位一个线上 Java 服务器响应慢的问题，需要用到 tcpdump 抓包，使用 Java 工具查看 jvm 的状态，使用 mysql 命令行或者工具查看数据库状态，使用 explain 分析可疑 SQL 语句。
掌握了技术线，就可以完成某个业务功能的全流程设计和开发了。
硬实力-技术面
“面”就是某一类相关技术线的综合。例如：
Java 开发是一个技术面，包括多线程、JDBC、文件读写、JVM 调优、JVM 工具等多个技术线；
高性能开发是一个技术面，包括：数据库分库分表、缓存、多线程、HTTP 优化等；
数据库维护是一个技术面，包括：数据库调优、数据库问题定位、高性能数据库表设计等；
掌握技术面，已经是某个领域的专家了，简单来说就是这个领域的问题找你都可以搞定。
硬实力-技术体
“体”就是多个技术面的综合。
最常见的“体”就是架构设计，对于一个大型业务或者系统的架构师来说，需要掌握多个技术面，然后进行设计和取舍。例如，一个后台架构师需要掌握 Java 的技术面、数据库的技术面、网络的技术面等，以及业务领域知识。
架构设计是横向技术面的综合，我称之为广度技术体；还有一种纵向技术面的综合，我称之为深度技术体。例如 Java 的开发工程师，当达到技术面的水平时掌握了“多线程、JDBC、文件读写、JVM 调优、JVM 工具等”，如果需要进一步在 Java 这个领域提升技术，就需要向下了解操作系统、硬件（CPU、内存、磁盘等），从而更好的解决某些复杂的问题，例如 Disruptor 高性能并发框架的设计。掌握了技术体，就可以进行架构设计，或者成为某个领域的资深专家了，解决领域级的复杂问题。
软实力-发现问题
有的问题很明显，例如线上出故障，系统性能不达标，系统性能需要达到 5W QPS；但有的问题并不那么明显，并不能一眼看出是问题在哪里，是技术问题还是管理问题。
例如我们曾遇到团队间协作开发效率很低，每次开发一个业务功能，都需要几个系统的研发人员来讨论接口协议、接口数据格式、接口安全加密、业务逻辑等，大家都不厌其烦，但好像又都必不可少，团队间为了提高效率，项目经理制定了规范、流程、模板等，但作用最终都不大。那后来是怎么解决的呢？通过引入服务中心来完成系统间同步接口调用，通过引入消息队列来完成系统间异步消息通知，系统间协作效率大大提高，以前要开会讨论几个小时的事情，现在只要明确接口传输的数据内容即可，甚至都不用开会，两个研发一讨论就差不多了。
除此以外，问题的根源往往掩盖在很多问题表象之下，如果不解决根源问题，解决一个表象问题，获得一时安宁，一段时间后又发生另外的问题，长此以往反反复复。
例如我们曾有个系统，今天交换机故障导致业务问题，明天系统 bug 导致业务问题，后天机柜断电导致业务问题，还被黑客攻击过，这些问题看起来都很独立，问题的发生也感觉都是偶然的，按照出一个问题解决一个问题的方式也没什么问题，但全年来看，业务就是出了很多问题，怎么解决？我们经过分析，发现根本原因是业务需要异地多活，而架构是双机房单中心的，我们需要做到的不是避免每个问题的发生（事实上也不可能避免），而是应该做到问题发生后能够快速处理，于是通过将架构重构为异地多活，重构完成后还是有各种偶发问题发生，但对业务的影响就很小了。
发现问题的能力主要来源于经验，包括成功的经验、踩坑的经验、参考别人的经验，因此如果要培养自己这方面的能力，多思考、多总结、多学习、多参加行业交流。
软实力-技术创新
达到这个级别基本都是业界大神一般的级别，说实话我也没什么经验，只能仰慕这些大神。
例如：
当年贝索斯要求亚马逊公司内的系统都服务化，后来是哪位大神想到可以把这个能力开放出来转换为“云计算”？
阿里云王坚博士当年在众人都不看好的情况下为何坚持云计算是未来？
Google 在解决大数据问题时，如何能够提炼出三篇论文，开启了一个大数据时代？