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

06 苦杏素

苦杏素是从杏树里提炼出来的无色液体。在瑞典,超市里就可以买到这样的东西,价格跟杏仁提取物相当。在烘焙时,你可以像使用其他提取物一样使用苦杏素。然而在墨西哥,你花 50 美金只能买到这么一滴,因为它可以“治愈”致命的癌症。事实上,苦杏素不能治愈任何疾病。所有证据都揭示这其实是一个残忍的骗局,但在走投无路的情况下,无论这种说法多么离谱,病人最终还是会接受苦杏素小贩们的说法。处于绝望中的人们是不会理性去看待证据的。

同理,不少管理人员也“足够绝望”,这种绝望让他们很容易成为某种号称能够提高产能的技术苦杏素的受害者:他们买到的技术其实缺乏任何客观证据的支撑。因为需求如此迫切,他们就会忽略对证据的审视。

在睡梦中减肥

一天,我在极度无聊下开始剪报纸上关于能够提升产能 l00%或更多的广告。一会儿我就收集了一大堆。宣传能提升产能的手段真是花样百出,让人吃惊,有课程、打包项目、方法论、书籍、时间安排表、硬件监测器、计算语言、新闻传单等。那天晚上,我搭乘地铁回城时,在《纽约时报》的背面发现了一个广告,上面说“在睡梦中减肥”,跟其他广告真是异曲同工。 -TRL

我们面临不少需要提高产能的压力。这个问题的解决没有简化之道,因为所有的简单手段在之前就已经被尝试和实施过。一些组织仍然会比其他组织做得好很多。我们相信那些做出优越成绩的组织并不是采用了什么特别高级的技术。之所以表现良好,就在于他们做到了更高效的人员管理、改进的办公场所以及企业文化,还有就是实施了一些量化的手段。我们将在后面的第二到第四部分进行讨论。

技术手段未必有效,至少短期来看不能立竿见影,这多少让人有些泄气;而我们提倡的对企业文化的改进又很难运用,而且见效缓慢。最理想的是指望剪下杂志最后几页的一张赠券,附上几千元钞票,寄出去,然后就祈祷着从回信中获得一剂灵丹妙药,它能神奇地帮助产能获得提升。当然,这种灵丹妙药帮不了你什么,可这种不是解决方案的简单方案,比起真正复杂的解决方案,往往更加吸引人。

七宗罪

不能解决问题的简单技术方案带来的假象就像那些诱惑了奥德修斯( Odysseus)的原罪一样,每一项都有着独特的吸引力,却是一无是处的虚假承诺。一旦你迷信这些,就会犹豫着是否该去做那些为建设一个健康企业文化必须付出的辛劳工作。

根据你所从事行业的不同,具体诱惑你的原罪也各有不同。我们从自己熟悉的软件开发领域收集了七种,描述如下,并给出了我们的反馈。

软件管理的七个假象

  • 有一个你不知道的新窍门可以让产能飙升。

反馈:你不可能单纯地傻到对一些基本的东西一无所知。你不停地探寻新方法,尝试可能有用的改进。在你所采用或想要采用的方法中,没有一个能够真正让产能飙升。我们要做的就是让大家能够健康发展:人们愿意全身心参与、去学习、去提高。

在兜售这个点子时,故作高深莫测,采用一种纯粹的心理上的恐吓战术,让你觉得这一神奇创新不容错过。

  • 其他管理者正在收获 100%、200%乃至更多的增长!

反馈:忘了吧!这种典型的神奇工具一般只关注整个生命周期的编码和测试阶段。即使我们拿掉编码和测试,也不能期望 100%的提升,还有分析、讨论、文档、培训、验收、交流和交付需要完成呢!

  • 技术日新月异,你已经过时啦!

反馈:技术确实日新月异,但(回想下高科技幻象)你做的大部分工作并不是真正的高科技。硬件变化确实很大,但软件开发行业却很平稳。我们仍然有很大一部分时间花在低技术含量的需求和文档上。软件业的产能每年也就增长 3%~ 5%,仅仅比钢铁和汽车行业好一点点。

  • 改变程序语言会给你带来巨大提升。

反馈:程序语言很重要,因为它们影响着你怎样去思考一个问题。但如前所述,它们仅仅影响了项目的实施部分。这种被夸大的宣传把一些新的程序语言塑造成了苦杏素。确实,可能用 Java 实现一个新功能比 PHP 好,但在 Java 出现前,已经有其他更好的方法来达到你想做的:针对某类功能的专业快速实现工具。除非你在过去几十年都冬眠去了,否则改变一种编程语言是不会给你带来什么根本变化的。可能给你 5%的提升(不够你一个喷嚏的),不会再多了。

  • 因为库存(backlog)的缘故,你需要马上让产能翻倍。

反馈:关于软件开发库存讨论了太多,依旧是一团迷雾。我们都知道一个项目最后的花费总比开始预期的要多很多。可以乐观地假设,一个今年没有构建的系统(因为我们没有人力了)的花费要比实际构连该系统少花费一半或者更多。这是一个典型的在迷雾般的库存中迷失了的项目,乐观的成本估计只有实际成本的一半,甚至更少。倘若我们知道系统的真正成本,就能看清楚项目的实质:一个经济上的失败之作。项目根本就不应该在库存里,而应该丢到被拒绝的那一堆里。

  • 你自动化了其他所有东西;难道不是要你自动化掉你的软件开发人员吗?

反馈:这是另一个版本的高科技幻象:相信软件开发者能够轻松应付可以自动化的工作。然而,他们的主要工作是通过与人沟通把用户对需求的表述变成正式的程序。对于这些工作,不管我们怎么改变,开发生命周期都是必需的,而且不太可能被自动化解决。

  • 你的员工在巨大的压力下工作得更好。

反馈:他们根本不会——他们更乐于减少压力。

到目前为止,所有这些都是负面的:如果依靠人员会对产能起反作用,采用最新技术来装点系统又不会有什么帮助,那么管理者该怎么办呢?

这就是管理

早年,我还是一名开发人员,有幸在莎伦·温伯格(Sharon Weinberg)管理的项目中工作过。她后来成了科德及日期咨询集团( Codd and Date Consulting Group)的主席。我认为她简直就是启发式管理的活榜样。一个下雪天,我拖着病体搭建着我们那不够完善的系统,准备用户演示。莎伦进来,发现我在控制台前强撑着精神做事。她转身离开,几分钟后,她端着一碗热汤出现了。喝完她给的热汤,我精神一振,然后问她在管理工作如此繁忙的同时,怎么有时间来做这些。她给了我一个招牌式的微笑,然后说:“汤姆,这就是管理。” -TDM

莎伦熟知所有具有良好本能的管理者深谙的道理:管理者的作用不是让大家去工作,而是创造环境,让大家可以顺利开展工作。

上一页05 再谈帕金森定律下一页第二部分 办公环境

最后更新于5个月前

这有帮助吗?