任何情况下不能吞异常，一般使用logger,哪怕只能用e.print... 也是有补救措施的，而吞掉便无从知晓。
* 配置多资源时，各种公用的内容没有提取，导致修改时非常麻烦，推荐使用include方式
* 子资源要能使用父资源的指标值,也就是父子要有继承关系
* 国际化时不应该再另起一个模型，这样会使同一修改改动很多文件
* 任何会导致特殊字符危险的方案不能用，比如
- 在解析命令时会解析参数 /o ,后来有一个目录叫"/opt/home" ，导致解析不成功，非常隐蔽而且危险
* 打日志时要尽量的全，哪怕是trace，调试时很方便。不需要的可以不配置，需要时不必再次修改代码。
* cc 的文件名长度有限制，非常不便
* 做配置时，某个对象的属性集中一处配置，哪怕是include,不可分散至引用处重复配置,比如现在原型的资源类型的 disporder
* log4j 要做动态加载
* 打日志要规范，利用解析，使用多logger输出
* 队列要集中管理，分配
* 线程要集中管理，分配。无论是线程池还是独立线程的创建。
* 模块化工作的敌人是建一个模块的工程时很麻烦，所以要从架构设计时解决这个问题，因为这个而导致今后结构不清晰，很不值得
* 大数据量的删除操作很慢，约几个小时的时间。所以需要在批量插入的时候判断是否需要删除部分数据
* 用URL返回本地文件路径时，注意URLDecode.decode(path,"UTF-8"); 来转换特殊编码
* 真实环境的压力测试(尤其是异常测试)很重要，未经此测试不要出售，会带来很大的维护压力
* socket 连接重试一定要有间歇，不然会把服务器搞宕
* 用到线程时，线程要继承一处，并作统一创建和管理，以便于在内部设置路标。并且在线程内要及时写入路标。设置路标时，参数以map形式添加，读取时再格式化成字符串。
* 对于多线程程序，线程池分配时，分配策略要可配置以调节性能
* 2008-6-13 06:34下午 今天开发时，A改过的东西 我们B不知道，他在本地修改因为版本已经冻结，导致严重问题复现。今后采用为某个现场环境建立一个hotfix版，在这个版本上记录更改历史
* 给现场安装不知该分配多大内存时，要有一个自动修正功能，设置内存在一个范围内递增。捕获oom 异常，让监控线程关闭系统并修改内存配置重启。但是前提是要保证数据的完整性受损是可接受，或者有解决方案的。
* 当一个小组成员分头支持现场问题时，每个人解决问题后要全体知悉，便于积累经验和对外表达一致
* Joel曾经说过：不要先去完成界面，因为在很多用户看来，完成了界面，就等于功能也快完成了。而要让功能和界面的开发保持同步最好。
* 开发软件不能只顾自己开发时方便,还要考虑到运行维护时是否方便
* 模块依赖api时，此模块要把自己需要的api整理为一套adapter去适配，便于整理出对api方法的依赖，另外在api强行变动时，其他应用也有应急办法
* 留下足够的程序内部信息的监控入口，生产环境是不让动的,xstream
* OOM, StackOverflow, JMX高负载后停止服务
* 系统中用到的环境变量名要集中使用常量管理
* io 远程调用传输过程中，尽量合并携带参数 ，减小传输量。不要使用zip。
* 线程要提供一个暂停的方法，以便调试
* 使用需要持久华的缓存，注意与持久化及时同步问题
* 作小于判断时，注意-0 是等于0 的，应该用<=来判断。
* windows 2003系统中当开着服务控制台启动DaemonServer后不关闭mmc控制台,向控制台输内容会导致阻塞。要自定义文件流，使他们保存至文件。
* 持续进数据的队列 要对处理慢的情况有考虑，否则会oom
* 同步数据需要在一个事务内完成写入,否则会导致界面的坏体验
* 使用具体类来代替type类型区分，可以帮助在有性能问题时快速定位，只是有可能增加些代码量，值得