这篇文章无关技术，只是从事工具开发来的一些总结，因为之前的工作是开发工具对代码进行检查，譬如静态检查和单元测试，很多人的理解不一样，有的人认为这些是必须的，因为可以形成一张网去看护我们的产品，不出事故还好，如果出事故可以快速的定位问题，然而也有人认为，我们的产品能运行，能赚钱就可以啊，为什么要投入更多的工作量来搞一些不赚钱的事情呢，其实这两种都可以理解，只是出发的角度不同，但是我觉得，如果一个公司要长久的发展，就需要稳定的产品来获得客户的信任，所以我支持第一种。本篇文章就是我工作两年来对代码的总结和一些看法（虽然我还是菜鸟，但是菜鸟还是能发表点心情嘛~），我们作为程序猿，当然和代码打交道最多，甚至每天的时间超过了和人的交流时间，所以，善待代码，写出精简漂亮的代码对我们来说是多么的重要。
简单比复杂好
随着软件行业的不断发展，历史遗留的程序越来越多，代码的维护成本越来越大，甚至大于开发成本。而新功能的开发又常常依赖于旧代码，阅读旧代码所花费的时间几乎要大于写新功能的代码。我前几天看了一本书，书中有这么一句话：“复杂的代码往往都是新手所写，只有经验老道的高手才能写出简单，富有表现力的代码”此话虽然说的有点夸张，可是也说明了经验的重要性。
我们所写的代码除了让机器执行外，还需要别人来阅读。所以我们要：
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、它并没有真消失
大家都在使用源码管理工具。删除掉的代码只是不再挡着你前进的道路，但是它们并没有真的消失了--它们仍然存在于代码管理工具中。你通过删除冗余和混乱获得了清晰明净，但是如果日后发现删除的代码中有闪光点，存在有价值的类和方法的话，你总是可以再把它们找回来的。