注意代码的规范和可读性

命名

N1:采用描述性名称.命名要具备描述性.

N2:名称应与抽象层级相符.

    public interface Modem {

      boolean dial(String phoneNumber);//应修改为 boolean connect(String phoneNumber);

      boolean disconnect();

      boolean send(char c);

      char recv();

      String getConnectedPhoneNumber();

    }

N3:尽可能使用标准命名法

N4:无歧义的名称.

N5:为较大作用范围选用较长名称.名称的长度应与作用范围的广泛度相关.

N6:避免编码. 不应该在名称中包括类型或者作用范围信息.

N7:名称应说明副作用. 应该说明函数,变量或类的一切信息.

注释

C1:不恰当的信息.

C2:废弃的注释. 过时,无关或者不正确的注释就是废弃的注释.

C3:冗余注释. 如果注释描述的是你某种充分自我描述了的东西,那么注释就是多余的.

C4:糟糕的注释.注释要精准,简洁

C5:注释掉的代码. 全部删掉!

环境

E1: 代码BUILD需要多少部.标准是签出代码,就可用单个指令构建它.

   svn get mySystem

   cd mySystem

   ant all

E2: 单个指令可运行全部的单元测试.

函数

F1: 过多的参数. 函数的参数量应该少. 没参数最好,一个次之,依次类推.

F2: 少用输出参数

F3: 标示参数.

F4: 不被调用的函数. 直接删除,保留代码的整洁.

一般性问题

G1: 一个源文件中存在多种语言. 理想的源文件包括且只包含一种语言.

G2: 明显的行为未被实现. 函数或者类应该实现其他程序员有理由期待的行为.

G3: 不正确的边界行为. 单元测试需要追索每个边界条件.

G4: 忽略安全. 不要忽略编译告警.

G5: 重复. 牢记DRY原则(Don't Repeat Yourself). 发现重复代码就表示遗留了抽象.,

G6: 在错误的抽象层级上的代码. 良好的软件设计要求分离位于不同层级的概念,将它们放到不同的容器.

G7: 基类依赖于派生类. 基类不应该依赖派生类. 比如部署的时候基类和派生类分属不同的jar,基类的jar文件对派生类的jar文件的内容一无所知,才能分散和独立的部署组件.

G8: 信息过多. 设计良好的模块有非常小的接口. 要限制类或模块中暴露的接口数量.类中的方法越少越好.函数知道的变量越少越好.

G9: 死代码. 未调用的代码尽早删除.

G10: 垂直分割. 变量和函数应该在靠近被使用的地方定义.

G11:前后不一致. 命名所代表的行为和意义要统一.

G12: 混淆视听. 删除未实现,未使用,无意义代码,保持代码整洁.

G13: 人为耦合

G14: 特性依赖.类的方法只应该对其所属类的变量和函数感兴趣,不该垂青其他类中的变量和函数.

G15: 选择算子参数.

G16: 隐晦的意图. 代码尽可能具有表达力.

G17: 位置错误的权责. 最小惊异原则.

G18: 不恰当的静态方法. ??

G19:使用解释性变量. ??

G20: 函数名称应该表达其行为.

G21:理解算法.

G22:把逻辑依赖改为物理依赖.

G23:用多台替代IF/ELSE或Switch/Case

G24:遵循标准约定. 每个团队都应遵循基于通用行业规范的一套编码标准.

G25:禁用魔法数. 用命名常量代替.

G26:准确 代码中的函数和不准确都是源于懒惰,都要清除

G27:结构甚于约定. 用到良好命名的枚举的switch/case要弱于拥有抽象方法的基类.

G28:封装条件.

G29:避免否定性条件.

G30:函数只该做一件事.

G31:时序耦合. 不要隐藏时序耦合.

G32:别随意.

G33:封装边界条件. 边界条件难以追踪.

G34;函数应该只在一个抽象层级上.

G35:在较高层级放置可配置数据

G36:避免传递浏览,

JAVA

J1:使用通配符避免过长的导入清单.

J2:不要继承常量.

J3: 枚举 vs 常量 .用枚举消除魔法数.

测试

T1: 测试不足

T2: 使用覆盖率工具

T3: 别略过小测试.

T4: 被忽略的测试就是对不确定事物的疑问.

T5: 测试边界条件

T6:全面测试相近的缺陷. 缺陷趋向扎堆.在讴歌函数发现一个却显示,最好全面测试那个函数.

T7: 测试失败的模式有启发性

T8: 测试覆盖率的模式有启发性

T9; 测试应该快速

如何技术选型

没有准确估计实际业务量或者说就没有估计过，导致技术选型直接参考京东、淘宝一线大公司，实现复杂，技术铺的也很大。（选型的目标是能够快速实现产品的迭代，技术够用就好）

因为缺少经验，前期业务没有明确的规划，技术选型也没有考虑高内聚、低耦合，导致系统之间依赖太强，导致现在想拆分很难。

选择了一些较新的技术框架，过于依赖几位关键的技术牛人，结果这些人一旦离职，就陷入迷茫。（框架选择要谨慎，如果选择高逼格的技术框架，需要留住核心人员，或者有备份人选）

eclipse设置

字体

普通列表项目eclipse字体推荐，专为程序员设计的字体，Source Code Pro

插件

eclipse改代码区颜色,​代码大小字体及窗口主题  eclipse改代码区颜色,​代码大小字体及窗口主题

安装地址：  http://​eclipse-color-theme.github.com/​update/ ​