🍊
翻译橙
🍊返回主站🤖参与贡献
  • hello,这里是翻译橙
  • spring boot参考文档
    • 1. 法律
    • 2. 寻求帮助
    • 3. 文档概述
    • 4. 入门
    • 5. 升级Spring Boot
    • 6. 使用 Spring Boot 进行开发
      • 6.1. 构建系统
      • 6.2. 构建你的代码
      • 6.3. 配置类
      • 6.4. 自动配置
      • 6.5. Spring Bean 和依赖注入
      • 6.6. 使用@SpringBootApplication注解
      • 6.7. 运行您的应用程序
      • 6.8. 开发者工具
      • 6.9. 打包您的生产应用程序
      • 6.10. 接下来读什么
    • 7.核心特性
      • 7.1. SpringApplication
      • 7.2. 外部化配置
      • 7.3.Profile配置
      • 7.4.日志记录
      • 7.5.国际化
      • 7.6 面向切面的编程
      • 7.7. JSON
      • 7.8. 任务执行与调度
      • 7.9. 单元测试
        • 7.9.1. 测试范围依赖
        • 7.9.2. 测试 Spring 应用程序
        • 7.9.3. 测试 Spring Boot 应用程序
        • 7.9.4. 测试容器
        • 7.9.5. 测试工具
      • 7.10. Docker Compose 支持
      • 7.11. 测试容器支持
      • 7.12. 创建您自己的自动配置
      • 7.13. Kotlin 支持
      • 7.14 SSL
      • 7.15.接下来要读什么
    • 8. 网络
      • 8.1. Servlet Web 应用程序
        • 8.1.1. “Spring Web MVC 框架”
        • 8.1.2. JAX-RS 和Jersey
        • 8.1.3. 嵌入式 Servlet 容器支持
      • 8.2 反应式网络应用程序
        • 8.2.1. “Spring WebFlux 框架”
        • 8.2.2. 嵌入式反应式服务器支持
        • 8.2.3. 反应式服务器资源配置
      • 8.3. 优雅关机
      • 8.4. spring安全
        • 8.4.1. MVC安全
        • 8.4.2. WebFlux 安全
        • 8.4.3. OAuth2
        • 8.4.4. SAML 2.0
      • 8.5. spring 会话
      • 8.6.GraphQL
      • 8.7. Spring HATEOAS
      • 8.8.接下来读什么
    • 9. 数据
      • 9.1. SQL数据库
      • 9.2. 使用 NoSQL 技术
      • 9.3. 接下来读什么
    • 10. 消息
      • 10.1. JMS
      • 10.2. AMQP
      • 10.3. Apache Kafka 支持
      • 10.4. Apache Pulsar 支持
      • 10.5. RSocket
      • 10.6. Spring Integration
      • 10.7. WebSockets
      • 10.8. What to Read Next
    • 11. IO
      • 11.1. 缓存
      • 11.2. Hazelcast
      • 11.3. Quartz 调度程序
      • 11.4. 发送电子邮件
      • 11.5. 验证
      • 11.6. 调用 REST 服务
      • 11.7. web services
      • 11.8. 使用 JTA 进行分布式事务
      • 11.9. 接下来读什么
    • 12. 容器镜像
  • Spring核心功能
    • 1.IOC容器和Bean简介
      • 1.2. 容器概述
      • 1.3. Bean概述
      • 1.4. 依赖项
        • 1.4.1. 依赖注入
        • 1.4.2. 详细的依赖关系和配置
        • 1.4.3. 使用depends-on
        • 1.4.4. 延迟初始化的 Bean
        • 1.4.5. 自动装配协作者
        • 1.4.6. 方法注入
    • 2. Resources
      • 2.1. 介绍
      • 2.2. Resource接口
      • 2.3. 内置Resource实现
      • 2.4. ResourceLoader接口
      • 2.5. ResourcePatternResolver接口
      • 2.6. ResourceLoaderAware接口
      • 2.7. 资源作为依赖
      • 2.8. 应用程序上下文和资源路径
    • 3. 验证、数据绑定和类型转换
      • 3.1. 使用 Spring 的 Validator 接口进行验证
      • 3.2. 将代码解析为错误消息
      • 3.3. Bean 操作和BeanWrapper
      • 3.4. spring类型转换
      • 3.5. spring字段格式
      • 3.6. 配置全局日期和时间格式
      • 3.7. Java Bean 验证
    • 4. SpEL表达式
    • 5. Spring 面向切面编程
      • 5.1. AOP 概念
      • 5.2. Spring AOP 的能力和目标
      • 5.3. AOP 代理
      • 5.4. @AspectJ 支持
        • 5.4.1. 启用@AspectJ 支持
        • 5.4.2. 声明一个切面
        • 5.4.3. 声明切入点
        • 5.4.4. 声明切点
        • 5.4.5. 切面说明
        • 5.4.6. 切面实例化模型
        • 5.4.7. AOP 示例
      • 5.5. 基于模式的 AOP 支持
      • 5.6. 选择要使用的 AOP 声明样式
      • 5.7. 混合切面类型
      • 5.8. 代理机制
      • 5.9. @AspectJ 代理的程序化创建
      • 5.10. 在 Spring 应用程序中使用 AspectJ
      • 5.11.更多资源
    • 6. Spring AOP API
      • 6.1. Spring中的切入点API
      • 6.2. Spring 中的 Advice API
      • 6.3. Spring 中的 Advisor API
      • 6.4. 使用ProxyFactoryBean创建 AOP 代理
      • 6.5. 简洁的代理定义
      • 6.6. 以编程方式创建 AOP 代理ProxyFactory
      • 6.7. 操作切面对象
      • 6.8. 使用“自动代理”工具
      • 6.9. 使用TargetSource实现
      • 6.10. 定义新的切面类型
    • 7. 空指针安全
    • 8. 数据缓冲器和编解码器
    • 9. 日志
    • 10. 附录
      • 10.1. XML 模式
      • 10.2. 自定义XML Schema
        • 10.2.1. 创作 Schema
        • 10.2.2. 编码一个NamespaceHandler
        • 10.2.3. 使用BeanDefinitionParser
        • 10.2.4. 注册处理程序和模式
        • 10.2.5. 在 Spring XML 配置中使用自定义扩展
        • 10.2.6. 更详细的例子
      • 10.3. 应用程序启动步骤
  • 使用redis实现分布式锁
  • Java 安全标准算法名称
  • JDK 9 JEP
  • JDK 10 JEP
  • 人件
    • 《人件》
    • 第一部分 管理人力资源
      • 01 此时此刻,一个项目正在走向失败
      • 02 干酪汉堡,做一个,卖一个
      • 03 维也纳在等你
      • 04 质量——如果时间允许
      • 05 再谈帕金森定律
      • 06 苦杏素
    • 第二部分 办公环境
      • 07 家具警察
      • 08 “朝九晚五在这里啥也完成不了。”
      • 09 在空间上省钱
      • 间奏曲:生产效率度量和不明飞行物
      • 10 大脑时问与身体时间
      • 11 电话
      • 12 门的回归
      • 13 采取保护步骤
    • 第三部分 正确的人
      • 14 霍恩布洛尔因素
      • 15 谈谈领导力
      • 16 雇一名杂耍演员
      • 17 与他人良好合作
      • 18 童年的终结
      • 19 在这儿很开心
      • 20 人力资本
    • 第四部分 高效团队养成
      • 21 整体大于部分之和
      • 22 黑衣团队
      • 23 团队自毁
      • 24 再谈团队自毁
      • 25 竞争
      • 26 一顿意面晚餐
      • 27 敞开和服
      • 28 团队形成的化学反应
    • 第五部分 沃土
      • 29 自我愈复系统
      • 30 与风险共舞
      • 3l 会议、独白和交流
      • 32 终极管理罪恶得主是……
      • 33 “邪恶”电邮
      • 34 让改变成为可能
      • 35 组织型学习
      • 36 构建社区
    • 第六部分 快乐地工作
      • 37 混乱与秩序
      • 38 自由电子
      • 39 霍尔加·丹斯克
