🍊
翻译橙
🍊返回主站🤖参与贡献
  • 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. 第一部分 管理人力资源

02 干酪汉堡,做一个,卖一个

开发的本质完全迥异于生产。然而,开发管理者的思想却通常被生产环境衍生而来的管理哲学所左右。

假设你是一位本地快餐店的老板,那么采用如下任何一条或多条高效生产度量都是合情合理的:

  • 压缩出错率,让机器(“人”这台机器)能够尽量平稳地运转。

  • 对工作上犯错的员工采取严厉手段。

  • 把工人当成是机器上可替换的部件。

  • 优化稳定状态。(根本不用考虑运行是怎样开始的,或者需要怎样去终止运行。)

  • 标准化流程,让一切有章可循。

  • 消灭试验——总部那帮家伙就专门干这事儿。

在快餐行业(或者任何生产环境),这些都是司空见惯的合理手段,但对你来说不是。这种“干酪汉堡,做一个,卖一个”的思维观念在开发领域是致命的。这种做法只能让你的团队士气低落,让他们无法将精力集中到真正的问题上。这种管理风格与开发工作水火不容。

要管理脑力劳动者,你需要与前面走的路背道而驰。我们提出的相反做法会在下面几节详述。

错误任所难免

对大多数脑力劳动者来说,工作偶尔出错再自然不过,也很健康,没什么危害。但总有些教条主义者会把工作中的错误和罪恶联系起来。我们需要采取措施去改变这种态度。

面对一群软件开发经理,我们介绍了一种迭代式设计的策略。这个想法是针对那些天生容易出错的设计的,我们应该彻底抛弃而不是去修复。这种设计活动上的死胡同是我们可以预期的,而为此付出的成本却微不足道,不过就是从头再来,轻装前进。令我们感到惊诧的是,许多管理者觉得这是给他们老板出了一道不可能解决的政治难题:“我们怎么能丢掉公司付钱生产的产品呢?”他们好像更相信我们应该补救这个有缺陷的版本,即使从长远来看,我们可能会付出更多。

营造一个不容许任何失误的氛围会让大家持有戒心。他们不愿去尝试那些有可能变坏的事情。当你试图体系化流程时,当你倾向于墨守成规时,你就在强化这种戒心,于是大家就会人为地被禁止做出关键的战略决策,因为他们害怕犯错。在不允许犯错的规定下,或许平均的技术水平会稳步提高,但团队的社会氛围却会遭受可悲的伤害。

相反的做法是鼓劢大家犯错。你可以不时问问大家遭遇了哪些死胡同,并明确地让大家明白:最佳答案并非是“没有”。当有人说了出来,应该祝贺他们——这是他们应得的。

管理:傻瓜定义

管理的复杂度使得我们很难简单地定义它,但在伦敦的一次专业学术组织大会上,我们遇到的一位资深管理者让这些细微差异变得荡然无存。他用一句话总结了他对这个主题的观点:“管理就是踢屁股。”这等于说管理者负责全盘思考,而他的手下就照章办事。这种想法可能对于制作干酪汉堡会奏效,但在依靠脑力而非体力的环境中是没有用的。在这样的环境,每个人都要带着脑子工作。踢他们的屁股,可能会让大家行动起来,却不可能让他们去创新、创造以及思考。

即使向人们施压可以增加短期产出,长远来看还是无效的:对于所有工作者来说,若是因为他们感到动力不足而需要老板来“弥补”,没有什么比这更让人沮丧的了。

最可悲的是,这种管理手段几乎永远都会让生产过剩。你根本不需要使用严格的度量来促使大家工作——大部分人是热爱他们的工作的。你有时可能需要采取一些手段让大家少工作一会儿,这样就可以做一些更有意义的工作(更多想法参见第 3 章)。

人力商店

在生产环境中,很容易将人当作是机器的零部件。部件磨损了,你可以换个新的。新的部件可以和原来的互换。你定的新部件,无论多少,都不过是数字而已。

很多开发经理持相同态度。他们竭力说服自己:没有人是不可替换的。正是因为他们害怕关键人物会离去,于是强迫自己相信没有所谓的关键人物。管理的本质不就是保证工作正常进行,而不用管个体的去留吗?他们的行为看起来就好像有这么一个奇妙的人力商店,只需拿起电话说:“给我派送一个全新的 George Gardenhyer 过来,但让他不要那么高傲。”

