软件研发效能权威指南 电子工业出版社 txt 电子书 免费 下载地址

在数字化时代，公司的业务都高度依赖信息技术，研发效能已经成为信息科技企业发展的核心竞争力。研发效能在国内还处于快速探索期，还有一系列非常重要的概念需要澄清，方法和实践需要整理，问题和困惑需要解答。本书试图通过洞悉研发效能提升的底层逻辑，全方位、系统地介绍研发效能的全景。我们希望这本书是研发效能领域的百科全书，能够涵盖效能提升全生命周期的方方面面，在精心设计的逻辑结构组织下，能够对效能实践、效能工具平台、效能度量方法，以及各个行业典型案例等进行全面又有深度的解读。我们希望通过本书帮助更多在研发效能领域持续探索的企业和同行，为软件工程在国内的持续发展做出一点点贡献。

目 录 第一篇 概 述 篇 第1章 研发效能概述 2 1.1 研发效能的定义、目标及解决的问题 4 1.2 研发效能的实践框架 7 1.3 研发效能的实施策略 13 1.3.1 研发效能实施过程中的常见困境 14 1.3.2 明确你在研发效能提升中所扮演的角色 15 1.3.3 清楚应该做什么和不能做什么 16 1.3.4 不躺平、不内卷，行稳致远 26 1.4 研发效能的核心价值观与常见误区 26 1.4.1 研发效能的核心价值观 26 1.4.2 研发效能提升的误区 28 第二篇 研发效能实践篇 第2章 需求及敏捷协作领域实践 33 2.1 业务探索 34 2.1.1 业务探索概述 35 2.1.2 业务探索的价值 35 2.1.3 业务探索的实现 35 2.1.4 业务探索的误区 52 2.2 精益需求 53 2.2.1 精益需求概述 53 2.2.2 精益需求的价值 54 2.2.3 精益需求的实现 54 2.2.4 案例研究：的精益需求 59 2.2.5 精益需求的误区及解决方法 61 2.3 实例化需求 62 2.3.1 实例化需求概述 62 2.3.2 实例化需求的价值 63 2.3.3 实例化需求的实现 63 2.3.4 实例化需求实践误区 66 2.4 敏捷协作 67 2.4.1 敏捷协作概述 68 2.4.2 敏捷协作的价值 68 2.4.3 敏捷协作的实现 68 2.4.4 案例研究：360评估系统研发团队的敏捷之路 81 2.4.5 敏捷协作的误区 83 2.5 可视化管理 84 2.5.1 可视化管理概述 84 2.5.2 可视化管理的价值 85 2.5.3 可视化管理的实现 85 2.5.4 案例研究：某大型金融机构的可视化管理 89 2.6 规模化敏捷交付 91 2.6.1 规模化敏捷交付概述 91 2.6.2 规模化敏捷交付的价值 91 2.6.3 规模化敏捷交付的实现 91 2.6.4 规模化敏捷实例 95 2.6.5 案例研究：购物App千人敏捷实例 106 2.6.6 规模化敏捷的误区 108 第3章 开发领域实践 109 3.1 分支模型 111 3.1.1 分支模型概述 111 3.1.2 分支模型的价值 111 3.1.3 版本控制系统中的基础概念 111 3.1.4 常见的分支模型 112 3.1.5 分支模型的选择 117 3.1.6 案例研究：某大型国有银行分支实践 119 3.1.7 分支模型使用的误区 120 3.2 本地开发 121 3.2.1 本地开发概述 121 3.2.2 本地开发的过程 122 3.2.3 本地开发面临的问题及挑战 123 3.2.4 高效本地开发 124 3.2.5 一线互联网公司本地开发示例 126 3.2.6 小结 129 3.3 云端开发 129 3.3.1 云端开发概述 130 3.3.2 云端开发的价值 130 3.3.3 云端开发的实现 131 3.3.4 案例研究：基于微服务的云端开发 134 3.3.5 云端开发的误区 138 3.3.6 小结 138 3.4 代码评审 138 3.4.1 代码评审概述 139 3.4.2 代码评审的价值 139 3.4.3 代码评审的类型 139 3.4.4 代码评审的内容 140 3.4.5 代码评审的实践 141 3.4.6 案例研究：某一线互联网公司的代码评审案例 142 3.4.7 代码评审的误区 144 3.5 单元测试 144 3.5.1 单元测试概述 145 3.5.2 单元测试的价值 146 3.5.3 单元测试的示例 146 3.5.4 单元测试的原则 148 3.5.5 测试替身 149 3.5.6 案例研究：某一线互联网企业的单元测试应用案例 150 3.5.7 单元测试的常见误区 151 3.6 代码扫描 151 3.6.1 代码扫描概述 151 3.6.2 代码扫描的价值 152 3.6.3 代码扫描的原理 152 3.6.4 代码扫描的应用场景 152 3.6.5 案例研究：某一线互联网公司的代码扫描 154 3.6.6 代码扫描的误区 157 3.6.7 代码扫描的展望 158 3.7 编译构建 159 3.7.1 编译构建概述 159 3.7.2 编译构建的价值 161 3.7.3 编译构建的实现 161 3.7.4 案例研究：基于distcc的分布式编译平台改造 165 3.7.5 编译构建的误区 167 3.8 架构设计 168 3.8.1 架构设计概述 168 3.8.2 架构设计的价值 169 3.8.3 架构设计的实现 169 3.8.4 常见的架构模式 173 3.8.5 架构模式对研发效能的影响 177 3.8.6 案例研究：S公司的微服务“失败”之旅 178 3.8.7 架构设计的误区 182 3.9 低代码应用 183 3.9.1 低代码概述 183 3.9.2 低代码平台7个核心价值 183 3.9.3 低代码平台用户评价指数 184 3.9.4 低代码平台三个核心目的 185 3.9.5 低代码的实现 186 3.9.6 案例研究：某公司低代码研发效能实践 187 3.9.7 低代码平台应用的误区 193 3.10 测试驱动开发 194 3.10.1 测试驱动开发概述 194 3.10.2 测试驱动开发的价值 194 3.10.3 测试驱动开发的实现 195 3.10.4 案例研究 196 3.10.5 测试驱动开发的困境 199 第4章 测试领域实践 200 4.1 测试环境管理 202 4.1.1 测试环境管理概述 202 4.1.2 测试环境管理的价值 202 4.1.3 测试环境管理的实现 203 4.1.4 测试环境管理的误区 208 4.2 自动化验收测试 208 4.2.1 自动化验收测试概述 208 4.2.2 自动化验收测试的价值 209 4.2.3 自动化验收测试的实现 209 4.2.4 案例研究：某头部互联网视频App的自动化验收测试 211 4.2.5 自动化验收测试的误区 212 4.3 自动化接口测试 214 4.3.1 自动化接口测试概述 214 4.3.2 自动化接口测试的价值 214 4.3.3 自动化接口测试的实现 215 4.3.4 案例研究：某能源公司的自动化接口测试 217 4.3.5 自动化接口测试的误区 218 4.4 测试数据管理 218 4.4.1 测试数据管理概述 218 4.4.2 测试数据管理的价值 218 4.4.3 影响测试数据管理的因素 219 4.4.4 测试数据管理的框架 220 4.4.5 测试数据使用效率 223 4.4.6 测试数据管理的挑战 223 4.4.7 案例研究：基于多产品、多环境和多测试场景的测试数据管理 224 4.5 性能测试 225 4.5.1 性能测试概述 225 4.5.2 性能测试的价值 226 4.5.3 性能测试的实践方式 227 4.5.4 性能测试的实践误区 228 4.6 全链路压测 229 4.6.1 全链路压测概念 229 4.6.2 全链路压测的基建 230 4.6.3 全链路压侧实践案例 234 4.7 安全测试 235 4.7.1 安全测试概述 235 4.7.2 安全测试的价值 236 4.7.3 安全测试的落地 236 4.7.4 安全测试的误区 240 4.8 精准测试 240 4.8.1 精准测试概述 241 4.8.2 精准测试的价值 242 4.8.3 精准测试的实践 242 4.8.4 精准测试的趋势 247 4.8.5 精准测试的误区 248 4.9 测试中台 249 4.9.1 测试中台的背景 249 4.9.2 开发人员做测试遇到的问题 249 4.9.3 测试中台赋能测试 251 4.9.4 测试中台的全局架构 253 第5章 CI/CD领域实践 255 5.1 持续集成 257 5.1.1 持续集成概述 257 5.1.2 持续集成的价值 258 5.1.3 持续集成的实现 258 5.1.4 案例研究：“这不能称为持续集成” 260 5.1.5 持续集成的误区 261 5.2 持续交付 262 5.2.1 持续交付概述 262 5.2.2 持续交付的价值 264 5.2.3 持续交付的实现 265 5.2.4 案例研究：逐特性发布 266 5.2.5 持续交付的误区 267 5.3 变更管理 268 5.3.1 变更管理概述 268 5.3.2 变更管理的价值 268 5.3.3 变更管理的实现 269 5.3.4 变更管理的误区 281 5.3.5 案例：Meta生产变更案例 282 5.4 部署自动化 283 5.4.1 部署自动化概述 283 5.4.2 部署自动化的好处 284 5.4.3 部署自动化的实施 284 5.4.4 案例研究：某微服务平台产品部署自动化流程 288 5.5 制品管理 291 5.5.1 制品管理概述 291 5.5.2 制品管理的价值 292 5.5.3 制品管理的实现 292 5.5.4 案例研究 306 5.5.5 制品管理的误区 311 5.6 发布策略 311 5.6.1 发布策略概述 311 5.6.2 发布策略的价值 312 5.6.3 发布策略的实现 312 5.6.4 案例研究 321 5.6.5 发布策略的误区 324 5.7 数据库变更版本管理 325 5.7.1 数据库变更管理概述 325 5.7.2 数据库变更管理的价值 326 5.7.3 数据库变更管理的实现 327 5.7.4 数据库变更管理案例 339 5.7.4 数据库变更管理的误区 346 5.8 配置参数管理 347 5.8.1 配置参数管理概述 347 5.8.2 配置参数管理的价值 348 5.8.3 配置参数管理的实现 348 5.8.4 案例研究：别让配置参数管理拖流水线建设的“后腿” 352 5.8.5 配置参数管理的误区 353 第6章 运维领域实践 354 6.1 云原生基础设施 355 6.1.1 云原生基础设施概述 356 6.1.2 云原生基础设施的价值 356 6.1.3 云原生基础设施的实现 357 6.1.4 云原生的技术演进趋势 359 6.1.5 云原生基础设施的达成路径 363 6.2 可观测性 366 6.2.1 可观测性概述 366 6.2.2 可观测性的价值 367 6.2.3 可观测性的实现 367 6.2.4 案例研究：腾讯互娱可观测性平台实践 370 6.3 全景监控 372 6.3.1 全景监控概念 373 6.3.2 全景监控的价值 373 6.3.3 全景监控的实现 374 6.3.4 可观测性与监控 378 6.3.5 案例研究：某人工智能公司在微服务下的全景监控方案 379 6.3.6 全景监控的误区 386 6.4 智能运维 386 6.4.1 AIOps概述 387 6.4.2 AIOps的发展历程 387 6.4.3 AIOps的知识体系 388 6.4.4 AIOps实施的关键技术 388 6.4.5 AIOps的应用场景 391 6.4.6 AIOps的常见误区 392 6.5 混沌工程 393 6.5.1 混沌工程概述 393 6.5.2 混沌工程的价值 394 6.5.3 混沌工程的实现 394 6.5.4 案例研究：Netflix公司的混沌工程实践 400 6.5.5 混沌工程的误区 401 6.6 ChatOps 403 6.6.1 ChatOps概述 403 6.6.2 ChatOps的价值 404 6.6.3 ChatOps的实施核心技术 404 6.6.4 ChatOps的应用场景和未来 407 6.6.5 案例分享 408 6.6.6 ChatOps的常见误区 410 第7章 运营领域实践 411 7.1 运营领域实践概述 411 7.2 运营领域实践的价值 412 7.3 运营领域实践的实现 412 7.4 案例研究：金融行业的运营实践 415 7.5 运营领域实践的常见误区 415 第8章 组织和文化领域实践 417 8.1 敏捷组织 418 8.1.1 敏捷组织概述 418 8.1.2 敏捷组织的特征 419 8.1.3 敏捷组织的实现 423 8.1.4 敏捷组织的误区 427 8.2 故障复盘文化 428 8.2.1 谈故障复盘前，先来看看航空业的安全性 428 8.2.2 复杂系统故障的特点 429 8.2.3 故障复盘的概念 429 8.2.4 故障复盘的价值 430 8.2.5 故障复盘背后的底层逻辑 430 8.2.6 故障复盘的步骤与实践 432 8.2.7 故障复盘常见的误区与应对策略 434 8.3 工程师文化 435 8.3.1 工程师文化概述 436 8.3.2 工程师文化的特征 436 8.3.3 工程师文化的实现 436 8.3.4 工程师文化的案例 437 8.3.5 工程师文化的误区 440 第三篇 研发效能平台篇 第9章 研发效能平台的“双流”模型 442 9.1 传统单点研发效能工具平台面临的挑战 442 9.2 “一站式”和“一键式” 443 9.3 研发效能平台的“双流”模型 444 9.4 总结 446 第10章 自研工具体系 447 10.1 敏捷协作域工具 449 10.1.1 什么是敏捷协作 449 10.1.2 敏捷协作域工具的价值 451 10.1.3 敏捷协作域工具的实现 451 10.1.4 度量与持续改进 463 10.1.5 敏捷协作域工具的误区 464 10.1.6 中农网的多产品线敏捷研发案例 464 10.2 代码域工具 470 10.2.1 代码域工具概述 470 10.2.2 代码域工具的价值 470 10.2.3 代码域工具的实现 471 10.2.4 代码域工具建设的误区 474 10.3 测试域平台和工具 475 10.3.1 测试域平台和工具概述 475 10.3.2 测试域平台和工具的价值 476 10.3.3 测试域工具的实现 477 10.3.4 未来测试域平台和工具前瞻 485 10.4 CI/CD域工具 486 10.4.1 CI/CD域工具概述 486 10.4.2 CI/CD域工具的价值 487 10.4.3 CI/CD域工具的实现 488 10.4.4 CI/CD域工具的发展方向 493 10.5 运维域工具 494 10.5.1 运维域工具概述 494 10.5.2 运维域工具的价值 495 10.5.3 运维域工具的实现 496 10.5.4 X-Ops文化的起源与盘点 497 10.5.5 行业主流运维域工具盘点 498 10.5.6 运维域工具的发展方向 501 10.6 移动研发平台 502 10.6.1 移动研发平台概述 503 10.6.2 移动研发平台的价值 503 10.6.3 移动研发平台的实现 505 10.6.4 移动研发平台的发展方向 512 10.7 一体化协同平台 513 10.7.1 一体化协同平台概述 514 10.7.2 一体化协同平台的价值 518 10.7.3 一体化协同平台的实现 519 10.7.4 一体化协同平台发展方向 523 10.8 代码智能化工具 524 10.8.1 代码智能化工具概述 525 10.8.2 代码智能化工具的价值 525 10.8.3 代码智能化工具的实现与案例 526 10.8.4 总结 533 第11章 开源工具集成 535 11.1 开源工具集成概述 535 11.2 工具集成的价值 536 11.3 开源工具集成的实践 536 11.4 案例研究 538 第四篇 研发效能度量篇 第12章 研发效能度量 546 12.1 度量框架 548 12.1.1 框架概述 548 12.1.2 框架解读 549 12.1.3 框架实现 550 12.1.4 框架应用案例 551 12.2 度量指标体系 552 12.2.1 度量指标体系概述 552 12.2.2 度量指标体系的价值 552 12.2.3 指标体系的设计 552 12.2.3 案例研究：国内某互联网企业的效能指标体系 558 12.2.4 指标体系设计的误区 559 12.3 效能分析 559 12.3.1 效能分析概述 560 12.3.2 效能分析模型 560 12.3.3 案例研究——需求交付周期下钻分析 564 12.3.4 效能分析的误区 566 12.4 度量平台 567 12.4.1 整体架构 567 12.4.2 开源工具与平台 570 12.5 专项度量分析 571 12.5.1 需求价值流分析 571 12.5.2 代码度量分析 578 12.5.3 代码评审度量分析 586 12.6 度量的成功要素 597 12.6.1 把度量引导到正确的方向上来 602 12.6.2 结语 602 第五篇 效能提升案例篇 第13章 效能提升优秀案例 604 13.1 某商业产品效能提升案例 604 13.1.1 研发效能挑战 604 13.1.2 整体改进思路 604 13.1.3 全面效能提升实践 606 13.1.4 全流程数字化度量 627 13.1.5 整体收益 629 13.2 腾讯会议后台研发效能提升之路 630 13.2.1 腾讯会议研发效能建设前概况 630 13.2.2 腾讯会议研发效能改进历程 632 13.2.3 腾讯会议研发效能建设总结与思考 645 13.3 微众银行研发效能建设实践 649 13.3.1 研发效能建设初期 649 13.3.2 研发效能度量平台 649 13.3.3 研发效能数据分析 651 13.3.4 研发效能实践 655 13.3.5 研发效能文化建设 658 13.3.6 实施效果总结 659 13.4 宁波银行规模化敏捷试点案例 660 13.4.1 选型 660 13.4.2 诊断 660 13.4.3 开方 661 13.4.4 治理 663 13.4.5 持续 671 13.5 七场战役，细说长沙银行的数字化研发管理转型之路 672 13.5.1 第一场战役：新核心攻坚战 673 13.5.2 第二场战役：部落划分遭遇战 674 13.5.3 第三场战役：过程透明接触战 678 13.5.4 第四场战役：业务渠道整合战 684 13.5.5 第五场战役，全行协同联合战 686 13.5.6 五场战役的联合成果 689 13.5.7 面向未来，第六、七场战役以价值为先 690 13.5.8 结语 691 13.6 招商银行精益转型之路 691 13.6.1 精益管理体系演进历程 691 13.6.2 核心管理体系和工程体系 693 13.6.3 DevOps工具链设计过程 695 13.6.4 DevOps流水线建设案例 700 13.7 深圳某银行研发效能建设实践 702 13.7.1 选型 702 13.7.2 诊断 703 13.7.3 开方 704 13.7.4 结语 715 13.8 某大型保险集团：组织级效能团队+一线研发团队的研效协同改进实例 715 13.8.1 项目概述 715 13.8.2 效能痛点 717 13.8.3 前期建设情况 717 13.8.4 组织建设：双层结构，保障方向与步调一致 718 13.8.5 试点策略：点面结合，验证共性 718 13.8.6 效能度量体系：由少到多逐步推进 720 13.8.7 改进实践 723 13.8.8 展望 727 13.9 东风集团：DevOps赋能车企第二曲线持续增长 ——嘉为蓝鲸助力东风集团搭建DevOps能力体系 728 13.9.1 万事俱备，只欠东风：DevOps建设前状况 729 13.9.2 东风浩荡，万象更新：DevOps建设过程 730 13.9.3 东风化雨，润泽四方：DevOps建设后成果 741 13.9.4 结语 747 参考文献 748

