读书笔记：人月神话
人月神话 40周年中文纪念版 The Mythical Man-Month
第1章 焦油坑
史前史中，没有别的场景比巨兽在焦油坑中垂死挣扎的场面更令人震撼。上帝见证着 恐龙、猛犸象、剑齿虎在焦油中挣扎。它们挣扎得越是猛烈，焦油纠缠得越紧，没有任何猛 兽足够强壮或具有足够的技巧，能够挣脱束缚，它们最后都沉到了坑底。
过去几十年的大型系统开发就犹如这样一个焦油坑，表面上看起来好像没有任何一个单独的问题会导致困难，每个都能被解 决，但是当它们相互纠缠和累积在一起的时候，团队的行动就会变得越来越慢。
编程系统产品
编程产品（Programming Product）。这是可以被任何人运行、 测试、修复和扩展的程序。经验数据表明，相同功能的编程产品的成本，至少是已经过测试的程序 的三倍。
编程系统（Programming System）中的一个构 件单元。可以用 来组装和搭建整个系统。因为一些 意想不到的交互会产生许多不易察觉的 bug，测试工作将会非常耗时，因此相同功能的编程 系统构件的成本至少是独立程序的三倍。
编程系统产品（Programming Systems Product）。和以上的所 有的情况都不同的是，它的成本高达九倍。然而，只有它才是真正有用的产品，是大多数系 统开发的目标。
职业的乐趣
首先是一种创建事物的纯粹快乐。
其次，快乐来自于开发对其他人有用的东西。
第三是整个过程体现出魔术般的力量——将相互啮合的零部件组装在一起，看到它们 精妙地运行，得到预先所希望的结果。
第四是学习的乐趣，来自于这项工作的非重复特性。
最后，乐趣还来自于工作在如此易于驾驭的介质上。
职业的苦恼
首先，必须追求完美。因为计算机也是以这样的方式来变戏法：如果咒语中的一个字 符、一个停顿，没有与正确的形式一致，魔术就不会出现。
其次，是由他人来设定目标，供给资源，提供信息。
对于系统编程人员而言，对其他人的依赖是一件非常痛苦的事情。他依靠其他人的程 序，而往往这些程序设计得并不合理，实现拙劣，发布不完整（没有源代码或测试用例）， 或者文档记录得很糟。
下一个烦恼——概念性设计是有趣的，但寻找琐碎的 bug 却只是一项重复性的活动。 伴随着创造性活动的，
另外，人们发现调试和查错往往是线性收敛的，或者更糟糕的是，具有二次方的复杂 度。结果，测试一拖再拖，寻找最后一个错误比第一个错误将花费更多的时间。
最后一个苦恼，有时也是一种无奈——当投入了大量辛苦的劳动，产品在即将完成或 者终于完成的时候，却已显得陈旧过时。
第2章 人月神话
在众多软件项目中，缺乏合理的时间进度是造成项目滞后的最主要原因，它比其他所 有因素加起来的影响还大。导致这种普遍性灾难的原因是什么呢？
首先，它反映了一种悄无声息，但 并不真实的假设——一切都将运作良好。
第二，我们采用的估算技术隐含地假设人和月可以互换，错误地将进度与工作量相互 混淆。
第四，对进度缺少跟踪和监督。
第五，当意识到进度的偏移时，下意识（以及传统）的反应是增加人力。
乐观主义
所以系统编程的进度安排背后的第一个假设是：一切都将运作良好，每一项任务仅花 费它所“应该”花费的时间。
Dorothy Sayers 在她的 “The Mind of the Maker”一书中，将创造性活动分为三个阶段：构思、实现和交流。首先是作为一个构思或模型出现在作者的脑海中，它与时间 和空间无关。接着，借助钢笔、墨水和纸，或者电线、硅片和铁氧体，在现实的时间和空间 中实现它们。然后，当某人阅读书本、使用计算机和运行程序的时候，他与作者的思想相互 沟通，从而创作过程得以结束。
在许多创造性活动中，往往很难掌握活动实施的介质，例如木头切割、油漆、电器安 装等。这些介质的物理约束限制了思路的表达，它们同样对实现造成了许多预料之外的困难。
人月
第二个谬误的思考方式是在估计和进度安排中使用的工作量单位：人月。用人月作为 衡量一项工作的规模是一个危险和带有欺骗性的神话。它暗示着人员数量和时间是可以相互 替换的。
人数和时间的互换仅仅适用于以下情况：某个任务可以分解给参与人员，并且他们之 间不需要相互的交流
沟通所增加的负担由两个部分组成，培训和相互的交流。
相互之间交流的情况更糟一些。如果任务的每个部分必须分别和其他部分单独协作， 则工作量按照 n(n-1)/2 递增。
因为软件开发本质上是一项系统工作——错综复杂关系下的一种实践——沟通、交流 的工作量非常大，它很快会消耗任务分解所节省下来的个人时间。
系统测试
空泛的估算
重复产生的进度灾难
第3章 外科手术队伍
问题
Mills的建议
Mills 建议大型项目 的每一个部分由一个团队解决，但是该队伍以类似外科手术的方式组建，而并非一拥而上。由一个人来进行问题的分解，其他人 给予他所需要的支持，以提高效率和生产力。
如何运作
团队的扩建
第4章 贵族专制、民主政治和系统设计
概念的完整性
法国城市兰斯（Reims）在建筑风格上的一致性和上面所说的大教堂形成了鲜明的对比。设计的一致性和那些独到之处一样，同样让人们赞叹和喜悦。如同旅游指 南所述，风格的一致和完整性来自 8 代拥有自我约束和牺牲精神的建筑师们，他们每一个人 牺牲了自己的一些创意，以获得纯粹的设计。
获得概念的完整性
贵族专制统治和民主政治
在等待时，实现人员应该做什么
第5章 画蛇添足
结构师的交互准则和机制
面对估算过高的难题，结构师有两个选择：削减设计或者建议成本更低的实现方法。结构师必须
- 牢记是开发人员承担创造性和发明性的实现责任，所以结构师只能建议，而不能支 配；
- 时刻准备着为所指定的说明建议一种实现的方法，同样准备接受其他任何能达到目 标的方法；
自律——开发第二个系统所带来的后果
第6章 贯彻执行
假设一个项目经理已经拥有行事规范的结构师和许多编程实现人员，那么他如何确保 每个人听从、理解并实现结构师的决策？
文档化的规格说明——手册
手册是 产品的外部规格说明，它描述和规定了用户所见的每一个细节；同样的，它也是结构师主要 的工作产物。
规格说明的风格必须清晰、完整和准确。所有文字都要相互一致。这往往使手册读起来枯燥乏味， 但是精确比生动更加重要。
形式化定义
直接整合
会议和大会
周例会是每周半天的会议，由所有的结构师，加上硬件和软件实现人员代表和市场计 划人员参与，由首席系统结构师主持。
新问题通常会被讨论一些时间。重点是创新，而不仅仅是结论。该小组试图发现解 决问题的新方法。
正面和负面的意见都会被很好地描述。
随着时间的推移，一些决定没有很好地贯彻，一些小事情并没有被某个参与者真正地 接受，为解决这些堆积起来的问题，我们会举行年 度大会，典型的年度大会会持续两周。
这些会议在手册冻结的前夕召开。出席人员不仅仅包括体系结构小组和编程人员、实 现人员的结构代表，同时包括编程经理、市场和实现人员，
它们列举在会议室周围的图表上， 每个不同的声音都有机会得到表达。每天早晨，会议参与人员会在座位上发现更新了的 手册说明，记录了前一天的各项决定。
多重实现
电话日志
产品测试
第7章 为什么巴比伦塔会失败
巴比伦塔的管理教训
大型编程项目中的交流
项目工作手册
大型编程项目的组织架构
减少交流的方法是人力划分（division of labor）和限定职责范围（specialization of function）。
事实上，树状组织架构是作为权力和责任的结构出现。其基本原理——管理角色的非 重复性——导致了管理结构是树状的。
树状编程队伍，必须具备的基本要 素。
- 任务（a mission）
- 产品负责人（a producer）
- 技术主管和结构师（a technical director or architect）
- 进度（a schedule）
- 人力的划分（a division of labor）
- 各部分之间的接口定义（interface definitions among the parts）
产品负责人的角色是什么？他组建团队，划分工作及制订进度表。他要求，并一直要 求必要的资源。
技术主管的角色是什么？他对设计进行构思，识别系统的子部分，指明从外部看 上去的样子，勾画它的内部结构。
第8章 胸有成竹
系统编程需要花费多长的时间？需要多少的工作量？如何进行估计？
$$ 工作量 = 常数 \times 指令的数量^{1.5}$$
Portman的数据
Aron的数据
Harr的数据
OS／360的数据
Corbató的数据
第9章 削足适履
作为成本的程序空间
规模控制
空间技能
数据的表现形式是编程的根本
第10章 提纲挈领
计算机产品的文档
大学科系的文档
软件项目的文档
为什么要有正式的文档
第11章 未雨绸缪
试验性工厂和增大规模
将原型发布给用户，可以获得时间，但是它的代价高昂 ——对于用户，使用极度痛苦；对于重新开发的人员，分散了精力；对于产品，影响了声誉， 即使最好的再设计也难以挽回名声。
因此，为舍弃而计划，无论如何，你一定要这样做
唯一不变的就是变化本身
为变更设计系统
为变更计划组织架构
设计人员通常不愿意提交尝试性的设计决策，再为它们进行 辩解。“通过设计文档化，设计人员将自己暴露在每个人的批评之下，他必须能够为他的每 个结果进行辩护。如果团队架构因此受到任何形式的威胁，则没有任何东西会被文档化，除 非架构是完全受到保护的。
首先，管理人员自己常常 认为高级人员太“有价值”，而舍不得让他们从事实际的编程工作；其次，管理人员拥有更高的威信。为了克服这个问题，如 Bell Labs 的一些实验室，废除了所有的职位头衔。每个 专业人士都是“技术人员中的一员”。
组建外科手术队伍式的软件开发团队，这整个观念是对上述问题的彻底冲击。其结果 是当高级人才编程和开发时，不会感到自降身份。
前进两步，后退一步
程序维护中的一个基本问题是——缺陷修复总会以（20－50）%的机率引入新的 bug。 所以整个过程是前进两步，后退一步。
为什么缺陷不能更彻底地被修复？首先，看上去很轻微的错误，似乎仅仅是局部操作 上的失败，实际上却是系统级别的问题，通常这不是很明显。修复局部问题的工作量很清晰， 并且往往不大。但是，更大范围的修复工作常常会被忽视，除非软件结构很简单，或者文档 书写得非常详细。其次，维护人员常常不是编写代码的开发人员，而是一些初级程序员或者 新手。
回归测试
前进一步，后退一步
Lehman 和 Belady 研究了大型操作系统的一系列发布版本的历史 。他们发现模块数量 随版本号的增加呈线性增长，但是受到影响的模块以版本号指数的级别增长。所有修改都倾 向于破坏系统的架构，增加了系统的混乱程度（熵）。
系统软件开发是减少混乱度（减少熵）的过程，所以它本身是处于亚稳态的。软件维 护是提高混乱度（增加熵）的过程，
第12章 干将莫邪
目标机器
辅助机器和数据服务
高级语言和交互式编程
第13章 整体部分
剔除bug的设计
自顶向下的设计。
简言之，Wirth 的流程将设计看成一系列精化步骤。开始是勾画出能得到主要结果的， 但比较粗略的任务定义和大概的解决方案。然后，对该定义和方案进行细致的检查，以判断 结果与期望之间的差距。
结构化编程。另外一系列减少 bug 数量的新方法很大程度上来自 Dijkstra 。
基本上，该方法所设计程序的控制结构，仅包含语句形式的循环结构，例如 DO WHILE， 以及 IF...THEN...ELSE 的条件判断结构
关键的地方和构建无 bug 程序的核心，是把系统的结构作为控制结构来考虑，而不是 独立的跳转语句。
构件单元调试
内存转储。某人持续地运行程序，直到 某个检测失败，这时所有的内存都被转储。
快照。随着内存的规模不断增长，对整个内存都进行转储变得不大可能。 因此，人们开发了有选择的转储、选择性跟踪和将快照插入程序的技术。
系统集成调试
第14章 祸起萧墙
里程碑还是沉重的负担
“其他的部分反正会落后”
进度落后了一天，那又怎么样呢？谁会关心一天的滞后？我们可以跟上进度。何况， 和我们有关的其他部分已经落后了。
严格地说，PERT 技术是关键路径计划的细化，如果使用 PERT 图，它需要对每个事件估 计三次，每次对应于满足估计日期的不同可能性。
地毯的下面
有两种掀开毯子把污垢展现在老板面前的方法，它们必须都被采用。一种是减少角色 冲突和鼓励状态共享，另一种是猛地拉开地毯。
减少角色的冲突。首先老板必须区别行动信息和状态信息。
如果老板把会见、评审、会议明显标记为状态检查（status-meeting）和问题－行动 （problem-action）会议，并且相应控制自己的行为，这对整个过程会很有帮助。当然，事 态发展到无法控制时，状态检查会议会演变成问题－行动会议。不过，至少每个人知道“当 时游戏的分数是多少”，老板在接过“皮球”之前也会三思。
猛地拉开地毯。不论协作与否，拥有能了解状态真相的评审机制是必要的。
[!NOTE]
Bell 实验室的 V. Vyssotsky 添加了以下的观察意见：我发现在里程碑报告中很容易记录“计划”和“估计”的日期。计划日期是项目经理 的工作产物，代表了经协调后的项目整体工作计划，它是合理计划之前的判断。估计日期是 最基层经理的工作产物。基层经理对实 际实现日期的最佳判断。项目经理必须停止对这些日期的怀疑，一旦它们在每个人的脑海中形成了清晰的印象，项目经理就可以预见到将来哪些地方如果他 不采取任何措施，就会出现问题。
第15章 另外一面
需要什么样的文档
流程图
自文档化的程序
我认为相应的解决方案是“合并文件”，即把文档整合到源代码。这对正确维护是直接 有力的推动，保证编程用户能方便、即时地得到文档资料。这种程序被称为自文档化（self-documenting）。
方法。
第二个方法是尽可能地使用空格和一致的格式提高程序的可读性，表现从属和嵌套关 系。
第三，以段落注释的形式
第16章 没有银弹
摘要
所有软件活动包括根本任务——打造由抽象软件实体构成的复杂概念结构，次要任务 ——使用编程语言表达这些抽象实体，在空间和时间限制内将它们映射成机器语言。
介绍
大家熟悉的软件项目具有一些人狼的特性（至少在非技术经理看来），常常看似简单明 了的东西，却有可能变成一个落后进度、超出预算、存在大量缺陷的怪物。因此，我们听到 了近乎绝望的寻求银弹的呼唤，寻求一种可以使软件成本像计算机硬件成本一样降低的尚方宝剑。
根本困难
我认为软件开发中困难的部分是规格化、设计和测试这些概念上的结构，而不是对概 念进行表达和对实现逼真程度进行验证。
让我们来考虑现代软件系统中这些无法规避的内在特性：复杂度、一致性、可变性和 不可见性。
复杂度。数学家和物理学家 们建立模型以简化复杂的现象，从模型中抽取出各种特性，并通过试验来验证这些特性。这些方法之所以可行——是因为模型中忽略的复杂度不是被研究现象的必要属性。当复杂度是 本质特性时，这些方法就行不通了。
可变性。另外的原因是因为软件可以很容易地进行修改——它是纯粹思维活动的产物，可以无限扩展。日常生活中，建筑有可能发生变化，但众所周知，建筑修改的成本很高，从而打 消了那些想提出修改的人的念头。
功能扩展的压力主 要来自那些喜欢基本功能，又对软件提出了很多新用法的用户们。
不可见性。几何抽象是强大的工具。建筑平 面图能帮助建筑师和客户一起评估空间布局、
软件的客观存在不具有空间的形体特征。当我们试图用图形来描述软件结构时，我们 发现它不仅仅包含一个，而是很多相互关联、重叠在一起的图形。这些图形可能描绘控制流 程、数据流、依赖关系、时间序列、名字空间的相互关系等等。
以往解决次要困难的一些突破
如果回顾一下软件领域中取得的最富有成效的三次进步，我们会发现每一次都是解决 了软件构建上的巨大困难，但是这些困难不是本质属性，也不是主要困难。
高级语言。大多数观察者相信开发生产率至少提高了五倍，同时可靠性、简洁性和理解程度也大 为提高。
抽象程 序包含了很多概念上的要素：操作、数据类型、流程和相互通讯，而具体的机器语言程序则 关心位、寄存器、条件、分支、通道、磁盘等等。
分时。分时解决了完全不同的困难。分时保证了及时性，从而使我们能维持对复杂程度的一 个总体把握。
统一编程环境。它们主要通过提供集成库、统一文件格式、管道和过滤器，解决了共同使用程序的次 要困难。
银弹的希望
专家系统。专家系统是包含归纳推论引擎和规则基础的程序，它接收输入数据和假设条件，通过 从基础规则推导逻辑结果，提出结论和建议，向用户展示前因后果，并解释最终的结果。
Edward Feigenbaum 指出这种系统的能力不是来自某种前所未有的推导机制，而是来自 非常丰富的知识积累基础，所以更加精确地反映了现实世界。
如何把它应用在软件开发工作中？可以通过很多途径：建议接口规则、制订测试策略、 记录各种 bug 产生的频率、提供优化建议等等。
专家系统最强有力的贡献是给缺乏经验的开发人员提供服务，用最优秀开发者的经验 和知识积累为他们提供了指导。这是非常大的贡献。最优秀和一般的软件工程实践之间的差 距是非常大的，可能比其他工程领域中的差距都要大，一种传播优秀实践的工具特别重要。
“自动”编程。从问 题的一段陈述说明自动产生解决问题的程序。
他指出，大多数情况下所给出的技术说明本质上是问题的解决方法，而不是问题自身。
程序验证。现代编程的许多工作是测试和修复 bug。是否可以在大量工作被投入到实现和测试之前，通过采用证实设计正确性的“深奥”策略，彻底提高软件的生产率和产品的可靠性？
更严肃地说，完美的程序验证只能建立满足技术说明的程序。
针对概念上根本问题的颇具前途的方法
购买和自行开发。软件成本一直是开 发的成本，而不是复制的成本。所以，即使只在少数使用者之间实现共享，也能在很大程度 上减少成本。
增量开发——增长，而非搭建系统。我们已经理解软件开发是 如何类似于其他的建造过程，并开始随意地使用其他的暗喻，如规格说明、构件装备、脚手 架（测试平台）（specifications, assembly of components, and scaffolding）。
当一个可运行系统——即使是非常简单的 系统出现时，开发人员的热情就迸发了出来。在开发过程中的每个阶段， 总有可运行的系统。我发现开发团队可以在四个月内，培育（grow）出比搭建（building） 复杂得多的系统。
第17章 再论“没有银弹”
人狼和其他恐怖传说
存在着银弹——就在这里
含糊的表达将会导致误解
我认同英国剧作家、侦探小说作者和神 学家桃乐丝·赛尔丝看待创造性活动的观点，创造性活动包括（1）概念性结构的形式规格 化，（2）使用现实的介质来实现，（3）在实际的使用中，与用户交互 。
复杂性是层次化的。
[!NOTE] 不同观点
Northrop 的 Steve Lukasik 认为即使是组织机构上的复杂性也不是任意的，可能容易 受到策略调整的影响。
我相信有一天软件的“复杂性”将以某种更高级的规律性概念来表达 （就像物理学家的不变式）。
作为对 Lukasik 的简单回应，我认为系统复杂性是无数细节的函数，这些细 节必须精确而且详细地说明——或者是借助某种通用规则，或者是逐一阐述，但决不仅仅是 统计说明。
它倡导向软件系统增加必要的复 杂性：
- 层次化，通过分层的模块或者对象。
- 增量化，从而系统可以持续地运行。
Harel的分析
Jones的观点——质量带来生产率
那么，生产率的情形如何
面向对象编程——这颗铜质子弹可以吗
重用的情况怎样
[!NOTE]
JPL 的 Van Snyder 向我指出，数学软件领域有着软件重用的长期传统：
数学软件上重用成功的原因有两个：（1）它很晦涩难懂，每行代码需要大量高智商的 输入；（2）存在丰富的标准术语，也就是用数学来描述每个构件的功能。
学习大量的词汇——对软件重用的一个可预见但还没有被预言的问题
子弹的本质——形势没有发生改变
……
第18章 《人月神话》的观点：是与非
第1章 焦油坑
第2章 人月神话
第3章 外科手术队伍
第4章 贵族专制、民主政治和系统设计
第5章 画蛇添足
第6章 贯彻执行
第7章 为什么巴比伦塔会失败
第8章 胸有成竹
第9章 削足适履
第10章 提纲挈领
第11章 未雨绸缪
第12章 干将莫邪
第13章 整体部分
第14章 祸起萧墙
第15章 另外一面
第1版结束语
第19章 20年后的《人月神话》
为什么要出版20周年纪念版本
核心观点——概念完整性和结构师
开发第二个系统所引起的后果——盲目的功能和频率猜测
图形界面的成功
没有构建舍弃原型——瀑布模型是错误的
增量开发模型更佳——渐进地精化
从事实时系统开发的 Harlan Mills，早期曾提倡我们首先应该构建实时系统的基本轮 询回路，为每个功能都提供子函数调用（占位符），但仅仅是空的子函数（图 19.2）。对它 进行编译、测试，使它可以不断运行。它不直接完成任何事情，但至少是正常运行的 。
在每 个阶段，我们都拥有一个可运行的系统。
在每个功能基本可以运行之后，我们一个接一个地精化或者重写每个模块——增量地 开发（growing）整个系统。
因为我们在所有时刻都拥有一个可运行的系统，所以
- 我们可以很早开始用户测试，
- 我们可以采用按预算开发的策略，来彻底保证不会出现进度或者预算的超支（以允 许的功能牺牲作为代价）。
Parnas 产品族
设计类似一棵树的技巧是将那些变化可能性较小的设计决策放置在树的根部。
这样的设计使得模块的重用最大化。更重要的是，可以延伸相同的策略，使它不但可 以包括发布产品，而且还包括以增量开发策略创建的后续中间版本。
增量式开发和快速原型
Harel 将原型精彩地定义成：
仅仅反映了概念模型准备过程中所做的设计决策的一个程序版本，它并未反映受实 现考虑所驱使的设计决策。
构建一个完全不属于发布产品的原型是完全可能的。例如，可以开发一个界面原型， 但是并不包含任何的实际功能，而仅仅是一个看上去履行了各个步骤的有限状态机。
关于信息隐藏，Parnas是正确的，我是错误的
人月到底有多少神话色彩？Boehm的模型和数据
使用人月作为生产率的衡量标准实际是一个神话。特别的，他发现：
- 第一次发布的成本最优进度时间，T = 2.5（MM）1/3。即，月单位的最优时间是估 计工作量（人月）的立方根，估计工作量则由规模估计和模型中的其他因子导出。最优人员 配备曲线是由推导得出的。
- 当计划进度比最优进度长时，成本曲线会缓慢攀升。时间越充裕，花的时间也越长。
- 当计划进度比最优进度短时，成本曲线急剧升高。
- 无论安排多少人手，几乎没有任何项目能够在少于 3/4 的最优时间内获得成功！当 高级经理向项目经理要求不可能的进度担保时，这段结论可以充分地作为项目经理的理论依 据。
人就是一切（或者说，几乎是一切）
这来自一个信念，即对于项目的成功而言，项目人员的素质、人 员的组织管理是比使用的工具或采用的技术方法更重要的因素。
放弃权力的力量
如果人们认同我在文中多处提到的观点——创造力来自于个人，而不是组织架构或者 开发过程，那么项目管理面对的中心问题是如何设计架构和流程，来提高而不是压制主动性 和创造力。
像 Pius XI 所预言的好处：通过权力委派，中心的权威实际上是得到了加强；从整体而言，组织机构实 际上更加融洽和繁荣。
最令人惊讶的新事物是什么？数百万的计算机
其他领域中进步的部分原因和软件创造相近——消除了次要的困难。例如，文书处理 方式曾经是很僵化的，合并更改内容需要重新打字，成本和时间都比较高昂。一份 300 页的 手稿，常常每 3 到 6 个月就需要重新输入一遍，
全新的软件产业——塑料薄膜包装的成品软件
买来开发——使用塑料包装的成品软件包作为构件
软件工程的状态和未来
结束语：令人向往、激动人心和充满乐趣的50年
注解与参考文献
附录：人月落地实战体验
一、名家谈人月
1．年金
2．《人月神话》与实践
3．Frank Chance评人月
4．软件尚方宝剑（Silver Bullet）何在
二、名著评人月
三、读者感言
1．读书有感——人月神话
2．我这几天很烦（产品概念完整性）
3．关于我们的思考——“项目开发”及读《人月神话》有感
4．我的“人月神话”
5．《人月神话》软玉生香
浙公网安备 33010602011771号