架构设计
遵循“先设计后开发”的原则，设计高于开发
设计时应确定好时序图、UML关系图
设计时应将需求、场景抽象成模型（建模），并将模型拆分成模块，形成架构
模型应考虑并兼容后续需求的迭代开发，应减少架构的修改
模块之间应减少依赖关系，并尽量以接口的方式形成依赖
设计时应考虑测试用例，“测试驱动开发”，以测试用例来检验功能开发的完成。
类的设计
职责单一，每个类应集中处理某个方面的事务
短小精悍，每个类的代码行数应该控制在1000行代码以内，提高可读性
封装性，应尽量减少对外暴露。非必要暴露的方法不要暴露。非数据类的成员变量不能直接对外暴露，而要提供公共的方法。
功能类应尽量实现于接口
因某种特征导致多个函数的实现发生变化，应考虑将这个特征以继承的关系进行表现，不同的特征，不同的子类
为了提高阅读性，类中代码的顺序上应该类型、功能进行排列，即按先变量后函数。变量的顺序，应按公有、私有、静态、类型排序。函数的顺序应按照构造函数、功能进行排序。
类名应表现出类的功能。
函数的设计
职责单一，一个函数集中处理一个功能。
短小精悍，每个函数保持在100行以内，函数过长是应将相应的功能抽出来。
简化输入输出，每个函数的参数应控制在3个以内，尽量保持在一到两个。多出来的参数，应该尽量集中成为成员变量。
逻辑紧凑，环环相扣。在最合适的位置做判断，跳转，减少代码的无用的执行。
方法名、变量名应有意义并表现功能
减少嵌套，函数内部的嵌套不应超过三层。可通过将嵌套抽成方法，跳转到另外一个新的函数并终止本函数，提前返回的方式减少嵌套。
优化复杂的逻辑判断，应将复杂的逻辑判断抽成新的方法。
代码中不能出现重复的代码，重复的代码要进行整合，可以通过合并成基类的逻辑或方法，抽成工具类中的方法实现。
Log的设计
Log的设计的重要性等同于正常代码。
Log不能暴露用户的个人信息。
应在方法的入口处反应决定方法结果的信息，包括参数信息，和重要内部成员变量的信息。
Log的长度不能过长，内部的内容应该尽量简写，并包括尽量的多的信息。避免在循环内部添加Log。
Log的设计应保证任何代码执行过程有迹可循。
竞态关系的设计（多线程的设计）
以下为功能类的设计：
应尽量减少功能类的成员变量。
容器类型的成员变量应该设置为私有，不能超过保护类型。外部的访问应该要通过特有的方法访问，特有的方法应该同步。获取容器内容应该通过拷贝的形式。
内部方法使用成员变量，不应该直接使用，而应该再用方法内部的变量保存成员变量的句柄或者值。以保证方法执行过程中句柄或者值的一致性。
应该减少锁的粒度，以减少死锁的可能以及其它线程可能等待的时间。
对于访问频繁的锁，应考虑将读锁和写锁拆分。