茹炳晟，业界知名实战派软件研发效能和软件质量双领域专家，硅谷研发效能理念在国内的技术布道者，现任腾讯Tech Lead，腾讯研究院特约研究员，腾讯技术委员会委员。“研发效能宣言”发起人，IT图书年度影响力作者，IT技术领导力互联网行业测试领域领军人物，中国商业联合会互联网应用技术委员会智库专家；多本技术畅销书作者，业界第一本研发效能图书《软件研发效能提升之美》作者，并主持编写多本软件技术白皮书；团体标准“软件研发效能度量规范”核心编写专家；国内外各大软件技术峰会的联席，技术委员成员和出品人

暂无出版社相关信息，正在全力查找中！

暂无相关书籍摘录，正在全力查找中！

在线阅读地址：软件研发效能权威指南 电子工业出版社在线阅读

在线听书地址：软件研发效能权威指南 电子工业出版社在线收听

在线购买地址：软件研发效能权威指南 电子工业出版社在线购买

暂无原文赏析，正在全力查找中！

编辑推荐

"1.作者阵容强大：本书有茹炳晟和张乐领衔主编，由48位研发效能各个领域的专家共同撰写。

2.作者背景资深：参与编写的作者都在研发效能领域深耕多年，具有丰富的、可落地的实践经验。

