Blog

Blog

PHODAL

五个基本原则,让新手写出 “整洁代码”

每个人都有自己对于代码的看法,有自己的偏好。对于我来说,也是如此。作为一个实用主义者,我遵循的东西,比较少,也比较简单。多了,记不住,也不实用。

避免预先设计的代码

架构往往得预先设计的,而代码容易被过度设计。而事先设计的架构,往往在落地的时候,会遇到一系列的挑战。等到软件交付时,则会变成新的架构,或者该架构的变体。代码,则也是类似的。

日常工作中,我们经常遇到的情况,到底有没有必要提前编写一些代码——这些功能往往是,我们根据以往经验,猜测未来会有的功能?不事先编写,那么后期修改就比较麻烦。事先编写的代码,不符合需求,那么后期还是得重写。只有运气刚刚好,我们才能编写出符合需要的代码。然而,多数时候,我们写的这些代码往往是用不上的。

一旦代码中有大量多余的代码,代码看上去就没那么整洁了。若非要在两者做一个平衡,便是多做一点点,如先把接口准备好,但是不实现相应的功能。

IDE 重构 vs 手工重构

整洁的代码,意味着不重复,而每个人对于重复的定义是不一样的。对于我来说,则是:事不过三,过三则重构。耦合和参数,会带来新的复杂度。重构,不是一件容易的事,也不是一件太困难的事。

手工重构代码,意味着风险。如果没有测试,直接对代码进行重构,那么就会生不如死。

IDE 重构代码,则是依赖于 IDE 自带的功能,以通过机器的方式来重构代码。与手工方式相比,它更加的可靠,并且风险相当的低。前提是,该语言有对应的 IDE 可以提供这个功能,如 WebStrom、Intellij IDEA 等。

短、平的函数

编写函数的时候,要注意长度要短~、一个函数完成一件事,并且避免多级嵌套

长的函数,阅读体验不好。多层嵌套的函数,复杂度过高。

采用各种 Lint 来限制函数的长度、层嵌套的数量,是一种颇为有效的降低复杂度的方式。

适当的设计模式与原则

设计模式和各种原则是好东西,它们可以方便我们与其他/她开发人员进行交流。当你遇到一个一对多的问题,别人一说,”你这个东西用观察者模式来实现”,那么问题就这么解决了。

设计模式,是一系列对于相关问题的解决方案。缺少编程经验的时候,学习设计模式,是一个不错的提升方式。而问题的关键,在于如何在适当的时候使用它们。在这个过程中,我们经历这么一些情况:

  1. 不知道设计模式
  2. 拿着设计模式的锤子(定律),到处使用
  3. 对设计模式反感,会避免使用
  4. 自然而然的使用设计模式

编程语言在解决问题上是相通的,哪怕是不同范式的设计语言,要解决的问题是一样的,采用的设计模式也就类似。

命名而非注释

命名,对于程序员来说,是一个难题。

一个好的变量名、函数名,远远比一行行注释,更重要——代码是写给人看的。

阅读遗留系统代码的时候,最怕的不是又长又深的代码,而是代码中有个 42 这种魔法数字(magic number),又没有对应的注释。那怕得打出几个电话、发几十条信息,才能知道这该死的 42 到底是什么。

哪怕是使用错误的单词,将 42 赋予这个变量,如 var ratio=42,也远比 42 + 对应的注释拥有更好的可读性。特别是,如果到处是这个 42 的变量,只会使得到处都是相关的注释。同样的,这个问题,也出现在对于函数的命名上。好在我们对于函数的命名,会略微重视一些。

结论

你还有哪些奇技淫巧呢?

关于我

Github: @phodal     微博:@phodal     知乎:@phodal    

微信公众号(Phodal)

围观我的Github Idea墙, 也许,你会遇到心仪的项目

QQ技术交流群: 321689806
comment

Feeds

RSS / Atom

最近文章

关于作者

Phodal Huang

Engineer, Consultant, Writer, Designer

ThoughtWorks 技术专家

工程师 / 咨询师 / 作家 / 设计学徒

开源深度爱好者

出版有《前端架构:从入门到微前端》、《自己动手设计物联网》、《全栈应用开发:精益实践》

联系我: h@phodal.com

微信公众号: 最新技术分享

标签