码迷,mamicode.com
首页 > 其他好文 > 详细

对代码的理解

时间:2016-05-19 16:26:49      阅读:115      评论:0      收藏:0      [点我收藏+]

标签:

  这篇文章无关技术,只是从事工具开发来的一些总结,因为之前的工作是开发工具对代码进行检查,譬如静态检查和单元测试,很多人的理解不一样,有的人认为这些是必须的,因为可以形成一张网去看护我们的产品,不出事故还好,如果出事故可以快速的定位问题,然而也有人认为,我们的产品能运行,能赚钱就可以啊,为什么要投入更多的工作量来搞一些不赚钱的事情呢,其实这两种都可以理解,只是出发的角度不同,但是我觉得,如果一个公司要长久的发展,就需要稳定的产品来获得客户的信任,所以我支持第一种。本篇文章就是我工作两年来对代码的总结和一些看法(虽然我还是菜鸟,但是菜鸟还是能发表点心情嘛~),我们作为程序猿,当然和代码打交道最多,甚至每天的时间超过了和人的交流时间,所以,善待代码,写出精简漂亮的代码对我们来说是多么的重要。

  简单比复杂好

  随着软件行业的不断发展,历史遗留的程序越来越多,代码的维护成本越来越大,甚至大于开发成本。而新功能的开发又常常依赖于旧代码,阅读旧代码所花费的时间几乎要大于写新功能的代码。我前几天看了一本书,书中有这么一句话:“复杂的代码往往都是新手所写,只有经验老道的高手才能写出简单,富有表现力的代码”此话虽然说的有点夸张,可是也说明了经验的重要性。

  我们所写的代码除了让机器执行外,还需要别人来阅读。所以我们要:
  1.写让别人能读懂的代码
  2.写可扩展的代码
  3.写可测试的代码(代码应该具备可测试性,对没有可测试性的代码写测试,是浪费生命的表现)
  其中2,3点更多强调的是面向对象的设计原则。

     怎样做到简单?有什么原则?

  1、DRY(Don‘t repeat yourself)

  此原则如此重要,简单来说是因为:代码越少,Bug也越少,没有重复逻辑的代码更易于维护,当你修复了一个bug,如果相同的逻辑还出现在另外一个地方,而你没意识到,你有没有觉得自己很冤?

  2、TED原则

  简洁(Terse):简洁的代码让人赏心悦目,就算是读代码也不会给人造成心理负担,如果某天你一看到没有格式、密密麻麻的c代码,我估计你会骂死那个写代码的程序员。
  具有表达力(Expressive):能用最少的代码表达你的意图,那说明你的代码是成功的,程序员就是需要严谨,不兜圈子,直接了当,这才是我们的风格
  只做一件事(Do one thing):专一,如果一个类、一个函数,只做一件事,那么在读代码的时候就不会造成思维混淆,同时可以大大提高工作效率

  3、关于DRY原则

  平时大家重构代码,一个重要的思想就是DRY。我要分享一个DRY的反例:
  项目在架构过程中会有各种各样的MODEL层,例如:DomainModel,ViewModel,DTO。很多时候这几个Model里的字段大部分是相同的,于是有人就会想到DRY原则,干脆直接用一种类型,省得粘贴复制,来回转换。
这个反例失败的根本原因在于:这几种Model职责各不相同,虽然大部分情况下内容会有重复,但是他们担当着各种不同的角色。
考虑这种场景: DomainModel有一个字段DateTime Birthday{get;set;},ViewModel同样具有DateTime Birthday{get;set;}。需求升级:要求界面不再显示生日,只需要显示是否成年。我们只需要在ViewModel中添加一个Bool IsAdult{get{return ....}}即可,DomainModel完全不用变化。

  放手去做,干掉冗余代码

  删除代码会有很多的益处--有些只是对你心情上的影响,而有些是很有实用价值的。

  1、删掉的代码永不崩溃,没有副作用
  删除掉无用的或者冗余的代码,那么与其相伴的枝节问题就不会在未来的某个时刻导致问题了。如果要进行大规模的重构或者是根据某个标准对源码进行排版的话,就无需担心已经删除的那部分代码了:它们已经没了。

  2、删掉代码,也为大脑清除记忆
  项目中的代码数量通常成千上万,不可能都记在脑中。但是看见方法名的时候,我们无需去查阅文档或者源码就可以记起该方法的作用。需要记忆的东西越少,我们的创造性就越高,删掉冗余的或者无用的代码,我们需要记忆或者关心的事情就又减少了一些。

  3、删掉的自动化测试不会失败,而且运行的飞快
  无需为不用的代码进行测试。如果某个组件只是在其测试中才会被调用,删掉它吧。这有助于解决测试中的副作用和无意中的耦合现象。还有,删除鲜有被调用的代码可使得单元测试的覆盖率提高。

  4、在写代码时就审查代码的价值
  如果你已经习惯了删除无用的代码,你会在写代码之前就问自己一句我真的需要这些代码吗?。这样你可以避免写出不是肯定会需要的代码。你还习惯于会去找寻是否已经有代码可以解决手头的问题,以此来避免重新发明轮子。这些都有助于你的项目的可维护性。

  5、它并没有真消失
  大家都在使用源码管理工具。删除掉的代码只是不再挡着你前进的道路,但是它们并没有真的消失了--它们仍然存在于代码管理工具中。你通过删除冗余和混乱获得了清晰明净,但是如果日后发现删除的代码中有闪光点,存在有价值的类和方法的话,你总是可以再把它们找回来的。

 

对代码的理解

标签:

原文地址:http://www.cnblogs.com/ChinaHook/p/5508979.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!