是时候表演真正的技术了！！！

问题：什么才算是真正的编程能力？

还在读书，也在实验室帮忙做了些东西，自己也搭过几个网站。在周围人看来似乎好像我很厉害，做了那么多东西，但是我发现这些东西虽然是我做的，但是实际上我手把手自己写的代码却并没有多少，很多都是用开源的东西，我写的代码无非是把别人的东西整合下，类似于胶水一样的工作。

我之前所认为的编程是全手动一行一行敲代码，但是现在我发现哪怕是工程上也有很多人是复制黏贴来解决问题的，并且提倡不要重复造轮子。

但是靠谷歌和复制别人的轮子，虽然我做出了很多东西，可是我并不觉得自己能力上有提升，倒是利用搜索引擎的能力的确提升了不少。而学校里另外一波搞ACM的人，他们每天刷题练算法，或许倒是的确提升了点编程能力，但是对工程几乎一窍不通。

所以我现在就很困惑，所谓的编程能力到底是什么，我该如何提升自己的编程能力？

回答者：刘贺-- 搞懂理论，深化系统

非常好的一个问题。这可能是我在知乎见到过的问编程有关的问题中问得最好的一个了。我非常喜欢这个问题。

计算机科学有两类根本问题。一类是理论：算法，数据结构，复杂度，机器学习，模式识别，等等等。一类是系统：操作系统，网络系统，分布式系统，存储系统，游戏引擎，等等等等。

理论走的是深度，是在追问在给定的计算能力约束下如何把一个问题解决得更快更好。而系统走的是广度，是在追问对于一个现实的需求如何在众多的技术中设计出最多快好省的技术组合。

搞ACM的人，只练第一类。像你这样的更偏向于第二类。其实挺难得的，但很可惜的是第二类能力没有简单高效的测量考察方法，不像算法和数据结构有ACM竞赛，所以很多系统的苗子都因为缺少激励和正确引导慢慢就消隐了。

所以比尔盖茨才会说，看到现在学编程的人经常都把编程看作解各种脑筋急转弯的问题，他觉得很遗憾。

做系统，确实不提倡“重复发明轮子”。但注意，是不提倡“重复发明”，不是不提倡“重新制造”。恰恰相反的，我以为，系统的编程能力正体现在“重新制造”的能力。

能把已有的部件接起来，这很好。但当你恰好缺一种关键的胶水的时候，你能写出来吗？当一个已有的部件不完全符合你的需求的时候，你能改进它吗？如果你用的部件中有bug，你能把它修好吗？在网上繁多的类似功能的部件中，谁好谁坏？为什么？差别本质吗？一个开源代码库，你能把它从一个语言翻译到另一个语言吗？从一个平台移植到另一个平台吗？能准确估计自己翻译和移植的过程需要多少时间吗？能准确估计翻译和移植之后性能是会有提升还是会有所下降吗？

系统编程能力体现在把已有的代码拿来并变成更好的代码，体现在把没用的代码拿来并变成有用的代码，体现在把一个做好的轮子拿来能画出来轮子的设计蓝图，并用道理解释出设计蓝图中哪些地方是关键的，哪些地方是次要的，哪些地方是不容触碰的，哪些地方是还可以改进的。

如果你一点不懂理论，还是应该学点的。对于系统性能的设计上，算法和数据结构就像在自己手头的钱一样，它们不是万能的，但不懂是万万不行的。

怎么提高系统编程能力呢？

土办法：多造轮子。就像学画画要画鸡蛋一样，不是这世界上没有人会画鸡蛋，但画鸡蛋能驯服手指，感受阴影线条和笔触。所以，自己多写点东西吧。写个编译器？渲染器？操作系统？web服务器？web浏览器？部件都一个个换成自己手写的，然后和已有的现成部件比一比，看看谁的性能好，谁的易用性好？好在哪儿？差在哪儿？为什么？

更聪明一点的办法：多拆轮子。多研究别人的代码是怎么写的。然而这个实践起来经常很难。原因：大部分工业上用的轮子可能设计上的思想和技术是好的，都设计和制造过程都很烂，里面乱成一团，让人乍一看毫无头绪，导致其对新手来说非常难拆。这种状况其实非常糟糕。所以，此办法一般只对比较简单的轮子好使，对于复杂的轮子，请量力而行。

轮子不好拆，其实是一个非常严重的问题。重复发明轮子固然是时间的浪费，但当轮子复杂而又不好拆的时候，尤其是原来造轮子的人已经不在场的时候，重新发明和建造轮子往往会成为无奈之下最好的选择。这是为什么工业界在明知道重复发明/制造轮子非常不好的情况下还在不断重复发明/制造轮子的根本原因。

程序本质是逻辑演绎的形式化表达，记载的是人类对这个世界的数字化理解。不能拆的轮子就像那一篇篇丢了曲谱的宋词一样，能读，却不能唱。

回答者：mu peng，less is more -- 懂得取舍

