面向对象编程

意味着几件事情。
第一，参与这个系统的角色一定有多个，若只有一个角色，且只有一个动作，那就退化成面向过程编程。
第二，需要规约出系统的各个角色，以及相互之间的交互
第三，根据需要抽象出各种抽象层。
第四，每个抽象层的实现就是面向过程编程

note1.其实所谓的组件化就是合理的抽象出系统内的角色，然后以服务的形式对外运行，而非原来的代码层面的内联。
note2.现有大部分编程事件都是面向过程的层次，很少涉及设计，也少有人员想要先去设计

开发流程

产品提出需求->产品经理及项目经理评估需求->开发测试产品确定，细化需求，给出需求用例->测试给出测试用例->开发测试共同给出技术方案->开发->迭代测试->上线

需求必须留档，且产品需给出User Case角度的用例

其中用例可用于系统的自动化

测试用例是以黑箱角度给出，且应为产品的UserCase的细化
用例必须留档，提出bug必须依据用例，并生成bug用例进行验证

每次迭代只应该做增量测试，每天自动化做全量测试

用例Example：
测试：
动作：用户激活账号
前置条件：用户账号已注册且保持未激活状态
执行接口/事件：*.do 点击xxxx按钮，激活如下事件
预期：接口返回/事件结束/抛出异常/etc

产品：
测试：
动作：用户激活账号
前置条件：用户账号已注册且保持未激活状态
预期：用户成功激活账号

另外，开发和测试其实应该要求是一样的，都应该懂代码，完全的黑箱非自动化的测试是会搞死人的

如何拦截SQL

1、所有开发约定所有人都用公司某一个基础包，自己封装此基础包
2、所有人都爱用自己喜欢的ORM的话，推荐拦截jdbc驱动
3、采用alibaba的Druid连接池，自己写一个Filter。

SOA与REST关系

REST是实现SOA的一种技术手段
比如服务与服务之间的通信采用REST接口。
但其实服务与服务之间通信不仅是可以REST，同时可以用消息队列，分发器，soap等等
更具体的是，SOA代表一种战略意图，REST是实现战略意图的一种战术

有一些不得不吐槽的

新技术真的好么，我并不觉得，至少我所在的层级很不喜欢各种新技术
我原来从来没用过MyBatis，总听说多好多好，但是在绝大部分场景下，都不如我直接用spring jdbc template来的方便，它那套orm转换预设了太多假设，为了解决那一堆不符合假设的场景又发明一堆概念。

比方说一个很简单的例子：

  • 我的数据库的时间字段是varchar类型保存的，那么我用Spring jdbc大概会需要对一个表对象写大约二十行的代码做orm转换。
  • 但是我用Mybatis也不见得少几行，特别是用xml写sql的时候还要自己指定Handler来做转换。
  • 有一点更不方便，项目大部分都采用spring做对象管理，当基础包和上层应用都用spring管理了，而基础包却依赖了某个特定的spring配置项，然后大家就呵呵了

其实最中心想吐槽的应该是，基础包应该尽可能的少依赖外部，或者说自有配置应该打包输出并封装在自己的项目，不要和上层应用发生耦合，会造成各种的不舒服.

数据同步

网络传输的数据结构要点：

要能区分出数据来源

要能区分数据新旧

要能分辨数据正确性

除了对数据结构的直接操作，其他都应该是外部组件

数据状态

正常

过旧

冲突（定义为异常状态需要使用者自己处理）

以上抽象成Condition

可能的复杂点

多数据冲突同一个数据，组件不解决，应该由业务处理

组件需要保证每次同步都将会是原子操作，故而多线程并发会是难点

尽可能使的组件易于扩展（尽量用接口编程）