由 GitBook 提供支持
在本页
  • 进步是我们最大的问题
  • 试点项目
  • 战争游戏
  • 头脑风暴
  • 培训、旅行、会议、庆祝和撤退

这有帮助吗?

在GitHub上编辑
  1. 人件
  2. 第六部分 快乐地工作

37 混乱与秩序

人类的本性使我们成为混乱的天敌。每当我们遇到混乱时,都希望将其变回秩序井然。到处都可以看到人造的秩序……在我们家中,花园里,甚至在我们梳头和规划街道的时候,都能看到秩序的影子。然而,这并不意味着彻底消除混乱就能使我们的生活变得更加美好。在当今社会,混乱已经成为一件值得人们珍惜的东西。我们需要细心呵护它,避免让那些“贪婪的少数(greedy few)”过肆地扩张以至于挤掉它们的生存空间。

我们这些管理人员就是所谓的“贪婪的少数”。我们经常将混乱视为自己的特殊领域。我们认为让一切井然有序就是我们的工作。开放的管理者却有一套截然不同的方法。他们愿意给其他人保留一小部分的混乱。采用这种方法,管理者的工作就是将混乱分成不同的部分,分发给下面的人打理。下面的人会从将这些事务整理得井井有条的过程中收获真正的乐趣。

进步是我们最大的问题

