ReThought(三): 说说代码

1,535 阅读4分钟

ReThought(三): 说说代码

Posted by: Phodal Huang 12 hours, 59 minutes ago

众所周知在我们公司的面试流程比较复杂——其中有一个是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的时候,总会尝试问对方说: “这样做的意图是”。

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

自我救赎

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