所以第二天的站会上，昨天你完成了哪些功能，是否提交了，是否完成了单元测试，是否通过了集成测试，就都知道了，你需要给大家一个解释，然后进入到新一天的开发。
到了两周，一个周期完毕，可以上线到生产环境了，可以通知有权限的运维进行操作，但是也是通过自动化的脚本进行部署的。
这就是整个过程，层层保证质量，从中可以看到，敏捷开发，持续集成，持续交付，持续部署，DevOps是互相联系的，少了任何一个，整个流程都玩不转。
五、有关代码结构
代码结构往往包括：
API接口包
访问外部服务包
数据库DTO
访问数据库包
服务与商务逻辑
外部服务
如果使用Dubbo RPC，则API接口往往在一个单独的jar里面，被服务端和客户端共同依赖，但是使用了springcloud的restful方式就不用了，只要在各自的代码里面定义就可以了，会变成json的方式传递，这样的好处是当jar有多个版本依赖，需要升级的时候，关系非常复杂，难以维护，而json的方式比较好的解决了这个问题。
这个模块提供了哪些接口，只要到API接口这个package下面找就可以了。因为无论是Dubbo还是springcloud，接口的调用都会重试，因而接口需要实现幂等。
访问外部服务的包，这将所有对外的访问独立出来，好处一是可以抽象出来，在服务拆分的时候，可能会用到，例如原来支付的逻辑在下单的模块中，要讲支付独立出来，则会有一个抽象层，涉及到老的支付方式，还是调用本模块中的逻辑，涉及到新接入的支付方式使用远程调用，有了这一层方便的多。好处二是可以实现熔断，当被调用的服务不正常的时候，在这里可以返回托底数据。好处三是可以实现Mock，这样对于单元测试来讲非常好，不用依赖于其他服务，就可以自己进行测试。
DTO和访问数据库的包，看到了这些数据结构，会帮助程序员快速掌握代码逻辑，不知道大家有没有这个体验，你去看一个开源软件的代码，首先要看的是他的数据结构，数据结构和关系看懂了，代码逻辑就比较容易懂了，如果数据结构没看懂，则光看逻辑，就容易云里雾里的。
还有就是核心的代码逻辑和对接口的实现。在这里面是软件代码设计的内功所在，但是却不是流程能够控制的。
六、有关接口设计规范
上面也说过了，Dubbo和Springcloud会对接口进行重试，因而接口需要保持幂等。也即多次调用，应该产生一致的结果，例如转账1元，因为调用失败或者超时重试的时候，最终结果还应该是转账1元，而非调用两次变成转账2元。
幂等判断尽量提前，可以使用ID作为判断条件。
接口的实现应该尽量避免阻塞，可以使用异步方式提升性能。
接口应该包括能够区分不同情况的异常，而非抛出宽泛的Exception，不能吞掉异常。
接口的实现要有足够的容错性，以及对不同版本的兼容性。当要引入新接口的时候，使用先添加，后删除的方式。
接口应该有良好的注释。
七、有关代码设计
对于代码的设计，这里常说的就是SOLID原则。
S是单一责任原则，如果你的代码中有一个类行数太长，可能你需要重新审视一下，是不是这个类承担了过多的责任。
O是开放关闭原则，比较拗口，对扩展开放，对修改关闭。思想是对于代码的直接修改是非常危险的事情，因为你不知道这段代码原来被谁用了，而且当时候用的时候，面临的情况都是怎样的。因而不要贸然修改一段代码，而是选择用接口进行调用，用实现进行扩展的方式进行。当你要实现一段新的功能的时候，不要改原来的代码，也不要if-else，而是应该扩展一种实现，让原来的调用的代码逻辑还是原来的，在新的情况下使用新实现的代码逻辑。
L是里氏替换原则，如果基于接口进行编程，则子类一定要能够扩展父类的功能，如果不能，说明不应该继承与这个接口。例如你的实现的时候，发现接口中有一个方法在你这里实在对应不到实现，不是接口设计的问题，就是你不应该继承这个接口，绝不能出现not implemented类似之类的实现方法。