混乱的程度一直在下降,特别是在新的技术领域。对于那些出于好奇而进入这个领域的人来说,他们对于那个缺乏秩序、万事万物都没有那么机械的年代充满了怀旧之情。在过去的 30 年中,每一项伟大的进步都简化了我们的工作。当然,这些进步带来的好处无比精彩,我们也不愿再回到那个古老的时代了——但是……

我们都渴望改进我们的工作方式,使软件开发这个行业能够更加有序。这是一种进步。诚然,在这个过程中,某些疯狂的乐趣就此丢失了,而一个人的快乐可能正是另一个人的痛苦(你认为很成功的项目,在老板眼中可能一文不值)。无论如何,向着更加有秩序、更可控的方向前进正是大势所趋。深谋远虑的管理者不会阻止这种趋势,但也可能会适当地尝试逆势而为,从而给工作注入更多的能量。这就使得我们可以采取某种策略,建设性地重新引入少量无序。

既然开门见山地亮出了我们的观点,现在就只需要列出实现该策略的几种方法:

  • 试点项目

  • 战争游戏

  • 头脑风暴

  • 激发性训练

  • 培训、旅行、会议、庆祝和撤退

以上我们审慎地给出了一些成功应用过的重新引入混乱的手法。当然,若是你自己的列表,限制则不必如此严格。针对某个主题开展一次短暂的头脑风暴(后面会详细介绍头脑风暴)将会带来意想不到的精彩可能。

试点项目

在试点项目中,我们可以抛开常规,尝试一些新的未经证明的技术。起初,大家对新技术不怎么熟悉,因此不必期待从一开始就要多么高效。改变总是会有成本的。另一方面,生产效率会随着我们采用的新技术而提高。这种总体上产生的正面效应就是霍桑效应(Hawthorne Effect),即人们在尝试新颖的东西时,所激发的能量与兴趣可以促进人们的生产效率。

这两点正面效应可以抵消由于过陡的学习曲线带来的负面影响吗?我们认为,答案是肯定的。改变其本身的重要性,就与项目周期、人员能力以及人们对他们正在试验的技术的信任度同等重要。根据我们的经验,采用了任何改进方法的试点项目,带来的生产效率都要大大高于平均值。这意味着,如果你选择在试点项目中采用某些新技术,可以降低你的投入。

那么,所有的项目都应该是试点项目吗?如果你所在的组织采取了这样的策略,那么恭喜你。像富士通和 IBM 的一些子公司和子部门,就是这样做的。在任何情况下,比起没有试点项目,将所有项目做成试点项目都是大有裨益的。

对于在试点项目中运用新技术的方法.通常存在两点反对意见:

  • 没有可以试点的项目怎么办?

  • 由于交付了不一致的产品,我们的下游活动(比如产品支持和客户培训等)岂不是更加复杂了?

第一个反对意见基本上是一个伪命题。多年的实践经验表明,大多数组织都不必担心没有可资试点的项目。他们可以将前十年所积累起来的好点子放在下一个十年进行试点。在结束时,又一个十年过去了,又会有充足的试点项目出现。

对于不一致产品传递到下游团队的问题,你得承认这个问题对于任何行业来说都是存在的,即便对于高度标准化的商店也是如此。当下,人们做的事情是满足不同产品间的文档一致性,而非功能上的一致性。换言之,标准化的只是与产品相关的文档而已,并不是产品本身。即使项目文档与标准之间存在些许差异,带来的不便也不会太大。

