1.一定要注意日志机制，并在项目设计之初就指定日志的方式，哪些地方记录什么样的日志。
2.为什么要适用全局的css，为什么要设计类，来囊括所有的操作或者部分的操作，这些其实都在做一件事：控制。尽量多的内容在控制范围之内，而不是随意散落，让各个单体来自己决定是一件很难控制也很可怕的事情，越大的项目/机构这样也就越危险。
3.做系统设计，一定要从划分的模块中跳出来，而是从模块的内在的关系和对象的角度中来做分析和设计。所谓模块是深层业务逻辑的表面体现，换言之是给客户使用的，不是你设计师设计的东西。设计师关注的是根本的东西。比如成本系统中被划分了成本科目管理，发票，项目，成本核算等模块，但是我们看到究其核心是什么？我们先来捋一下思路：成本系统的核心对成本的核算，核算来自于两部分：成本系统本身的发票以及外系统（财务&ME），其实整个系统的处理核心，或者说源头就在这里，无论是项目管理，还是成本核算，归根到底用的就是这些数据。不过还没完，数据是有的，那么这些数据的粒度是怎样的呢？计算口径是深层次理解数据源的关键。对于数据源的理解有很多维度，不同的项目有不同要求，对于成本系统而言，以飞机为单位的成本科目（维修任务级别）和费用类别（工时/材料/其他）是关键。基于此来如此设计，无论是数据库设计，还是应用层设计都将会非常清晰。
4.系统设计和数据库设计关系紧密，其中一个用处，如果你想要修改一处设计想要知道会影响那些业务，那么你可以参看数据库的设计，这个业务的表关联那些表，这些表用都是和哪些业务关联，即可知道受影响的业务了。
5. 对于操作的执行分析，要有一个Sense:执行这个操作有什么约束。比如删除一张发票，如果这张发票已经放入了付款通知书那么就不能删除。除非它首先从付款通知书里面删除了，再回过头来删除发票。在比如每月执行数的修改，一定要校验执行数不能超过预提总额，至于这一点是否要校验呢？值得商榷，约束很多情况是越少越好，伴随着业务的开展，会有很多意想不到的情况发生，限制这种约束反而会影响系统的易用性和健壮性。所以添加约束这一点，要慎行，要有确认的添加，而不是拍脑袋。
6.在需求分析阶段，业务群，转化为故事群，在设计阶段将故事群转化为对象群，再将对象群转化为表群，总之要建立一个“群”的概念，群的概念就是既是单独的个体，也是相互关林的个体，都是有背景的，被使用，同时也使用别人。群的概念提出目的是让设计者，调研者在脑海中要对整体的设计，需求建立画面，反复推演。
7.做业务分析一定要一条线（主干），一棵树（全貌），能够了解整个系统的全貌，然后了解各个组成部分之间的关系，而不要有遗漏，所以作分析前提是做好全局认识，创建好系统树，再来谈系统分析。
8. 状态-功能矩阵
对于汇总显示的查询，是不能通过点击一条记录进行修改的（因为你不知道要修改那一条）。所以页面有很多状态，对于和一个状态的改变要遍历其他的业务，是否状态的改变导致其他业务不能正常进行，加以校验。所以细化页面的时候需要两张列表，状态列表，业务（功能）列表，看看两者的影响情况，姑且称之为状态-功能矩阵。接上，什么叫做状态，状态就是不同将会导致业务（操作）不同，属性，就是不同不会导致业务（操作）不同.
9. 修改/ 添加的设计
对于修改的方式有两种：一种是下面是表格，然后点一下表格某一项，内容反倒上面去，然后修改；还有一种方式就是一堆的输入框，直接修改，添加就是直接增加一行，这样做的好处是对于用户操作比较便利，但是对于后台程序处理而言怎是每一次都是先删除所有的项目（因为跟踪字段修改本身就比较麻烦，而且无疑是页面又增加了一种机制，增加项目的复杂性），然后重新创建。这样做成本比较高，而且如果是需要记录操作日志的情况下，这种方式也不便于记录真实操作。还有一种处理方式就是完全交给后来来判断，返回过去的数据是修改还是新增，但是这种机制造成后台的处理逻辑变得复杂，对于开发不利，一个保存方法的职责太多了，处理太多，不易于维护，最好还是区分开来，由前台的分状态处理比较好。
10. 异常处理和日志现行
异常处理和日志处理这两部分十分重要，一定要重视起来，这两个模块应该是先行者。而且日志的内容应该分为两部分：一部分是当前日志，应该只有一条，方便开发者跟踪本次异常，还有一个就是日志列表，记录历史信息。因为我们看到开发人员发现了异常还需要首先重新运行，而且还不确定那里除了问题，如果能够先看日志，大致确定问题点，然后再调试会提高开发效率。
另外，日志的输出应该是可以打开关闭的，在测试开发阶段，部分向文档中写日志的方式应该被打开，部署之后就关闭。
11.数据库的写操作处理
1）一定要对操作（修改，删除）的数据进行版本比较，避免脏数据问题；这个需要通过在框架中添加处理；
2）对于所有的写操作一定要判断返回值，因为对于数据库并发的情形，异常的情形很可能会出现修改/删除失败的情况，所以需要让用户知道自己的操作是否成功了。这些都是封装在框架里面；
3）对于创建者，创建时间修改者，修改时间等等信息有框架来处理更新；
4）要进行事务的设计；
12.业务逻辑里面一定不能有长串的ifelse的判断，这样会阻挡业务的清晰，对于后来加入和维护阅读代码都很困难，对于这样长串的处理需要抽象为对象进行封装，再次抽离/分离到单独的业务类中，或者一个单独的私有方法。不要放到处理逻辑的主方法中，这样会污染业务处理逻辑。
13.删除有两类，对于有的过往的信息，这类信息将不再被使用（例如核算，归类），可以采用逻辑删除的方式，这样检索的数据真实的反应当时的情况，比如工作流里面的审批人；还有一类是要做限制：比如角色，如果一个角色分配给人了，如果你想要删掉一个角色，一定要把所有的该角色的用户的角色重新指定，才能删除，无论是逻辑还是物理，因为这些人以后还是需要使用的。对于这一类元素可以考虑添加批量修改的功能。
14.基于插拔设计的必要性：客户想要把老空调的升级业务和消息推送业务，实现方式替换为黑水晶方式，我突然发现插拔式设计和好处了。插拔式需要接口统一，清晰，设计的重要性。
15.一定要提供一种能够共同处理接口的机制
这里是因为在老空调，后来决定需要添加白名单的处理，所有的将近60个接口都需要添加一步骤操作：从参数中提取参数mac对其合法性进行校验；需要：接口类一定要继承基类，对于参数一定要最好命名共通（有的叫mac，有的叫deviceid，彻底无语）；因为需要根据对参数进行解析（因为是通过发送xml的方式发送参数）；对于参数命名，对于类的本身的抽象，对于参数的统一化处理，此刻显得尤为重要，设计接口不可不知。