3.内容系统全面：全书分为5篇共13章，包括近80个小节，每个小节都详细讲解了研发效能领域的某种具体方法、具体实践点或技术点。

4.实践性强：每个小节都概括了核心观点，都有实现细节和落地指南，大部分小节都有配套的案例。另外，通过银行、保险、互联网、传统制造等领域的9个效能提升案例，给大家提供了效能提升的参考路径。"

媒体评论

"1.作者阵容强大：本书有茹炳晟和张乐领衔主编，由48位研发效能各个领域的专家共同撰写。

2.作者背景资深：参与编写的作者都在研发效能领域深耕多年，具有丰富的、可落地的实践经验。

3.内容系统全面：全书分为5篇共13章，包括近80个小节，每个小节都详细讲解了研发效能领域的某种具体方法、具体实践点或技术点。

4.实践性强：每个小节都概括了核心观点，都有实现细节和落地指南，大部分小节都有配套的案例。另外，通过银行、保险、互联网、传统制造等领域的9个效能提升案例，给大家提供了效能提升的参考路径。"

书籍介绍

在数字化时代，公司的业务都高度依赖信息技术，研发效能已经成为信息技术企业发展的核心竞争力。

研发效能在国内还处于快速探索期，有一系列非常重要的概念需要澄清，有许多方法和实践需要整理，还有不少问题和困惑需要解答。