对于试点项目的一个警告是:在任何一个项目中不要试验超过一种类型的开发技术。虽然总是谈到标准的重要性,让人惊讶的是,很多项目管理者在试点项目中却彻头彻尾地抛弃了所有的项目标准。他们通常在同一个项目中尝试使用新的硬件、新的软件、新的质量控制过程和新的原型技术等。

实施试点项目的合理做法是每次只允许对开发过程的一个组成部分进行细微的调整。在一个最健康的环境中,顼目人员应该知道,对于每一个试点项目,鼓励试验一个技术点,同时,还需要遵循其他的项目标准。

战争游戏

就我们多年组织的编码战争游戏来看,有时一些具有竞争性但又无所谓输赢的活动可以带来具有建设意义的无序性。虽然这个游戏是为软件社区量身定制的,但是,其中的概念却可以应用于任何一个领域。不管你从事什么样的工作,这种游戏都可以成为一种令人愉悦的经历,用以处理一些定制的问题,并能比较你与你同事之间的能力殊异。(当然,前提是遵循第 8 章中描述的安全与信息保障,以确保该游戏的结果不会对你产生负面效应。)

战争游戏可帮助你评估自己的相对优势与劣势,进而帮助企业评估出自己的整体优势与劣势。正因为此,我们的两个客户每年都会举行这样的战争游戏,以此来帮助员工在技能方面进行自我评估和自我改进。每年一度,员工们都会进行这样一次完全保密的测试过程,就像进行体检一样。

为了模拟具有积极效果的无序性,最有效的战争游戏方式是将参与人员分成不同的团队。下面便是我们曾经成功尝试(当然也是一次宏大的消遣)过的一种游戏形式。

  • 选择一个小的开发项目或者一个任务划分清楚的项目作为实验用的小白鼠二最好能够选择公司中的一个实际项目,l ~ 2 人月的工作量。然后,选择一个新的、具有挑战性的问题。当然,这个问题应该能眵应用到员工的开发技能。

  • 通过发布 T 作的具体声明使项目以正式的方式运转。

  • 正式宣布在即将到来的周末将有一个 24 小时的项目锦标赛。确保所有人都能理解,将比赛安排在周末并不是为了省钱,而是使团队有个属于他们自己的地方进行比赛,而非为了节约人力成本。鼓励每个团队由四个人组成,比赛完全基于自愿原则。

  • 事先发布工作声明,并且规定游戏规则和目标。

  • 锦标赛开始当天,仅参赛人员出场。提供他们之所需(食品、计算机、帆布床、复印机、会议室等)。让所有团队都做相同的工作,以确保他们之间的确属于竞争关系。

  • 为比赛安排组织者,他们的职责是确保每个人都遵循那些基本的原则,防止致命问题的发生。若有团队取得阶段性成功,应营造出锣鼓喧天的欢庆感觉。

  • 寻找机会让每个人都能在某种程度获胜(最短耗时奖、健壮产品奖、最优方案奖等)。要大声宣布任何团队取得的任何成就。

  • 安装获胜产品,或者同时安装多个获胜产品。小心记录产品稳定性、缺陷数量、用户接受程度、改变所需成本等任何有可能影响产品成功的信息。然后,将这些数据报告给开发团队。

在这样的活动成功举办之后,大家会告诉你,这是他们整个职业生涯中最激动人心也是最为享受的经历。没有什么能比你的目标更重要了。期待达成目标,即便需要尝试多次。

对于这样的项目锦标赛,要注意以下几点:首先,这些事情是要花钱的。不要让员工在周六的比赛时间做平时工作上的事情,不然就需要支付实际的工资。比起相同的常规项目,在这样的比赛项目上可以多做几次尝试。其次,可以多花些时间凸显项目中的问题,使组织者活跃起来,进而引入更多的检查点和阶段性成果。再次,根据项目所需时间来准确地界定项目范围(如果范围大到所有团队都不可能完成,或者简单得一开始不久就能完成,没人会有乐趣)。最后,在食物上要显得慷慨一点(在我们进行的一次比赛中,我们从纽约城餐厅预订了丰盛的野餐式午餐,并提供了晚餐外卖,在下午 2 点钟的时候,所有人还去唐人街买了好些零食)。