我的一位客户在对一名出色的员工进行薪资评估时,惊讶地发现这个员工想要的并不是涨薪。他说他在家时,常常会灵光一现,想起一些绝妙的主意,但糟糕的互联网连接却让他很是心烦。难道公司就不能帮他在家安装一条网线,再给他买台高性能的工作站吗?公司当然可以。在接下来的几年,公司甚至在这位员工家里帮他建立了一个小型办公室。当然,我这位客户的案例有些不同寻常。要是换做一位洞察力偏弱的管理者,他会怎么做呢?太多的管理者认为工作人员展现其个性是一种威胁。 -TRL

有这么一个案例。老板是一名洞察力不够强的管理者,他对员工的个性表现出极端的受威胁感:他有一位富有才华的员工常年在外到访客户现场,花销自然不少。通过对他报销的分析,显示他在食物上的花销远远超过了其他出差人员——他在食物上的花销超出其他人 50%。在一封愤怒的公开信中,这位老板给这名员工打上了“食物犯罪”的标签。而这位员工的总体花销没有超支,不管他在食物上有多少额外花销,他在其他方面节省了。这名员工并非花的更多,他只是与众不同。

对于盲目尊崇生产世界管理风格的管理者来说,员工的独特个性是一种持续的困扰。人性化的管理者却能认识到正是这种独特性使得项目团队产生了化学反应,是团队充满活力与高效的源泉。这是需要培养的。

稳定的项目濒临死亡

稳定的生产思维对项目工作尤为有害。我们很容易忘记项目生命周期的最终目标就是要结束自己。一个项目唯一的稳定期就是将死之时。除非你正在一个被取消或将要取消的项目中,所有的项目管理关注点都应该投入到开发的动态调整上。然而在一个新项目中,我们衡量员工的价值却使用了稳定状态下的特征:他们写了多少代码或者产出了多少文档。我们对于每个员工在整个开发投入中的切合度关注甚少。

几年前,在我教授一堂企业内部设计课程时,一位高级管理者抓住我,要我评估课堂的学员(他顼目上的员工)。他对一位女士尤为好奇,毫不掩饰对她的质疑:“我看不见她给项目带来的贡献,她不是一个好的开发人员或测试人员,或者任何其他专业人员。”在做了一些调查后,我发现了一个引人注目的事实:在她 12 年的公司生涯中,她所在的项目没有一个不是获得巨大成功的。她的贡献不是很明显,但她所在的项目总是成功了。在课堂观察了她一周,并与她的同事交流过后,我得出一个结论:她就是一个超级催化剂。她的存在使得团队内部更有黏度。她帮助团队成员互相交流和相处,有她的项目会变得更加有趣。当我试图向那位管理者阐述这一理念时,我被震惊了:他居然不知道催化剂这个角色在一个项目中的重要性。 -TDM

催化剂很重要,因为项目总是处于不断变化的状态。一个能够让项目更稳定的人抵得上两个做事的人。

我们只是做事,没时间考虑工作自身

如果分配给你一个任务,你会花多少时间来真正实施这项任务?不可能百分之百。实施之前肯定需要做一些头脑风暴,调研新方法,找到规避一些子任务的方法,阅读相关材料,培训,还有试错。

回首我们作为管理者的那些年,我们都没有正确地认识到这一点。我们都花了太多时间去做事,却没有花足够的时间提出关键问题,“这件事到底该不该做?”稳定阶段的干酪汉堡心态使得我们根本没有去思考这项工作。这种心态会推着我们把百分百的投入放到实施状态。倘若真要为没有思考时间寻找借口,那么这个借口永远都是时间压力——就好像还有什么工作可以在没有时间压力的情况下完成似的。

随着更多利益的介入,思考方法的重要性也显著提高。正所谓“磨刀不误砍柴工”,我们必须学习如何多花时间在思考上,少花时间在实施上。项目需要的投入越夸张,成员就越应该学习如何更好地协作,对这份工作的热爱也会变得更重要。项目越是需要在一个无法完成的固定时间交付,项目团队就越不能缺乏频繁的头脑风暴,或者项目组聚餐之类的活动来帮助团队形成一个统一的整体。

但是,这些都是人文关怀。每个人都知道怎么做,对吗?错。在做事情上我们都是如此的一根筋。我们花费不到 5%的时间在计划、新方法调研、培训、读书、评估、预算、排期、人员安排这一系列活动上:(5%这个数字来自于对系统开发项目的分析,但这个数字涉及的范围应该更广,可能涵盖了所有拿薪水的工作者。)

关于读书的统计结果让人尤为失塑:以软件开发人员的平均水平为例,平均每人没有一本和工作相关的书,甚至没有阅读过一本相关书籍。这种现状让每一个重视质量的人心怀忧虑。对我们这些写书的人来说,简直就是一场悲剧。

上一页01 此时此刻,一个项目正在走向失败下一页03 维也纳在等你

最后更新于5个月前

这有帮助吗?