《软件研发效能权威指南》试图通过洞悉研发效能提升的底层逻辑，全方位、系统化介绍研发效能的全景。我们希望这本书是研发效能领域的“百科全书”，能够涵盖效能提升全生命周期的方方面面，在精心设计的逻辑结构组织下，能够对效能实践、效能工具及其平台、效能度量方法，以及各个行业典型案例等进行全面而有深度的解读。

我们希望通过本书帮助更多在研发效能领域持续探索的企业和同行，为软件工程在国内的持续发展做出一点点贡献。

• 作者： wolfwind 发布时间：2024-03-17 10:01:35

  纸的质量不错，还有双语文字。故事的趣味性一般吧

• 作者： 悠悠我心 发布时间：2023-04-21 14:24:39

  专门看了度量、效能相关的内容

• 作者： 通灵顽石 发布时间：2023-05-04 09:51:30

  代标《民法典婚姻家庭编司法解释（一）理解与适用》，“离婚”一章研读。最近过得非常难，一边上班（一周骑车通勤7小时，以至于我那么爱车的一个人，现在看到自行车就恶心想吐），一边读书（必要性无需多言），一边健身（健身是保证肉体存续的唯一方法），还要一边帮父母打外祖父和后老伴离婚的官司（父母不学法典，光着急，我妈直接发病时大吵大叫，直接拿来抖音上的律师要网上咨询）。我爸妈本来还说要我出律师费，被我拒绝了。