在有限的时间内，几乎没有系统可以做到完美。要快，要安全，高并发，易扩展，效率高，容易读，高内聚，低耦合...

大到一个网站，小到几个class，工程师都要清楚，要取什么，舍什么，这并不是那么容易的事。我们都有自己的性格，有的求新，有的求稳，有的求快，但具体到一个项目时，知道如何取舍对这个项目最好，很重要。

学校里的作业，没人在意你是不是写在一个大的main()里面，能跑就行。但做项目的时候，太多的东西要考虑，有时候，宁可简单易读，也不用快那么一点点；有时候，要做太多看不到的工作，却丝毫马虎不得；有时候，写了不如不写，留白也是一个学问。

小心无时无刻不在变更的客户需求

曾经接手个项目，里面几乎所有的class，每个都有interface，各种继承，各种实现，理由是灵活性高，易扩展。真的易扩展吗？我不知道。

没多久，客户的需求就改了，各种拎不清的继承实现都化为乌有，一大半要重写。

问题在哪里？

不是编程不好，而是取舍的不好。在那个阶段，为30%的需求，花200%的努力，追求设计的滴水不漏，却舍弃快速实现，取得反馈的时机，这就是失误。需求总会变，客户看到越早，修改越早，影响越小。

很聪明的人，也可能做出很难用的系统，不一定是编程不好，可能是不愿，或不屑于取舍。不同的阶段，不同的项目，要取舍的东西也不同。编程只是手段，目的是解决问题，能力高不高，要看问题解决的好不好。不在于使用了什么高端算法，或是复杂的框架。

懂得如何取舍并不容易，需要对问题的深刻理解，对技术的胸有成竹，和身后无数个踩过的坑。但重要的是有取舍的意识，主动思考取舍什么，这样学的才会快。

回答者：丁盛豪，网络媒体HeckPsi.com创始人 -- 学会Debug

对于编程能力这个问题其实我也想过很久，这个东西确实非常难界定。单纯靠算法水平、编程速度、工程经验都很难说是编程能力。

虽然这个东西的影响因素非常庞大，但从我日常的工作来看，其实我觉得衡量编程水平最靠谱的方法是观察这个程序员 Debug 的能力。

程序从本质上来说就是 输入 -> 处理 -> 输出 的过程，而中间的处理就像是一个巨大的黑盒子。而这个黑盒子的本身就是程序，在大多数情况下你并不能看到这个黑盒子的全貌。从常识上写一个不存在 bug 的程序是一件 几乎 不可能完成的任务。即使是敲个最简单的 Hello World 程序，你也很难保证编译器不给你抽几下风。尤其是当这个程序变得非常庞大时，写程序这件事的本身就是 盲人摸象 的过程。程序员必须要有相当好的 全局观 ，才能保证自己的程序良好运行而不出问题，并能在出了问题之后能够做出迅速的定位和修复。
所以观察一个程序员能否 迅速Debug 的过程就是一个很好的判断依据。

举个例子来说

我几周前给手机刷了机，第二天早上准备去晨跑，发现手机 GPS 不工作。于是我立刻分析了出现问题可能的地方：

GPS 模块硬件 -> GPS 驱动 -> 系统配置 -> GPS 权限 -> 软件兼容性

由于想起刚刷了机，基本可以排除硬件问题。而软件之前同样在其它 Android 5.1 机器上跑过，同时跑了下 Google Maps 也不能定位，排除兼容性问题。原生系统的权限系统非常简单，基本排除是权限。出问题的可能是第三方 ROM 的驱动有问题或者配置文件。观察到 A-GPS 基站辅助定位也不工作，基本排除 GPS 驱动问题。确认是配置文件有问题，检查 /etc/gps.conf 竟是空文件。于是就在手机上用文本编辑器顺手码了一段配置，重启后问题修复。

这就是一次非常流畅准确的对一个未知的 Bug 定位和修复的过程。

是时候表演真正的技术了！！！

由于 Bug 的未知性，可以很好避免一些你在判断时可能遇到的 作弊 情况，我们知道现在很多人为了面试无所不用其极。就算是以前非常经典的面试问题，现在也很不靠谱。现在你问 “如何理解面向对象编程？” 和你对答如流的人可能并不真正理解 OOP，不过背的很熟而已。以前觉得算法是个很好验证水平的切入点，自从 LeetCode 背题流的出现，这招现在也不怎么靠谱。而 Debug 是个无法 提前准备的东西，所以对于编程能力的校验通常很准确。

而且，Debug 的过程中会接触到自己很多不熟悉的知识。由于编程本身就是一个 Engineering，正常的过程就是在 码字 -> 出问题 -> 学习 -> 修改 的过程中循环。如果你对算法不熟悉，那么遇到程序性能问题的时候你硬着头皮也要用学习算法知识来解决掉。所以这是一项非常综合的能力，是程序员 知识、智力、经验 的综合体现。

至于如何提升编程能力？

多写、多错、多学。没有捷径，捷径只不过是作弊。作弊能帮你找到工作，但并不能真正解决问题。