对于一个程序员来说怎么样才能提高自己代码能力？
 说到程序员的代码能力，其实不仅仅是代码本身，而是围绕这生产出好代码的各项能力的综合。具体来讲，主要有下面7类能力： 我们逐一概要说明下。 计算机领域有很多基础知识，比如计算机原理，编译原理，算法与数据结构，网络，操作系统，数据库……它们是编程的基础，有助于代码能力提升。 当然它们很难全掌握。其实也没必要全掌握，你把和自己工作相关的那些内容，搞明白就行了。比如你做驱动开发，就要高清计算机组成原理，指令集，内核驱动架构等。 编码能力具体指写代码水平，你写得快 or 慢，优雅 or 笨拙，清晰 or 杂乱，简洁 or 复杂，适度 or 冗余…… 这些是你在代码中呈现出来的素养，有时候看着差不多，但久而久之，会差很远。 程序设计能力，指对完成小规模任务的子程序、子模块、子系统的设计能力，通常体现在业务逻辑映射、代码结构（设计模式）等方面。 比如你写了一个算法的动态链接库，就要导出对外的接口，你接口设计得如何？比如你程序中要频繁创建对象，是不是可以用工厂模式或抽象工厂？ 类似这种，都是“程序模块”上的设计能力。 系统架构能力指架构整个软件系统（通常对应一个完整业务或横跨多个业务）的能力。比如一个电商网站的整体架构，比如一个安防系统的整体架构。 系统架构能力是比程序设计能力更高一层的软件设计能力，对应的角色，往往是系统架构师，这也是很多程序员的梦想。 程序设计能力、系统架构能力，在很大程度上决定了软件的质量。如果这两方面不过硬，做出来的软件，出了问题，修复的代价就会非常非常高——一个微不足道的Bug，都可能引发熬夜加班。 软件是为了实现某种业务、满足用户某种需求、为用户提供便利。所以，作为程序员，得能够理解业务层面的东西，知道你写的代码，究竟有何意义，能怎样帮助用户解决问题，用户会怎样使用……理解这些，才能更好的做架构设计、程序设计，进而才能更好的编码。 而如果业务理解能力很差，就很容易出现驴唇不对马嘴的情况，给项目干系人带来无尽的麻烦…… 软件开发的目的是生产可以满足用户需求的产品，因而它是一个系统性的工程，有需求调研、业务拆解、系统架构设计、模块程序设计、编码、调试、测试、部署、运维、支持…… 在这整个作业系统中，程序员是生产链条中的一个环节，他交付的产品，必然会有一个“客户”——要么是下游的开发，要么是测试，要么是运维，要么是最终用户，不管是谁，不管是内部的或外部的，总之，会有一个客户。 而当你要交付给客户东西，就需要是一个可以拿来即用的产品化的东西，而非“一堆代码”，不然客户就难以使用，就会感到不友好，就会降低对你的评价。 我早几年负责过车载嵌入式产品开发，团队里驱动组有两个伙伴，习惯于调试完驱动后，就把代码提交，告诉我任务搞定，可以让应用组的人开工了。 应用组的程序员签出了驱动组的代码，一通猛整，发现跑不通，就过来找我，说驱动组提交的东西就是个半成品，缺一层适配接口，上层代码没法直接调用，驱动组的同事坚持不做接口封装，导致工作无法开展。 驱动组的同事此时会拿出自己的示例程序，跑一遍，说，你看，这不好好的嘛，能跑嘛，你跑不起来是你没写接口呀。 可应用组的同事确实没办法直接使用驱动组提交的代码，也不大可能把驱动组的测试程序整合进产品中。 像这种情况，实际上就是驱动组的程序员缺乏产品化意识和能力导致的——从为客户提供服务的角度来看，它们应该封装出硬件无关的接口给应用组的同事来调用。 在软件开发中，这样的情况非常多，我们一定要意识到，完成代码只是一部分工作，我们更重要的工作，是把代码作为产品交付给“客户”，让他们能“拿来即用”，实现自己的需求。 这就需要我们建立产品化意识，培养产品化能力，保证自己能交付出方便客户使用的东西。 前面说的很多能力，系统架构、业务理解、产品化，其实都离不开人际技能：你不善沟通，就很难和产品经理有效互动；你不善沟通，就很难和开发团队成员顺畅协作；你不善表达，就很难在项目中说出自己的看法，获得别人的支持…… 所以，人际技能，是一种通用的、支撑性的能力，有了它，你才能在软件研发团队中顺利开展工作。 功夫在诗外，希望每个程序员，都可以综合培养以上7种能力，有效提高自己的“代码能力”。 点个赞啦啦~