专栏首页北京马哥教育高级Python工程师教你如何正确写代码

高级Python工程师教你如何正确写代码

我接手的第一样东西就是React UI。我们有一个主要组件,它容纳了其他所有组件。我喜欢在代码中加入一点幽默感,我想把它命名为GodComponent。在code review的时候,我才明白为什么命名是一件很难的事情。

计算机科学有两个难点:缓存失效,给变量命名,以及差一错误。

我经手的每一段代码都带有隐喻意。GodComponent?那时用来盛放所有那些我不知道该放到哪里的的烂代码的。它包罗万象。如果我将一个变量命名为LayoutComponent,未来我会知道,它所做的只是规划布局,而不涉及任何状态。

我发现的另一个好处是:如果它看起来太大了,就像包含大量业务逻辑的LayoutComponent一样,我知道是时候重构了,因为业务逻辑不应当属于那部分。而如果使用GodComponent这个名称,那对里面的业务逻辑就不会产生任何影响。

命名你的集群?根据在它上面运行服务来命名是个好主意,可是你以后还可能会在上面运行其他东西。最终,我们是用团队名称来命名的。

对于函数来说也是一样。doEverything()是一个可怕的名字,这会产生很多后果。如果这个函数可以完成所有操作,那么测试这个函数的特定部分就会变得特别难。无论这个函数有多大,你都不会觉得奇怪,因为毕竟这个函数就是要做所有事情的。所以需要换个函数名,重构。

有意义的命名也有不好的一面。如果名称太有意义并隐藏一些歧义怎么办?例如,在SQLAlchemy中调用session.close()时,closing sessions不会关闭基础数据库连接。

在这种情况下,将名称视为x,y,z而不是count(),close(),insertIntoDB()可以防止赋予它们隐含意义——并迫使我仔细检查它们正在做什么。

从来没想到,关于命名我要说的东西居然不能用一句话就概括完。

旧代码和下一个开发者

你有没有看过一些代码并觉得很奇怪?那些开发者为什么这样做?这完全说不通啊。

我有幸曾经使用过遗留代码库。其中有类似这样的注释,“在与穆罕默德一起解决了这个问题以后,注释就删掉了。”你在做什么?谁是穆罕默德?

我可以在这里做一个角色转换——想想以后来接手我代码的人们——他们会不会发现它很奇怪。Peer review 部分解决了这个问题。这让我意识到了环境的重要性:要时刻记得我的团队正在工作的环境是什么样的。

如果我忘记了代码,稍后又看到它,而无法重新回想起当时的环境时,我会说:“到底为什么他们会这样做?这讲不通……哦等等,这是我自己写的。”

这就是文档和代码注释发挥作用的地方了。

文档和代码注释

它们有助于保留环境(上下文,语境),以及分享知识。

正如Li在“如何建立良好的软件”中所说的那样,“软件的主要价值不在于生成的代码,而在于产生它的人所积累的知识。”

“软件的主要价值不在于产生的代码,而在于产生它的人所积累的知识。”——Li

我们有一个面向客户的API终端,似乎没有人使用过。我们只是删除它吗?毕竟,这是技术负债。

如果我告诉你,每年在特定国家/地区,10名记者会将他们的报告发送到该终端,该怎么办?你要如何测试?如果没有文档(现实中确实没有),我们就没办法。所以,我们没有那么做。我们直接删除了该端点。几个月以后那个一年一度的时刻到了。十名记者无法发送10份重要报告,因为终端不再存在了。

拥有关于这个产品的知识的人离开了团队。当然,现在代码中有一些注释解释了端点的用途。

据我所知,文档是一个每个团队都在努力解决的问题。不仅仅是代码文档,还有代码周围的流程。

我们还没有找到一个完美的解决方案。

我很喜欢Antirez对不同类型的有价值的代码注释的详细分类。

原子提交

如果你必须回到之前的步骤(是的你会的。详见测试部分),这个提交作为一个单元是否合适?

在删除烂代码的时候有自信

