设为首页收藏本站

LUPA开源社区

 找回密码
 注册
文章 帖子 博客
LUPA开源社区 首页 业界资讯 技术文摘 查看内容

为什么我看不懂你的代码

2014-12-19 11:18| 发布者: joejoe0332| 查看: 1821| 评论: 0|原作者: labazhou.net|来自: oschina

摘要: 凌晨1:30分,我正盯着不到一个月前我写的一段代码。当时它看起来像是件艺术品,全部是可理解的,优雅、简单、让人叹为观止。这一切都不再了,明 天是我的最后期限,数小时前我发现了一个bug。当时看起来的简单和逻辑 ...

  “我到底在想什么?!?”


  凌晨1:30分,我正盯着不到一个月前我写的一段代码。当时它看起来像是件艺术品,全部是可理解的,优雅、简单、让人叹为观止。这一切都不再了,明 天是我的最后期限,数小时前我发现了一个bug。当时看起来的简单和逻辑再也说不通了。可以肯定的是,如果我写代码,我应该足以聪明到理解代码?



  经过了多次这种经历以后,我开始认真思考,为什么我的代码在我编写的时候很清楚、而当我数周或数月后回头看的时候,它们却那么费解。


问题1,过度复杂的逻辑模型

  为了理解当你间隔一段时间返回到你的代码、却发现代码难以理解的第一步,就是理解我们如何从心智上建立问题模型。你写的几乎所有代码都是尽量解决现实世界的问题。在你写代码之前,你需要理解你正试图解决的问题。这常常是编程里最难的一步。

  为了解决现实世界的问题,我们首先需要形成该问题的心智模型【注1】,以此作为编程意图。接下来你需要形成实现编程意图的方案模型,我们姑且称为语 义模型(semantic model)。从来不要混淆你的编程意图和此意图的方案。我们倾向于主要考虑方案方面的东东,而常常忽略意图的模型。

  你接下来的步骤是形成可能最简单的语义模型。这是容易搞错的第二步。如果你不花时间去真正理解你正试图解决的问题,你将在写代码时被绊倒在模型上。另一方面,如果你真正考虑了你正尽量做的事情,你经常得到一个非常简单的模型,这足以让你掌握最初的意图。

  如果你想容易地维护简单的代码,就尽可能多些地消除意外的复杂性。我们正试图解决的问题是足够复杂的。如果你不必那么做,就不要把意外的复杂性增加进来。


问题2,笨拙的把思想转化成代码

  一旦你尽全力形成了最好的语义模型,那么就到了把它转化为代码的时候了。我们称之为句法模型(syntactic model)。你正试图把你的语义模型的意义转化为计算机能够理解的句法。

  如果你有非常不错的语义模型、而在转化为代码时搞砸了,那么在你需要在以后某个阶段回头修改代码时,你将比较痛苦。当你脑子里还有语义模型时,把你 代码映射到语义模型是容易的。回忆起变量“x”实际上代表一条记录被创建的日期、而“y”代码记录被删除的日期,这是不难的。当你3个月后再回来看代码, 你的脑子里将没有这个语义模型了,因此无法理解同样的变量名字。

  把语义模型转化为句法的任务就是尽量多地留下线索,让你在今后返回时,能够重建当初的语义模型。

  好了,你该怎么做呢?


类结构和命名

  如果你在使用面向对象语义,请尽量让你的类结构和命名靠近语义模型。领域驱动设计(Domain Driven Design)【注2】是在这种练习上投入了相当重要性的一种运动。即使你没有相信完全的DDD方法,你也应当非常小心地考虑类结构和命名。每个类都是你 留给自己和其他人的线索,它帮助你在将来返回的时候重建你的心智模型。


变量、参数和方法命名

  尽量避免普通的变量和方法命名。不要把方法命名为“Process”,因为“PaySalesCommision”更有意义。不要把变量命名为 “x”,因为它应当是“currentContract”。不要把参数命名为“input”,因为“outstandingInvoices“更好。


单一功能原则(Single responsibility principle,简称SRP)

  SRP【注3】是面对对象设计原则的核心之一,关联着好的类和变量命名。它认为,任何类或方法都应该完成一个单一的功能,只能是一个单一的功能。如 果你想为类和方法给出有意义的名字,那么它们需要有一个唯一的较好定义的目的。如果一个单一类从数据库读和写、计算营业税、通知交易客户并生成账单,那么 你就可能无法给出合适的名字。我常常停留在重构类上,因为我总是努力取一个足够短的名字,以描述它做的每个功能。为了更多地讨论SRP和其它面向对象原 则,可以参考我的博文《面向对象设计》。


适当的注释

  如果因为某种原因,你不能让代码变得清晰,你同情将来的自己,需要不得不做些事情,那就留下注释来说明你为什么不得不那样做。注释倾向于快速地变得陈旧,因此我宁愿尽可能让代码自描述,注释用来说明为什么你不得不那样做,而不是它如何做。


问题3,没有足够的组块

  心理学上的组块被定义是,把信息组块定位为单一的实体。那么这该如何应用到编程上呢?作为一名开发者,在你积累经验时,你开始发现你解决方案里反复 出现的模式。极具影响的设计模式:《可重用的面向对象软件》是第一本整理和解释一些模式的书。尽管如此,组块不仅仅用在设计模式和面向对象。在函数式编程 (FP)里,存在大量的著名标准函数具备这同样的目的。算法是组块的另一种形式(后续会更多)。

  当你合理地使用组块(设计模式、算法和标准函数)时,它让你停下来思考,你编写的代码是如何运行的、而不是考虑它做了什么。这缩短了你的语义模型(你的代码)和句法模型(你脑子里的模型)的距离。这个距离越短,你就越容易重建你的心智模型。

  如果你有兴趣了解更多FP里的函数,请移步到我的文章面向web开发者的函数式编程



酷毙

雷人

鲜花

鸡蛋

漂亮
  • 快毕业了,没工作经验,
    找份工作好难啊?
    赶紧去人才芯片公司磨练吧!!

最新评论

关于LUPA|人才芯片工程|人才招聘|LUPA认证|LUPA教育|LUPA开源社区 ( 浙B2-20090187 浙公网安备 33010602006705号   

返回顶部