我从资深软件工程师学到的避坑大法

过去一年中,我坐在一位资深的软件工程师旁边,可以仔细地观察他是怎么工作的。我们两人经常共同编程,使得这项观察更为容易。此外,在团队文化中,从背后窥探写代码的人并不令人反感。以下是我所学到的:

 

编写代码

 

如何命名

 

我首先着手的是 React UI。我们有一个主要组件来放置其他所有的组件。我喜欢在代码里加点幽默感,因此我想要将它命名为 GodComponent。当进入代码审查环境的时候,我才明白为什么命名这么难。

 

 
在计算机科学里有两个难题:内存不足、命名、以及差一(off-by-one)错误。
——Leon Bambrick
 

 

我每个命名的代码段都有隐藏含义在里面。GodComponent 是所有我不必费心去寻找合适位置来存放那些垃圾的地方,它可以容纳所有东西。如果我早早把它命名为 LayoutComponent,之后的我就会发现它所做的就是分配 layout,没有状态。

 

我发现命名好的另一个好处是:如果它看起来太长了,就像 LayoutComponent 包含了很多业务逻辑层,我就知道是时候要重构了,因为业务逻辑层并不属于这里。如果是以 GodComponent 命名,这里的业务逻辑层也不会和其他有所区别。

 

命名你的集群?以在服务器上运行的服务名称来命名更好,直到用它们来运行其他服务为止。我们最终以团队的名字来命名服务器。

 

在函数上也是同样的道理。doEverything() 是一个糟糕的名字,会有很多难以预料的后果。如果这个函数能够做所有事情,那么在测试函数某个特定部分时将变得非常困难。因为不管这个函数有多大,你都不会觉得奇怪,毕竟这个函数应该做所有的事情。这时候就需要改名、重构了。

 

有意义的命名也有不太好的一面。如果名字的表意太强,结果掩盖了一些功能上的细微差别怎么办?例如:当你在 SQLAlchemy 中调用 session.close() 时,这只会关闭会话但不会关闭底层数据库的连接。

 

在这种情况下,可以以 x,y,z 来命名而不是 count(),close(),insertIntoDB(),这样可防止为其赋予隐性含义并强制开发人员仔细检查它所执行的操作。
 
历史代码和下一名开发者
 
你曾否看过一些代码,觉得它们很奇怪?这些代码为什么这么做呢?它们的实现一点都不合理。
 
我曾负责过遗留代码库。代码中有诸如「当 Mohammad 发现情况时取消注释代码」这类的注释。这是在做什么?谁是 Mohammad?
 
在这里可以做下角色转换——想象下一个人来看我的代码,他们是否会觉得奇怪?

 

同行审查可以某种程度上解决代码注释这个问题。这让我想到了上下文的概念:注意我团队正处的上下文位置。

 

如果我忘记了这部分代码,之后又回到了代码工作上,没有注释的话我不能重新创建上下文,我可能只会想:「为什么他们要这么写?这没有任何意义……哦,等等,是我写的。

 

这里就是开发文档和注释该出现的地方。

 

文档和注释
 
文档和注释有助于维护上下文和分享知识。
 
正如李在《如何构建好软件》中所说,「软件的主要价值不是编写它的代码,而是编写它的人所积累的知识。

 

比如说,我们有个似乎没有人用过的、面向随机客户端的 API 终端。因为这些原因,我就应该把它删除吗?毕竟这是一个技术累赘。
 
如果说,在某个特定国家,有 10 名记者会一年一次将他们的报道发送到这个终端,怎么办?你如何测试它?如果没有开发文档(那时就没有)就不能测试。所以我们没有测试。我们删除了那个终端。过了几个月后,到了一年中发送的时间,因为这个终端已经不存在了,10 名记者也就无法发送这 10 份重要报告。
 
虽然熟悉产品的人已经离开了团队,但是现在代码中有注释解释终端的作用。
 
据我所知,文档是每个团队都在努力的东西。不仅仅是代码的文档,还有关于代码的流程。
 
自信地删掉垃圾代码

 

我过去很不喜欢删除垃圾代码或过时的代码。我认为过去写的代码都是神圣的。我的想法是:「他们写这些代码的时候肯定有一些想法。」这是传统和文化与第一性原则之间的碰撞,与删除一年一次的终端发生的事相同。我在那里学到了详细的一课。
 
我尝试基于已有代码进行工作,但是资深工程师会尝试解决掉它——全部删除。一个永远无法到达的 if 声明?一个不应该调用的函数?是的,都消失了。

 

至于我呢?我只会把我的函数写在最上面。我没有减少这些技术累赘,反而增加了代码的复杂程度,以及误导别人的可能。下一个人将事情拼凑起来会更困难。

 

现在我受到的启发是:有一些代码你可能不理解,也有一些代码你知道永远不会用。删除那些你永远都不会用的代码,小心那些你不理解的代码。
 

 

代码审查
 
代码审查对学习来说非常有用。这是你写代码和其他人写代码时进行的外部反馈循环。
 
两种实现有什么区别呢?一种方法比另一种好吗?每次代码审查时我都问自己:「他们为什么这样做?「。每当我找不到合适的答案时,我就会去和他们谈谈。
 
在第一个月后,我开始在同事的代码中找到错误(就像他们对我代码做的一样)。同行审查对我来说变得更有趣了——这是我期待的游戏——一个提高我代码意识的游戏。
 
我的启发是:在理解代码如何实现前不要批准它。

内容版权声明:除非注明,否则皆为本站原创文章。

转载注明出处:http://www.wuliaoxiuxian8.com//news/80.html