ReThought（三）: 说说代码

众所周知在我们公司的面试流程比较复杂——其中有一个是Homework，即给候选人一份作业，三天之内完成代码，然后会对其Review。然后的环节便是到Office结对编程。今天有幸成为一名年轻的面试官，经历了今天两小时的学习后，发现自己在代码方面还是“很弱”。

无关的编程经验

只要我有更多时间，我就会写一封更短的信给你。

从小学算起我的编程年限应该也有十几年了吧，笑~~。只是我过去的多年编程经验对于我现在的工作来说，是多年的无关经验(详见《REWORK》——多年的无关经验)。

高中的时候学习了点游戏编程，也因此学了点C++的皮毛，除了学会面向对象，其他都忘光了。随后在学习Linux内核，当时代码里就各种struct。比起之前学过的Logo和QBASIC简直是特别大的进步，然当时觉得struct与面向对象两者间没啥太大区别。在那个年少的时候，便天真的以为程序语言间的区别不是很大。

大学的时候主要营业范围是各种硬件，也没有发现写出好的代码是特别重要的一件事。也试了试Lisp，尝试过设计模式，然后失败了，GoF写DP的时候一定花了特别长的时间，所以这本书很短。期间出于生活压力(没有钱买硬件)，便开始兼职各种Web前端开发。

在有了所谓的GNU/Linux系统编译经验、写过各种杂七杂八的硬件代码，如Ada、汇编，要保证代码工作是一件很简单的事，从某个项目中引入部分代码，再从某个Demo中引入更多的代码，东拼西凑一下就能工作了。

多年的无关经验只让我写出能工作的代码——在别人看来就是很烂的代码。于是，虽然有着看上去很长的编程经验，但是却比不上实习的时候6个月学到的东西。

只是因为，我们不知道: 我们不知道。

代码整洁

过去，我有过在不同的场合吐槽别人的代码写得烂。而我写的仅仅是比别人好一点而已——而不是好很多。

然而这是一件很难的事，人们对于同一件事物未来的考虑都是不一样的。同样的代码在相同的情景下，不同的人会有不同的设计模式。同样的代码在不同的情景下，同样的人会有不同的设计模式。在这里，我们没有办法讨论设计模式，也不需要讨论。

我们所需要做的是，确保我们的代码易读、易测试，看上去这样就够了，然而这也是挺复杂的一件事:

1. 确保我们的变量名、函数名是易读的

2. 没有复杂的逻辑判断

3. 没有多层嵌套

4. 减少复杂函数的出现

然后，你要去测试它。这样你就知道需要什么，实际上要做到这些也不是一些难事。

只是首先，我们要知道我们要自己需要这些。

别人的代码很烂?

什么是很烂的代码? 应该会有几种境界吧。

1. 不能工作，不能读懂

2. 不能工作，能读懂

3. 能工作，很难读懂

4. 能工作，能读懂，但是没有意图

5. 能工作，能理解意图，但是读不懂

如果我们能读懂，能理解意图，那么我们还说他烂，可能是因为他并不整洁。这就回到了上面的问题，模式是一种因人而异的东西。

我们在做Code Review的时候，总会尝试问对方说： “这样做的意图是”。

对于代码来说也是如此，如果我们能理解意图的话，那么我们要理解代码相对也比较容易。如果对方是没有意图，那么代码是没救的。

自我救赎

于是，回到开始的地方，现在的我还是只能写出整洁的代码。