通宵进行比赛往往会带来更多的乐趣。人们总是喜欢共患难、精疲力竭,让每个人都能看到其他人头发凌乱、不修边幅的邋遢样子。这种方式会使得所有人能够更紧密地团结在一起:

在比赛中,我注意到有人(一个参与者)直接在前台的地毯上打瞌睡我已认识她多年,之前一直觉得她很拘谨,现在才了解到她不同的一面 我看到了所有人的另一面 我们更像是一个整体了——来自项目锦标赛的某位参与者

头脑风暴

头脑风暴是一种交互式的会议活动,对于需要创造牲思维的工作尤为有用。一群人聚集在一起讨论同一个问题。在头脑风暴中,负责人应该保证整个过程既是无序的,又是愉快的,并且能够产生出实际的成果。

头脑风暴没有多少规则。由于我们的目的就是要在整个过程中制造混乱,规则显然就格格不入了。作为组织者,你需要强调的是点子的数量,而不是质量,要让整个过程非常松散,甚至显得有些愚蠢。有时,一个明显看来很愚蠢而且在常规会议中根本不会被提出来的点子可能会成为最后的赢家。在头脑风暴的过程中,我们并不对征集的点子进行评判,而是在之后做这样的事情。我们不鼓励负面的评论,比如“这个点子没劲”,因为不好的点子通常促使人们想出更好的点子。

作为组织者,当发现大家没有什么点子可出时,可以采取以下措施:

  • 类比思考(比如,大自然是如何处理这个问题或者相似的问题的?)

  • 反其道而行之(我们所要达到目标的反面是什么?)

  • 身临其境(如果是你,你会如何解决这个问题?)

培训、旅行、会议、庆祝和撤退

对于在沉闷的办公室待惯了的人来说,我们都希望能到办公室外面去走走。人们最想做的一件事情便是能够和同事一起出去旅行了。这种旅行可以是大家一起去参加某次培训,或者参加一次国际会议等。如果是到那些具有异域风情的地方,那就更棒了。你可以将员工从波士顿送到伦敦去参加一次会议,而这样的费用和送他们到圣路易斯或者丘拉维斯塔的费用是相当的。

特别是对于正在成长的团队来说,值得花钱让他们走出办公室。如果你有个外地的客户,可以将他们送到客户现场工作,所有费用由公司支付。如果是一个思想密集型的交付项目,可以将他们放在一个会议中心或者酒店里。创造机会让他们能够一起乘坐飞机,一起用餐,并在新的团队中规划自己的角色。

拓展训练机构通常会将你的员工带到野外来测试他们的勇气。在拓展训练中,每个组都需要度过重重难关,翻山越岭,激流勇进。前一天,你可能还在为供应链管理冥思苦想,绞尽脑汁;第二天,你却发现自己在拓展训练中与队员们同甘共苦。当然,这样的培训并不便宜。要是计算花在培训机构、旅行以及浪费的工作时间,你会发现你在每个人身上花了好几千美元。对于多数公司来说,这样的花销都是不可想象的。但是,那些确实开展了拓展训练的公司又如何呢?他们难道能傻到如此地步呜?或者他们是在做一些能够真正激发员工斗志的事情?

几千美元是否已经超出了你制造无序状况的预算?或者你只能拿出几百美元?我所知道的其中一位最有创造力的管理者向他的员工提供了一顿意外的午餐。他曾经跑到城里的一条街道,雇了一家热狗供应商——推了一整车酸菜味儿或者芥末黄的热狗,车上插着海蓝与橙黄相间的大伞——推到电梯中,乘坐到 30 楼,服务周到地分发给自己的员工。在营养学家眼中,这顿午餐其实都是些垃圾食品,但在社会学家眼中,却是一次成功的圆梦。每位员工都变得精神振奋、斗志昂扬,开始热火朝天地干起活来。他们的热情被这种喧嚣给点燃了。这一创举的成本不过几百美元,却在之后常被人津津乐道。当然,这名管理者将这次午餐划归为工作餐,但实际上这并不是一次午餐,而是一场庆祝。

毫无疑问,好的秩序是我们日常工作之所需。但是,我们依然希望能够看到一些冒险和一些适当的具有建设意义的无序性。

上一页第六部分 快乐地工作下一页38 自由电子

最后更新于6个月前

这有帮助吗?