🍊
翻译橙
🍊返回主站🤖参与贡献
  • 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. 第二部分 办公环境

08 “朝九晚五在这里啥也完成不了。”

我们的经济就是,各个领域的开发人员都形成了一种风俗:“加班就是命中注定”。这说明一项工作在预算时间内根本完不成。我们对此说法半信半疑。加班在软件业里确实司空见惯,但若非软件价值远远超过制造成本,这个行业也不会有空前的繁荣。那么,对于软件业工作者及其他思想密集型岗位的工作者,为何还需要投入如此多的额外时间,该怎么解释?

有一种令人困扰的可能性是,加班增加不了工作产出,它只不过提升了平均质量而已。这是真的,你常常能听到有人信誓旦旦地说着这样的话:

“在清晨大家到达之前,我做事的效率最高” “只要一个晚上,我就能做两三个大白天的事情” “办公室一天到晚像个动物园,下午 6 点,慢慢安静下来了, 这时你才可以真正开始完成点事情呢”

为了高效,大家可能选择早到晚走,或者干脆一天都宅在家里来完成工作中的关键部分。一位培训参与者告诉我们,她的新老板不允许她在家工作,有一次需要提交一份重要报告,她在前一天请了病假,待在家里完成了报告。

起早摸黑,又或者宅在安静的家里工作都是对办公环境的一种抵触。让人最为惊讶的事情还不是工作环境不适合完成工作,而是大家都知道,却没人站出来寻求改变。

弃权政策

我咨询过的一家加利福尼亚的公司非常关心自己的员工。有一年,公司管理层决定进行一次调查,了解所有程序员’(一千多人)认为的他们工作中最好和最差的地方。负责调查的经理非常认可公司进行的变革。他告诉我,第二号问题就是跟管理高层的沟通。分析了调查结果后,公司设立了质量小组、意见听取会和其他的沟通项目。我认真听他讲完了细节,然后我问他头号问题是什么。“环境,”他说,“大家对噪声都很不满意。”我又问公司在这方面采取了什么措施。“嗯,这方面我们没啥事儿可做,”他说:“这超出了我们的可控范围”。 -TDM

更让人失望的是,即使没有采取任何手段来改进环境,这位经理并不觉得脸红。这就好像说,程序员们抱怨这里的重力太大,经过管理层的认真讨论,决定听之任之,因为要解决这个问题已经超出了人类的能力范围。这是一种彻头彻尾的弃权政策。

改变环境并没有超出人类的能力范围。基本上每家公司都有家具警察这样一个权利小组,他们控制着公司的物理环境。要让他们看到改变的原因,或者拿走他们的控制权,并非不可能。本章我们将阐释你不得不这么做的原因。而在后续的章节中,我们将给出一些如何做的建议:

编码战争游戏:观察生产效率的因素

在本书第 1 版出版前的几年间,我们每年都面向公众开展一些生产效率的调查。目前为止,已有超过三百家来自世界各地的组织参加了调研。后来,我们开始在不同组织的软件开发团队开展公开竞赛来作为每年的调查。竞赛的内容是用最少时间最少缺陷地完成一系列的编码和测试任务。我们把这种竞赛称为编码战争游戏(Coding War Game)。规则是这样的:

  • 以一对来自于同组织的开发人员为单位参赛。这对开发人员并非一起合作,而是彼此竞争,同时也和其他对参赛者比赛。

  • 参赛两人都做同样的工作,设计、编码和测试一个满足我们固定需求的中等规模的程序。

  • 在做题过程中,参赛者同时在时间簿上记录下花费的时间。

  • 待选手们完成了测试,开发出的产品需要经过我们的标准测试。

  • 选手们都在他们自己的工作环境中在正常工作时间工作,使用相同的语言、工具、开发环境和计算机,就像其他任何一个项目那样。

  • 所有的结果都是保密的。

  • 1984 ~ 1986 年,有来自于 92 家公司的 600 多名开发人员参加了这个游戏。参加的好处是每个参赛者都能够知道他与其他参赛者的对比结果。参赛公司的好处是知道自身和其他公司的差别。对我们而言,收获是获得了影响生产效率的因素。在本章剩下的部分,我们将讨论这些因素。

个体差异

这场编码战争的第一个结果就是证明了参赛者个体的差异非常大。当然,过往已经观察到这样的结果了。如图 8-1 所示,汇集了三个不同来源个体的差异区域。

图 8-1 生产效率随个人而变化

在衡量个体能力差异时都适用的三条经验法则是:

  • 能力最强的人较之最差的产出比大概是 10:1。

  • 能力最强的人比居间的产出高 2.5 倍左右。

  • 能力靠前一半的人较之后一半的产出比大于 2:1。

不管定义了什么样的指标,上述规则都基本适用。所以,调查中能力靠前的那部分人较之后面一半的人,只需一半时间就能完成同一项工作;容易产生缺陷的一半人会比另外一半人多产生三分之二的缺陷,等等。从编码战争游戏得到的结果非常吻合这一描述。图 8-2 给出了一年游戏中完成第一个里程碑(完整编译,可以测试)的时间分布。

图 8—2 能力表现的个体差异

能力最强者比平均值高出 2.1 倍。前面一半与后面一半之比为 1.9:1。后面的游戏结果完全相似。

生产效率非相关因素