• 作者： lopin 发布时间：2024-01-17 17:02:27

  这一本比那本《软件研发效能提升实践》更厚，但也更加全面体系，原本以为两本书的内容会重复很多，实则这一本会更加专业一点，整体上值得好好品读，再结合自己企业的实际情况加以借鉴实践，此类书好与不好主要还是要看自己利用和实践的效果如何了

• 作者： NoNo姐 发布时间：2022-10-02 23:23:18

  哈哈哈，小学3年级的记忆

• 作者： 流沙 发布时间：2023-06-12 20:38:42

  可以当做一个Bok来看

• 论经济的长期发展－今日果，十年因

  作者：疯子刄 发布时间：2016-06-26 00:24:55

  这本书写于1999-2002年，作者进行了全球旅游，并细心观察了各种的经济情况。最近，英国退欧投票成功，就能在该书里找到原因：1.欧元区的注定失败 2.英国的政治传统。今日果，十年因。阅读这本写于15年前的书，你大概就能明白为了欧洲现在正在衰弱，中国为何能崛起，中东为何还是动乱，印度为何还是发展缓慢，非洲为何还未现代化。

  爱尔兰：发展对外贸易，积极开展本国市场，并将自己定位成工业制造、软件开发、通信设备和金融服务的中心。

  - 制订儿童的长期计划，具备编写软件和涉外谈判的能力。

  - 低税收，投资者／艺术者／工业享受税收优惠。

  - 政府开明。

  - 从侨民获得巨大的收益。

  英国：国立衰退

  - 原因在于权力下放，地方政府和中央政府的对立。

  - 狭隘自闭的思维。

  - 英国不加入欧元区，一方面想分享欧洲一体化带来的繁荣；与此同时，又想保持一定的独立性。

  投资建议：发现国家自己很难做而有些公司却可以做得很好的事情。比如壳牌石油公司。

                      投资于只在英国做生意的英国公司。不管英国经济情况如何，它都能持续繁荣。

                      通过英格兰的历史背景投资到它原来的殖民地国家。

                      购买便士股票。如疯牛病期间的肉品加工公司。

                      同时卖空英国股指期货进行套期保值。

                      自然资源长期在数量上是有限的，因此价格会增长。

  土耳其和巴尔干半岛：

  - 土耳其人和库尔德人（20%）的冲突。

  - 东边国家动乱。

  - 金融秩序混乱。银行缺乏透明度。

  - 货币持续贬值。

  - 繁琐的规章制度。保守、死板、排斥个体、排斥商业。

  - 土耳其人口年轻化，产品高质量、低价格。

  投资建议：只在大盘彻底崩溃的时候，适当买进一些会有盈利预期的股票。

  德国：不看好长期经济发展

  - 缩小贫富分化，主要方式是征税或者增加股票证券持有人的负担，但税收增加了中产阶级的负担，工人罢工。

  - 工人反抗税收政策，工会要求增加工资，但工资增长率超过了生产力的增长

  - 向富人征税只能解决短期的社会经济问题，长期问题远未得到解决。？？

  奥地利：

  - 与德国经济联系密切

  匈牙利：

  - 税收规避和极高的边际税率互为因果。

  - 高额的工资税使劳动力成本增加了50%。

  中欧国家在前苏联解体后，仍受中央集权的影响过深，或者感到迷茫，加之缺乏领导经验，不得不时常改变政策。

  中亚国家：蕴涵着丰富的矿产资源，但稳定长远法定的信贷基础，关税也随意更改。这些国家必须具备公正无私的法律体系、清正廉洁的政府官员以及稳定统一的货币政策。

  中国：考虑购买一家在上海新区有大量土地储备的地产公司（天才！！！）、一家橡胶轮胎工厂、一家器具制造商和一家玻璃公司。因为这些从事基础行业的公司最能迎合中国崭露头角的中产阶级日益提高的对生活质量的需求。

  投机建议：投资那些定居海外华人开设的企业。

                 所有的B股都买一点，并且长期持有。5年、10年或者15年以后。

  韩国：

  - 北部、东部多山，南部使宽阔的平原。人口高度聚集。1／4居住在军事分布线30英里的首尔。

  - 韩国女性人口短缺，女性价值大大提升。

      - 投资建议：女性可以按自己意愿消费，提高生活质量的烤箱、洗碗机、装修材料和家具会更有销路，还有婴儿护理这样的服务。但由于推迟结婚年龄，并不看好婚礼服装店。

      - 看好健身和SPA店。因为有追求的年轻女性将会保持更长时间的独身，以获得更好的教育，并且挑选丈夫。

      - 未来一代的儿媳妇不会对照顾老人热心，生产速冻食品和方便食品的公司的价值将会上涨。

      - 做女人更划算！！

  - 政府干预政策卓有成效，出口退税、进口壁垒以及对特定产业的政府扶持。劳动力富有纪律性。

  - 和日本相似，有美国大力经济支持和积极的货币政策。

  - 韩国模式弱点：过高的资产负债比率，庞大的外债，效率低下的金融体系（和中国现在情况一样，贷款给僵尸企业）。

  - 旅游业发展不足，另一项有潜力的投资是横穿首尔的汉江北岸的土地。

  俄罗斯：新贵巧取豪夺，没有法律基础。

  - 西伯利亚资源丰富，日本的资金和中国的劳动力移向西比利亚。

  - 保护费

  - 将大量资金用于国家的门面建设，而不是用在下层基础建设和生产设备的制造上。（才不是说中国，哼！）

  斯堪地纳维亚：危险的高福利 挪威／瑞典／芬兰／丹麦

  - 电子银行发达

  - 高福利、长假期，高税收

  - 出生率低，移民多，宗教冲突

  投资建议：小银行太多，必须整合合并。同时因为电子银行发达，会成为大型欧洲银行购买的候选对象。

                      不看好房地产，因为大量银行出租其房屋。

  法国：官僚主义，社会制度和高社会福利，会扼杀经济的长期增长。

  意大利：沉重的外债没有用来提高生产能力。

  - 成立欧元区的时候，和欧元的兑换汇率比较低，所以市场竞争力强。

  - 人口老龄化。

  不相信欧元会成功：欧元区国家必须都有相同的经济基础，然后很多国家伪造数据和报告。当经济形势滑坡，这些国家马上会显露出来。

  投资建议：银行业，军事和航空，消费品，独家胜地，自然资源，欧洲的石油公司比美国公司有优势，因为美国政府禁止美国公司与很多国家的石油生意：利比亚，尼日利亚，伊朗核伊拉克。

  非洲：靠资源生产为主。

  法国殖民地的14个国家使用非洲金融共同体法郎。

  - 军事独裁。

  - 产业结构单一，资源生产为主。

  - 政府滥发货币。

  - 腐败的政府组织。

  - 保护主义。

  - 宗教、种族冲突。

  中东：石油资源丰富，且投资了很多西方世界的权益资本中。

  印度：

  - 贸易保护论和反外国情绪。受英国殖民影响。

  - 能源短缺。

  - 缺乏高等教育学校。

  墨西哥：腐败和低效率

