流程

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> Activiti中流程的历史信息保存在ACT_HI_ACTINST表中，流程历史信息保存在ACT_HI_PROCINST表中，我们可以通过API或者直接写SQL进行查询，但是这里面并没有流程发起人的信息，流程发起人信息有的时候还是非常必要的，比如查询某人发起的流程或者做相关的统计等。 鉴于ACT_HI_ACTINST中保存了流程的活动历史信息，我们还是想在这个表上做文章，但是这个表中并没有发起人等相关的字段，这时候，我们发现，当一个流程刚发起时，ACT_TYPE_为startEvent，这时ASSIGNEE_为空，如果我们能借用这个字段，保存申请人，查询起来代码还是比较优雅的，虽然这个字段本身的含义不是申请人。 另外，ACT_HI_PROCINST表中还有一个START_USER_ID_字段，但是默认为空。通过上述两种保存流程发起人的方式，在不同的场景中都能够通过简单的方式查询到流程的发起人信息。 下一步，就是研究Activiti的代码了，看看能不能找到相应的扩展点，解决这个问题。 经过研究，找到了扩展点，开发起来还是比较方便的，下面进行详细描述，注意，本文的开发基于Activiti5.15.1版本，大体扫了下代码，更新的5.17版本应该也兼容，但未经过测试。 对于流程发起时保存ACT_HI

如果跳出进程（注意进程与线程的区别：线程是调用域的分界处，进程则是地址空间的分界处------因此，线程是调用问题的边界，进程则是“对象”的边界。在线程以外，没有真正的调用；同时，在进程以外，没有真正的“对象”------这源于操作系统的地址保护/隔离机制），也就跳出了OO的框架。这里的技术开始变得五彩纷呈： DCOM，CORBA，IIOP，SOA，REST，WEB SERVICE，ESB，EAI，SCA，MOM，HTTP，SOAP，RIA。。。 进程内的（运行时）技术，集中在性能，可移植性，可靠性，稳定性，健壮性，状态受控性，线程安全等方面。而进程外的（运行时）技术，侧重点在于异构协作，集成，系统架构，资源，异步，传输特性，路由，系统管理，流程，，，等方面。 来源： oschina 链接： https://my.oschina.net/u/109289/blog/29794

##要点 自动化基础 角色／配置管理 系统镜像？ 统一版本控制方式 运维人员也需 让所有人都知道该干什么 一步编译／部署 一个操作解决 工具自动记录时间／任务／事情 小而频繁地更改 特征标记（分支） 可以开发很多功能，完成之前不对外开放 不同开发语言都有？ 水桶测试 设想把编程看成是转动曲柄从井里提一桶水上来的过程。如果水桶比较小，那么仅需一个能自由转动的曲柄就可以了。如果水桶比较大而且装满水，那么还没等水桶全部被提上来你就会很累了。你需要一个防倒转的装置，以保证每转一次可以休息一会儿。水桶越重，防倒转的棘齿相距越近。 测试驱动开发中的测试程序就是防倒转装置上的棘齿。一旦我们的某个测试程序能工作了，你就知道，它从现在开始并且以后永远都可以工作了。相比于测试程序没有通过，你距离让所有的测试程序都工作又近了一步。现在我们的工作是让下一个测试程序工作，然后再下一个，就这样一直进行。分析表明，要编程解决的问题越难，每次测试所覆盖的范围就应该越小。 - [Dark Lauches](http://changelog.ca/log/2012/07/19/dark_launching_software_features) 简单说，就是开发新功能是要能使之方便地开启／关闭，可以很好应对突发事故。 统一的度量标准 开发人员可以看到运维情况（CPU/网络等情况） 即时聊天工具／机器人 远程办公 开发

学习了《软件开发沉思录》中的实用主义性能测试，对重点内容做下记录： 性能测试应该囊括确保产品性能符合要求所需的一切行动。这里有四个关键点:需求、产品性能数据、沟通和流程。 1.需求采集 需求采集中的几个重要问题:要度量什么?如何知道我们需要什么?以及如何得到确实有用(而非帮倒忙)的数据? @要度量什么 最重要的性能度量点有两个,最大吞吐量以及给定吞吐量下的响应时间。一个好的做法是:分别度量几种不同吞吐量下的响应时间,从中分析负载对响应时间的影响。 需要通过度量找出两项数据:当响应时间恰好可以接受时的吞吐量,以及达到预期吞吐量时的响应时间。伸缩性度量的关键则在于:随着数据规模、用户数量或者运行系统的硬件变化,起初得到的性能度量数据会发生怎样的变化。 可靠性的关键度量点是:当负载量高得超乎寻常,或者连续运行了很长时间以后,系统是否仍然正常工作。 @如何设定目标 要想知道系统需要达到怎样的吞吐量,你首先需要知道有多少用户会使用这个系统,以及他们的使用模式。用户会多频繁地使用某个功能?这个功能需要多快完成? 需要有一个可靠的沟通流程与机制来获得所需的信息,及时获知支撑业务需求所需的性能指标。 总之： 需求采集是为了让所有人都清楚最终交付的产品需要有怎样的性能才能支撑业务目标。之所以要让客户参与,是因为他们最了解自己的业务,这样才能确保采集到的需求足够准确