删除烂代码或过时的代码会使我感到非常不舒服。我认为多年之前被写下的代码是神圣的。我的想法是“当他们写下这些东西时,他们肯定是考虑到一些事情的。”这是传统和文化与第一原则思维方式之间的较量。删除一年一次的终端也是如此。我在这方面得到了太多具体的教训。

我会试着从周围解决代码,而高级工程师则会试着从中间解决。删除所有内容。一个永远不会运行的if语句?一个不应该调用的函数?是的,一切都没了。我?我只会在最上面写下我自己的函数而已。我没有减少技术债务。如果我做了什么的话,我也只是增加了代码复杂性和给他人的误导而已。对下一个人来说把这些代码功能拼凑到一起会更艰难。

我现在使用的启发式是:现在有的代码你无法理解,而且你知道有些代码是你永远也不会用到的。删除那些你永远不会用到的代码,并对那些你不理解的代码保持谨慎的态度。

Code Reviews

Code review是非常棒的学习途径。这是一个外部反馈循环,反映了你现在和将来会怎么写代码。差别在哪里?有一种方式比另一种更好吗?我在每次code review时都会问自己这个问题:“为什么他们那样做?”。每当我找不到合适的答案时,我都会和他们谈谈。

在第一个月之后,我开始在我的队友代码中发现一些错误(就像他们曾经为我做的那样)。这太疯狂了。同行评论对我来说变得更加有趣了——变成了我期待的一场游戏——一场改善我的代码感的游戏。

我的启发是:在我了解代码如何工作之前不要批准代码。

文章转载于马哥教育官网!

原文链接:https://www.magedu.com/84521.html

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 自动化代码发布系统实现

    日常运维问题 在我日常运维工作中,代码发布可能是最普遍的一项工作之一,尤其是网页代码的更新,碎片化发布需求非常频繁。在前期开发人员比较少时,还可以由自己 来上服...

    小小科
  • 代码行数最多的 Python 项目是?

    小小科
  • 基于开源CMDB系统快速实现一棵服务树

    服务树是 CMDB 资源的一种组织方式,通过树形的结构将资源与公司的组织架构结合,可以使开发同学能够清楚的知道自己使用了多少资源

    小小科
  • iOS程序员请改掉影响你升职加薪的36个坏习惯!

    IT行业的科技公司们一直苦苦追寻传说中以一当十的超级程序员,最新的研究表明确实存在这样一小撮效率奇高的“程序金刚”,但是一位普通程序猿如何能够蜕变成代码金刚呢?

    原来是泽镜啊
  • 有了这个神器,贴代码请大佬调试的时候再也不怕被骂这是什么鬼玩意儿啦!

    作为一个不知名的号主,承蒙大家不嫌弃,经常性的会有人非常客气的把一堆代码扔到我的脸上,这些代码千奇百怪,姿态各异,让我喜笑颜开...

    Rocky0429
  • Dead Code为什么能在代码库中永生?

    在一些遗留系统中,经常会看到大片大片灰掉的代码(被注释掉了),这种代码是死代码吗?如果要我下定义,我认为这些不是死代码,因为它们连代码都称不上,如何又能叫死代码...

    袁慎建@ThoughtWorks
  • JS逆向时碰到了恶心的死代码怎么办?手把手教你解决!

    你是否也曾有过「跟着代码跳了很久之后,才发现那一大坨代码其实没有任何作用」的惨痛经历?

    青南
  • JS逆向时碰到了恶心的死代码怎么办?手把手教你解决!

    你是否也曾有过「跟着代码跳了很久之后,才发现那一大坨代码其实没有任何作用」的惨痛经历?

    崔庆才
  • 万物代码化:从低代码、云开发到云研发

    我也是从我的所做、所见、所听中,构建了整个的模型,并非从未来穿越到现在,所以其中的一些设想,可能并非如此准确。

    Phodal
  • 代码能写多少写多少 No.187

    有个朋友说,他十天写了 20000 行代码,当时我的膝盖就直接给它了,怎么会有这么强的选手??!!

    大蕉

扫码关注云+社区

领取腾讯云代金券