看了neora的大作写给我的团队 ，颇受启发，在这里我借花献佛，也写一些短文给团队的新老成员做些总结。照搬的地方neora老大表骂我
各位尊敬的同事
你们好！我知道大家都很忙，忙的连写注释和文档的时间都没有，更不要说做总结了。所以我就写一些短文，帮助大家总结一下。正如大家所知道的，我们的团队每天所面对的问题有很多——需求、测试、编码、变更、架构 ……
为什么要编码？
软件就是把人们的需要转化为计算机可以执行的程序。
这一点毫无疑问，但是这就是我们编码的目的吗？我们都知道，计算机其实很笨，它只能认识 0 和 1 这两个数字，无论多么复杂的程序都是由这两个最简单的数字构成。这正如哥德巴赫猜想，作为最复杂的数学证明题，要求解决的却是最简单的 1+1 问题。也就是说，最直接的编程就是向计算机输入 0 或者 1
原因当然很简单，因为 0 和 1
所以，我们编写代码的目的就是为了交流和沟通，而这，也正是计算机语言存在的意义。
考虑别人
既 然编写代码的目的是为了沟通，那么作为一个程序员有什么理由去写那些只有自己才能够看懂的代码呢。如果吧这个作为一个问题问大家，恐怕没有一个人会这样回 答：“编写只有自己能看懂的代码，让别人去猜吧！”。因为大家都希望合作，都愿意与其他人沟通，这不仅仅是工作的需要也是人类的基本需要之一。
可是，并不是每一个程序员都懂得沟通的艺术。几年前，我认识了一个很有天分的程序员，他的编程能力让人吃惊。但是，当他把一个命名为“ tj
那么怎样才能编写一份能够阅读并易于理解的代码呢？下面我给出一些建议，其中的一些已经作为我们团队《编程规范》的一部分而被大家了解了，而另一些则不然。
必须认真的慎重的为你的变量、函数（方法）、类命名。要起一个科学合理的名字，因为名字是理解代码的重要依据。同时，一旦代码发布，其依赖者、继承者都要永远维持这种命名。想像一下，如果你和你的同事不得不使用类似“ tj
● 为你的代码编写注释。注释是代码的重要组成部分，同时也是别人理解你代码的重要依据，无论任务多么繁重，时间多么紧张，都应该象对待代码一样对待你的注释。哦，还有，最重要的是维护你的代码的同时要维护注释，就像下面一条所说的：
● 请确保注释是有效的。无效的，甚至是错误的注释还不如不写注释，这是显而易见的。注释应该言简意赅，不要用注释重复你的代码，也不要用注释阐述代码中显而易见的逻辑。请原谅我的啰嗦——在维护代码的同时不要忘记维护注释。
1) 过度的使用了设计模式。
2) 拼凑结果。
例如，某个复杂的函数返回的值总是比预期结果少 1 ，有些程序员会采用 +1
3) 过度封装。
4) 拒绝使用成熟的第三方类库。
许多初级设计人员，往往喜欢自己编写框架级别的代码，例如，在 JavaEE 开发中自行设计 MVC
5) 冒然采用新的技术。
程序员是思维活跃敢于尝试创新的人群，他们往往乐于使用新的技术和新的产品。但是，在使用这些产品之前请仔细考虑：“你了解它吗 ? ”。冒然在团队中应用新技术是一种非常不负责任的行为，学习曲线、隐藏 BUG
消除重复
如果说软件目的就是将需求转换为程序，那么软件的本质就是复用。复用是一个非常宽泛概念，微软将 Windows 操作系统刻录成光盘出售，用户买到的都是同样的程序，这就是复用；我们使用 163 或者 google 的 Email 服务，访问同样的 Web 网站，这，也是复用。一个程序、一个 URL
接口为我们的应用提供很好的“可替换性”，简单的说，使用者仅依赖接口，而不必考虑接口 是如何实现的，这样，一旦发生变化只需要重新实现接口，而依赖于接口的代码不必改动。显然，接口是非常强大的，它使得我们的代码具有扩展性，但是，是否所 有的模块都需要这种扩展性呢？实践证明， 80%
1） 两个并行开发的模块（或类、子系统），互相存在依赖关系。
例如， A 模块依赖 B 模块的某些功能，因为是并行开发的，所以 B 模块可能还没有完成，这个时候，需要 B 模块提供接口以供 A 模块使用。 A 模块开发的时候，可以先使用一个 B 模块接口的“模拟实现”，等到 B
2） 对于结构复杂的或提供公共服务的模块。
有时候，需要提供一些公共的服务为整个系统使用。例如，在 Java 中直接使用 JDBC 操作数据库往往比较繁琐，这个使用需要提供一个通用的 JDBC 封装，将重复繁琐的 JDBC 操作提取到抽象类或者工具类中。但是， JDBC
3） 当模块的可变性是可以预见的时候。
如果开发人员预见到：“这个模块将来一定会发生某种变化”，那么此时可以使用接口。这种 情况下，接口的粒度一定要细，仅仅包含变化的功能即可。例如，一组结构相同的数据，需要我们对其中一些特殊的数据进行处理，而原始数据中并没有提供某种规 律来辨别哪些数据是特殊的，此时，我们只好通过硬编码（ Hard Code ）来处理这些特殊数据（例如，通过名称来判断）。这显然是代码中的坏味道，解决的办法就是提供一个用于判别特殊性的接口，然后用 Hard Code
4）
面向对象的原则告诉我们，聚合复用应该优先于继承复用。但是，当你确定某些类从本质上讲是同一个类别 的时候，就应该考虑将这些类的公共部分提取到抽象类中，以实现代码的复用。经过这种处理的子类比原来要精简很多，甚至比使用了聚合复用还要精简。
● 在复杂的模块中使用设计模式。
大量的条件分支判断会导致代码冗长、结构松散、逻辑混乱，这类代码往往没有可阅读性和可维护性。但是，并非 if-else 就不能使用的了，只要遵循下面的原则， if-else
1)
2) 分支要尽可能少，不要超过 8
3) 每个分支的代码在 3
4)
5)
6) 如果上述 5
Copy-Paste 你的代码。
当你 Copy-Paste 代码的时候，说明代码中存在重复，重复的代码往往导致代码难以维护和阅读。一旦那些保存在剪切板中的代码中存在错误，编写者甚至不知道到哪里修改这些错误。每当你 Copy-Paste
源代码就是文档
我们为什么写设计文档呢？设计文档可以说明你的代码，阐明设计思路，文档是我们沟通的重要工具，它可以使软件具有可持续发展性。这里我只想说说详细设计文档。 几年
现在我已经明白了，所谓概要设计就是架构设计，架构就是将一个软件中功能性的东西剔除之后剩下的部分。这一部分是软件的结构，它说明了软件中最为重要的特性和这些特性的实现方式。
那么详细设计呢？我曾经看到过的详细设计可以细致到伪代码，程序员可以不必动脑筋，直接将伪代码翻译为 Java 或者 C# 代码即可。我对这样的设计人员致以无比的敬意，因为他（们）不但可以为数量远超他们的程序员写代码，更为神奇的是，这些代码可以在没有调试过的情况下正常运行。但是，我想今生我都无法达到这个水平了。而且即使我达到了这个水平，我还要为这些设计文档的维护尤其是文档与代码之间的同步 付出无比艰辛的劳动，与其这样，我不如：
● 简单设计。
Kent Beck 在《解析极限编程——拥抱变化》中为简单设计制定了 4
● 单元测试的文档作用。
测试方面我将另行撰文阐述，这里所说的是单元测试的文档作用。任何一个学习计算机编程的人都知道， 10 行文字说明不如一行代码演示，这体现了“例子”的重要性。单元测试对于维护者而言就是“例子”，当维护者难以理解你的代码，当使用者不知如何使用你写的 API
● 现代编程语言对于文档的支持。
在 Java 、 C# 、 Ruby 等新兴的编程语言中，可以将代码注释当作文档使用。例如 Java 为文档提供了很多支持——使用 HTML 标签、使用 @ 标记等，结合 Javadoc 命令就可以生成 HTML 格式的文档。相比传统的 Word
1）
2）
3）
● 源码之前了无秘密。
当测试、注释、文档都失去作用的时候，不要忘记，我们还有逻辑，还有代码！代码之前了无秘密。优质的代码是说明应用程序的最根本的方式，是程序员沟通的通用语言。
