这篇文章是对自己从业几年来关于写代码的一些总结与思考，没有普适性，如有不同意见欢迎交流。
0x00 代码规范
提到怎么写代码，必须要说的问题就是命名规范。代码规范有以下好处：
- 规范的代码可以促进团队合作
- 规范的代码可以减少bug处理
- 规范的代码可以降低维护成本
上面这些好处都是老生常谈了。作为程序员接手别人的代码是很经常的，此处我有几个建议：
- 尽量按照代码原来的风格规范进行开发。
- 如果老代码风格杂乱无章。此时我们应该是看到一处改一处逐渐使代码风格规范起来。
- 如果老代码有几处不符合规范，但是在本项目代码中风格是统一的，此处我的建议是按照老代码的风格继续编写。
- 尽量少改原来的代码，在新需求产生的时候我们应该是新建一个类，在自己的新类完成功能，然后再合适的位置插入，对于老代码尽量少动。（可能有人要反驳，但是在不能完全理解程序的情况下尽量少改代码是比较安全的维护方式。）
0x01 软件设计
做为一个程序员我们此处只讨论程序的设计以及走向，不讨论功能设计方面。
- 避免过度设计。在大功能大模块划分好之后尽量避免对一些小功能在划分模块，避免模块过多带来更多的维护成本。
- 模块与模块之间的数据交互尽量直接用
字符串，字节，JSON串传输。不要自己定义不必要的协议。 - 防止过早抽象，避免没有实际效果的抽象。
此处引用王垠大神的文章来表述：
奉行DRY原则的人还有一个问题，就是他们随时都在试图发现“将来可能重用”的代码，而不是等到真的出现重复的时候再去做>抽象。很多时候他们提取出一个貌似“经典模板”，结果最后过了几个月发现，这个模板在所有代码里其实只用过一次。这就是>因为他们过早的进行了抽象。 抽象的思想，关键在于“发现两个东西是一样的”。然而很多时候，你开头觉得两个东西是一回事，结果最后发现，它们其实只 是肤浅的相似，而本质完全不同。同一个int a，其实可以表示很多种风马牛不及的性质。你看到都是int a就提出来做个父类，其实反而让程序的概念变得混乱。还有的时候，有些东西开头貌似同类，后来你增添了新的逻辑之后，发现它们的用途开始特殊化，后来就分道扬镳了。过早的提取模板，反而捆住了你的手脚，使得你为了所谓“一致性”而重复一些没用的东西。这样>的一致性，其实还不如针对每种情况分别做特殊处理。 防止过早抽象的方法其实很简单，它的名字叫做“等待”。其实就算你不重用代码，真的不会死人的。时间能够告诉你一切。如果你发现自己仿佛正在重复以前写过代码，请先不要停下来，请坚持把这段重复的代码写完。如果你不把它写出来，你是不可能准确的发现重复的代码的，因为它们很有可能到最后其实是不一样的。 你还应该避免没有实际效果的抽象。如果代码才重复了两次，你就开始提取模板，也许到最后你会发现，这个模板总共也就只用了两次！只重复了两次的代码，大部分时候是不值得为它提取模板的。因为模板本身也是代码，而且抽象思考本身是需要一定代价的。所以最后总的开销，也许还不如就让那两段重复的代码待在里面。 这就是为什么我喜欢一种懒懒的，笨笨的感觉。因为我懒，所以我不会过早的思考代码的重用。我会等到事实证明重用一定会带来好处的时候，才会开始提取模板，进行抽象。经验告诉我，每一次积极地寻找抽象，最后的结果都是制造一些不必要的模板，搞得自己的代码自己都看不懂。很多人过度强调DRY，强调代码的“重用”，随时随地想着抽象，结果被这些抽象搅混了头脑，bug百出，寸步难行。如果你不能写出“可用”（usable）的代码，又何谈“可重用”（reusable）的代码呢？
- 软件应该以版本为基准进行推进。不要因为一个小BUG而推迟版本发布，在不影响大体功能的前提下按计划发布版本。
- 面向接口编程。对于可能发生改变的需求尽量使用接口化编程，这样在后面需求改变的时候就能容易的进行需求变更。
写代码时的铁律
写尽量少的代码
写代码应该尽量少写代码，代码越少犯错越少。所以在写的过程中不停的琢磨提炼代码是很有必要的，尽量避免写那种又臭又长的垃圾代码，只留下必须的代码。
尽量避免造轮子
开源如火如荼的发展至今，已经有很多前人给我们造好轮子了，很多轮子不需要我们造了。我们在平时应该注重积累一些常用的库这样代码才会越写越顺。