在对游戏结果的分析中,我们发现下面的因素与产出效率基本或根本没有关系:

  • 语言:用 COBOL 和 Fortran 来编码与用 Pascal 和 C 没什么区别。每种语言的结果分布情况跟总体的相似。关于语言观察中唯一例外的是汇编语言:使用汇编语言的选手被使用其他语言的选手远远甩在了后面。(但使用汇编语言的人已经习惯被甩在后面了。)

  • 经验年限:拥有十年编程经验的人并没有超过只有两年经验的人。经验和产出效率完全没有关系,除了在一种语言下少于 6 个月经验的人要差于其他人以外。

  • 缺陷个数:大概有三分之一的选手完成练习后没有产生一个缺陷。作为这样的群体,零缺陷的人通过更精准的工作避免了缺陷对产出效率的惩罚。(事实上,平均来看,较之出现一个或多个缺陷的人来说,他们花费了更少一些的时间来完成练习。)

  • 薪酬:被调查人员的薪酬差异很大。薪酬和产出效率的关系很弱。前一半的薪酬比后一半高出不到百分之十,但他们的产出效率却高出一倍。在各个薪酬水平上的产出效率差异性和整体一样大。

综上,我们或多或少能够预见到这样的结果,大部分现象业已提及。也有出乎意料的结果,我们发现其中一些因素对产出效率具有直接影响。

你可能不想让你的老板知道

我们发现,与高产出效率有正向关联的是一个意想不到的因素:你和谁搭档关系很大。如果你的搭档表现很好,你也会表现不错。如果你的搭档花了很长时间,那么你也差不多。如果你的搭档根本没完成练习,你也不能幸免?平均一对竞赛的搭档在表现上相差 21%。

为何这一点如此重要?因为就算这两人没有在一起工作过,他们都来自同一家组织。(大多数情况下,他们是来自那个组织的唯一一对。)他们在同样的物理环境及公司文化下工作。搭档产出效率几乎相似的现象表明,在所有参赛者中观察到的能力上的巨大差异对于组织内可能就不适用了:两个来自同一组织的人表现会趋于一致。这说明效率最高的人聚集在一些组织中,效率低的则会在另一些组织。软件业先驱 Harlan Mills 在 1981 年预见了这一现象:

倘若程序员产出呈现 10:1 的差异是可以理解的,那么软件组织在产出上的 10:1 差异也是存在的。

我们的研究发现,92 个参赛组织的表现简直是天壤之别。在这个参赛群体中,最好的组织(组织参赛人员的平均产出效率最好)比最差的要快十倍以上。在要求速度的情况下,所有最好组织的参赛选手开发的程序通过了主要的验收测试。

这带来的可不是一丁点儿麻烦。管理人员长期对个体的差异性深信不疑。他们认为这种差异是自然产生的,所以很难去改变。要相信上面提及的集群效应则困难得多。一些公司比另外一些还要糟糕,他们的公司环境及文化不但不能吸引或留住好的人才,更是让真正的人才无法在这种环境下有效工作。

工作环境的影响

事实显而易见,不少公司给开发人员提供的是一个拥挤、嘈杂、纷扰不断的工作环境,让大家整天都充满烦恼。单就这一点,就可以解释为什么工作效率会下降,而好的员工都跳槽去了别的地方。

工作环境的质量直接关系着开发者的效率,这一假设很容易测试。你只需要指派一系列固定的标准任务,类似开发人员做的日常工作,然后观察他们在不同环境下工作的完成情况。编码战争游戏就是按这样的思路设计的。

为了收集工作环境的数据,我们让参与者(在开始练习前)都填写了一份调查问卷,调查他们要完成任务的工作地昀物理环境。我们收集了一些客观数据(比如独立的空间有多大和层高有多少)和一些主观问题答案,譬如“你觉得你的工作环境让你感觉很舒适吗?”和“你的工作环境够安静吗?”然后我们将他们的答案和他们在练习中的表现关联起来。

一种趋势分析的简单方法就是看在练习中表现良好的人(基于一个组合的产出效率参数)身处的工作环境特征,然后去对比那些不好的。我们选择了对比前四分之一和最后四分之一。前四分之一的平均表现是最后四分之一的 2.6 倍。关于环境的关联在表 8-1 中做了总结。

表 8-1 代码战争游戏中最佳表现者与最坏表现者所处的环境

环境因素
处于前 1/4 的参赛者
处于后 1/4 的参赛者

1.你拥有多少独立工作空间?

78 平方英尺

46 平方英尺

2.对安静空间的接受度?

57%是

2g%是

3.对秘密空间的接受度?

62%是

lg%是

4.可以让你的手机静音吗?

52%是

lO%是

5.可以转移你的来电吗?

76%是

lg%是

6.人们是否经常不必要地打扰你?

38%是

76%是

在参赛者中,完成练习最快和最有效率的前四分之一的工作环境与最后四分之一的差异很大。前者的工作空间更加安静、更具私密性、更不受打扰,好了很多。

我们证明了什么

我们展现的这些数据并不能完全证明一个好的工作环境能够帮助大家表现更好。成许仅仅能说明好的人才会流向提供了良好工作环境的组织。这些真的和你有关吗?长远来看,安静、宽敞和注重隐私的环境无论是帮助你现在的团队更高效地完成工作,还是帮助你吸引和留住人才,又有什么区别呢?

如果说我们证明了什么,那就是在工作环境设计上采取弃权政策是一个错误。假如你参加或管理了一个需要靠脑子工作的团队,那么工作环境就是你该关注的事。观察到“朝九晚五在这里啥也完成不了,”然后就将注意力转移到其他事情上,这可远远不够。在正常工作时间,人们居然不能完成工作,这可真是一桩愚蠢的事情。是时候采取行动了。

上一页07 家具警察下一页09 在空间上省钱

最后更新于5个月前

这有帮助吗?