• 令人遗憾的辞源第三版

  作者：huxw06 发布时间：2020-04-23 13:58:39

  我买的是优盘版。能出一个优盘版，比只有纸质版，无疑是个很大的进步，而且优盘版还很贴心的能回溯到书页原文，有生成引文的功能，还可以在查询内容中直接复制字词查询。然而仍然有不少遗憾。

  先说内容上的。

  一、没有甲骨文或者金文，篆书的字形。作为古汉语辞书，这个要求不算过分（例如日本人编的角川新字源）。这与辞源前言所述精神也并不矛盾。（修改：现在还有其他的专门的工具书能查到这些字形，所以编者选择不去做这个事情，专注于字词的最早出处及其释义，也没问题。然而即便是从这个角度出发，早期文字的研究成果仍然不应被忽视，这就是下面要说的第二点。）

  二、与上一个问题相关的，有些甲骨文的较新的研究成果，没有反映出来。例如“蕡”，传统解释是大或者果实大的样子。于省吾根据甲骨文考古学的结果，在泽螺居诗经新证（1982年出版）中指出本意是斑驳貌，诗经中“有蕡其實”就是取此义。这个解释也十分符合逻辑，果实色彩斑驳也暗指已成熟。于省吾的解释已经被程俊英蒋见元的诗经注析采纳。原来的传统解释只是望文生义而已，这个在诗经的解释中很常见，毕竟是最早的文本，古人也没多少可参考的资料。辞源第三版中仍然采用“果木结实大”的解释，并且就用的“有蕡其實”作为例句。虽然只是说这一个字，但冰山一角也可以想见这几十年积攒的甲骨文成就（仅说字义方面）很可能被无视了，令人惋惜。作为古汉语权威工具书，将文字方面可靠的新成果反映进来（其实一点也不新了！而且相关资料很容易寻得)，这个应该是编者的义务吧，可不能用一句“遵循传统解释”之类的话做借口。

  三、辞源全书使用繁体字，但优盘检索时也认简体字，却不显示对应简体字形。例如检索“干”或“乾”，都出来“干”，“乾”，“幹”，“榦”，那么哪些字或者义项对应简化字“干”或“乾”呢？无论是优盘版还是“纸书溯源”里都看不出来。即便说辞源是给看古书的人用，可是现在也有很多古书出了简体版，为何不能稍微“屈尊”一下，把简体字形附上呢？

  四、字词解释缺少自封闭性（self-containdness)。例如香榧的“榧”，解释中说“子可食，療白蟲。見廣韻。”，这个“白蟲”是什么虫呢？说见廣韻，那么查了廣韻，还是这一句。无论是辞源还是广韵里，都找不到白蟲的解释。是泛指白色虫子，白蚁，还是说编者也搞不明白就把广韵照搬来了呢？如果确是泛指，那么就应该改成“白色的虫子”，或者“色白之虫"，毕竟辞源大部分解释是用的白话，没必要在此强作文语而以辞害义。

  五、词义的选择缺少审查。“閣閣”与“橐橐”的例句都选自诗经小雅斯干的“約之閣閣，椓之橐橐”。辞源对“橐橐”的解释是拟声，对“閣閣”的解释是“束物監牢貌”。可是显然这里两者都是拟声，而“閣閣”的意思就是绳子勒紧发出的声音，当然也可以借此表明绑得紧牢。辞源在例句后又说根据马瑞辰毛诗通释，“閣為鞈之假借⋯⋯”，这就是穿凿附会了。判断这些只需要常识。例句后还引了孔传的“閣閣，猶歷歷也”，而辞源对“歷歷”的解释只有“分明貌”。我看得很糊涂。我希望辞源是词典，而不是“集释”。

  六、有的词解释不清。例如“家数”，解释为“古代學術文章注重師法傳授，凡一脈相沿，信守家法的，稱爲家數。”那么到底家数是有师承的流派，还是说必须得有家族传承的才算呢？这个解释在这一点上含糊不清。这个毛病是句与句之间逻辑关系不清造成，可以说是汉语常出现的典型问题，无论古今。编者们作为文字专家，理应在这方面有所觉察。

  再来说说这个优盘版的软硬件问题。

  一、这个u盘只能在windows上使用，感觉很不方便。是不是有什么技术上的困难不能在其他系统里使用，还是就是懒得做了？

  二、只用了一两分钟就开始发烫。

  三、纸书溯源的窗口太小，一眼只能看不到半页，还需要下拉，而且下拉延迟感明显。这个非常影响纸书溯源的实用价值。窗口小可能是为了防盗版，怕被人截屏？可是这一点程序员们不难攻破吧，只要设置自动下拉两次分别截屏，然后在固定位置裁剪拼接就行了。考虑到纸书溯源一次只能看两页，而且还有水印和序列号，这种小窗口防盗版的方式（如果确实是为了防盗版），就多此一举而且十分影响用户体验。至于延迟，和上面说的发热一样，可能是u盘质量不够好吧。

  四、保修只有一年！既然是作为纸质书的替代版，为什么不终身保修呢？或者终身换新，只付u盘成本费，也是应该的吧，出版社有任何损失吗？就上面说的这个质量，让人不禁担心能用多久。

  五、另外，为什么不做app呢？又是怕盗版吗？我希望商务印书馆能有更大的担当，防盗版可以采用法律手段，而不必采用影响读者体验的方式。