• 对代码的理解


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

      简单比复杂好

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

      我们所写的代码除了让机器执行外,还需要别人来阅读。所以我们要:
      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、它并没有真消失
      大家都在使用源码管理工具。删除掉的代码只是不再挡着你前进的道路,但是它们并没有真的消失了--它们仍然存在于代码管理工具中。你通过删除冗余和混乱获得了清晰明净,但是如果日后发现删除的代码中有闪光点,存在有价值的类和方法的话,你总是可以再把它们找回来的。

  • 相关阅读:
    HL7及PIX相关的测试工具
    HDU4570----Multi-bit Trie----简单的DP
    hdu2248
    poj 3693 Maximum repetition substring (后缀数组)
    高性能通道
    volyaire重振Infiniband
    利用iWARP/RDMA解决以太网高延迟
    linux 单网卡来绑定多IP实现多网段访问以及多网卡绑定单IP实现负载均衡
    C细节学习
    每2秒获取系统的赋值及内存使用率
  • 原文地址:https://www.cnblogs.com/ChinaHook/p/5508979.html
走看看 - 开发者的网上家园