原则172 做项目总结

第8章产品保证原则

原则173 产品保证并不是奢侈品

原则 174 尽早建立软件配置管理过程

原则175 使软件配置管理适应软件过程

原则176 组织SCM 独立于项目管理

原则 177 轮换人员到产品保证组织

给所有中间产品一个名称和版本

原则179 控制基准

原则180 保存所有内容

原则181 跟踪每一个变更

原则182 不要绕过变更控制

原则183 对变更请求进行分级和排期

原则184 在大型开发项目中使用确认和验证(V&V)

第9章演变原则

原则185 软件会持续变化

软件的熵增加

原则 187 如果没坏，就不要修理它

原则188 解决问题，而不是症状

原则189 先变更需求

发布之前的错误也会在发布之后出现

原则191 一个程序越老，维护起来就越困难

原则192 语言影响可维护

原则193 有时重新开始会更好

原则194 首先翻新最差的

原则195 维护阶段比开发阶段产生的错误更多

原则 196 每次变更后都要进行回归测试

“变更很容易”的想法，会使变更容易出错

原则198 对非结构化代码进行结构化改造，并不一定会使它更好

原则199 在优化前先进行性能分析

原则200 保持熟悉

系统的存在促进了演变

SCM计划

为什么东京电力公司一步步衰落了呢

make for

behind the scenes

简单介绍一下卷积神经网络

元宇宙

impinge on记忆方法

原则172 做项目总结

忘记过去的人注定会重蹈覆辙。
一乔治·桑塔亚纳( George Santayana)，1908

本原则用于对管理错误或者整体的技术错误进行同样的操作.在每个项目结束时，给所有的项目关键参与者 3~4天的时间来分析项目中出现的每一个问题。

复盘过去真的很是重要

总的来说，主要思路是记录、分析所有不符合预期的事情并从中学习。

记录下你认为将来可以采取的预防问题发生的不同措施。未来的项目将会极大受益。

第8章产品保证原则

        产品保证是通过使用分权制衡( checks and balances)来确保软件质量的一系列工作。产品保证通常包括如下几项。
        1.软件配置管理( Software configuration management): 管理软件变更的过程。
        2.软件质量保证( Software quality assurance): 检查所有做法和产品是否符合既定流程和标准的过程。
        3.软件验证和确认 ( Software verification and validation): 这个过程用于验证(verify)每个中间产品是否正确地建立在以前的中间产品的基础上，以及确认 (validate)每个中间产品是否适当地满足客户的要求。
        4.测试(Testing):在前面的章节已介绍过。

原则173 产品保证并不是奢侈品

产品保证包含软件配置管理( software configuration management).软件质量保证( software quality assurance )，验证和确认(verificationandvalidation )，以及测试 ( testing )。在以上四点中，测试和评估的必要性是最常被承认的，哪怕预算不足。另外三点则经常作为奢侈品而被摒弃掉，如同它们只是大型项目或者昂贵项目的一部分一样。

测试和评估是很重要的

原则 174 尽早建立软件配置管理过程

有效的软件配置管理(SCM，Software Configuration Management )不仅仅是一个记录谁在什么时候对代码和文档进行了怎样修改的工具。它还包括深思熟虑地创建命名约定、策略和过程，以确保所有相关方都能参与软件的更改。

原则175 使软件配置管理适应软件过程

软件配置管理(SCM)并不是一对所有项目一律适用的标准实践。SCM 必须根据每个项目的特点去定制: 项目规模、易变性、开发过程、客户参与度等。

原则176 组织SCM 独立于项目管理

软件配置管理(SCM）只有在独立于项目管理的情况下才能做好本职工作。

如果 SCM 在管理关系上向项目经理汇报，SCM 只能接受这种情况。如果它们之间是独立的，SCM 可以实施最适合所有相关人员的规则。

原则 177 轮换人员到产品保证组织

轮换最好的工程人才到产品保证组织工作。一个好的指导方针可能是，每一个优秀的工程师每隔两到三年，就要投入六个月的时间到产品保证上。所有这些工程师的期望是，他们可以在“访问”期间对产品保证做出重大改进。

给所有中间产品一个名称和版本

软件开发过程中会有许多中间产出，需求规格说明、设计规格说明、代码、测试计划、管理计划、用户手册等。每个这样的产出都应该有唯一的名称、版本/修订号和创建日期。

此外,当把最终产品发布给用户时，必须给它分配一个唯一的( 产品)版本/修订号和创建日期。

原则179 控制基准

软件配置管理(SCM)的职责，是保持商定的规格并控制对其的变更。

正确的过程是由软件工程师提出变更请求(CR,Change Request)。然后，这个变更请求要与来自开发、营销测试和客户的其他变更请求一起由配置控制委员会(ConfiquratienControl Board)处理。这个委员会负责确定变更请求的优先级和排期只有这样才能允许工程师进行变更，只有这样 SCM 才能接受变更

任何变更都要留痕。

但是目前的编译环境一般都是具备了这些条件的，对于是谁负责，谁变更

原则180 保存所有内容

Paul Erlich 说过，“明智修补的首要原则是保存所有的零件“。

软件从本质上来说是不断被修补的。（但是很可能越修越烂）

所以任何软件更改都很可能需要被回滚。做到这一点的唯一产法是确保在进行更改之前保存所有丙容。软件配置管理组织的工作即在对基线进行批准的更改之前，保存所有内容的所有副本

原则181 跟踪每一个变更

每次变更都有可能引发问题。三个常见的问题是
1.变更未解决预期要解决的问题。
2.变更解决了问题，但导致了其他问题。
3.在将来的某天变更被注意到时，没有人能弄清楚更改的原因(或由谁更改 )。
在这三种情况下，预防措施都是跟踪所有变更

跟踪意味着记录
最初的变更请求(这可能是客户对新功能的请求，客户对故障的投诉，开发人员发现了一个问题，或者开发人员想要添加一个新功能。
用于批准变更的审批流程( 谁，何时，为什么，在哪个发布版本中)。
所有中间产出的变更( 谁，什么，何时 )。
在变更请求、变更审批和变更本身之间进行适当的交叉引用
这样的审计追踪使你可以轻松撤销、重做并且/或者理解变更.

跟踪意味着记录

原则182 不要绕过变更控制

变更得到控制，每个人都会受益。

“控制”并不意味着“阻止”

通常会直接要求开发人员为他们进行特定修改，来绕过变更控制。这是灾难性的。它会使项目管理陷入困境。它会导致成本上升。它会使需求规范不准确。

原则183 对变更请求进行分级和排期

对于任何投入使用的产品，来自用户、开发人员和市场营销人的变更请求都会集中到开发团队。

这些变更请求可能反映了对新功能的需求、性能下降的报告或对系统错误的投诉，应该成立一个委员会通常称为配置控制委员会(CCB，Configuration Control Board)，以定期评审所有变更请求。

委员会的职责是将所有这些变更进行优先级排序，并安排何时(或至少确定将在哪个即将来临的发布版本中)它们将会被解决。

原则184 在大型开发项目中使用确认和验证(V&V)

开发大型软件系统需要尽可能多的制衡，以确保产品的质量。

让独立于开发团队的组织来进行确认和验证()&V)。确认CValidation)是检查软件开发的每个中间产品以确保其符合之前产品的过程。

确认可确保: 软件需求满足系统要求，高阶的软件设计可满足所有软件需求( 而不是其他需求 )，算法可满足组件的外部规格说明，代码可实现算法，等等。验证(Verification)是检查软件开发的每个中间产品以确保其满足需求的过程。

确保和验证真的是很重要的

确认会使每个孩子问前一个孩子，“你说的是吗? ”验证会使每个孩子问第一个孩子，“你说的是x吗?”

第9章演变原则

（看完之后，真的感觉，事情最好真的就是一次性做好，不要随随便便地搞，到时候你想要改，那是真的难）

演变是与修改软件产品相关的一系列工作，用于：
1.满足新功能。
2.更有效地运行。
3.正常运行(当检测到原始产品中的错误时 )。

原则185 软件会持续变化

任何正在使用的大型软件系统都将经历不断的变化，因为系统的使用会使人想出新的功能。

它会一直变化，直到从头开始重写变得更划算。这就是曼尼·雷曼( Manny Lehman )的“持续变化定律”(Lawof Continuing Change

（事物是有演变周期的，事物积累到一定程度之后，就是会毁灭的）

软件的熵增加

任何经历持续变化的软件系统都会变得越来越复杂，并且变得越*越杂乱无章。由于所使用的所有软件系统都会发生变化(见原则185并且变化会导致不稳定，因此所有有用的软件系统都将朝着低的可靠性和可维护性迁移。

原则 187 如果没坏，就不要修理它

软件被认为是可塑的、易于修改的。不要误以为软件中的“失灵”很容易发现或修复。

在检查时，你觉得自己发现了另外一个错误。不要试图“修复”它。很有可能你会引入而不是修复一个错误(见原则 190)。相反，应记录并提交变更请求。期望通过配置控制和相关的技术评审来确定它是否是一个错误，以及应该以什么样的优先级进行修复

先要判断它是否是一个错误

原则188 解决问题，而不是症状

当软件出错时，你的责任是彻底理解错误产生的原因，而不只是草草分析一下，并对你认为的原因进行一个快速的修复

彻底理解错误的原因，这真的很重要

这个解决方案有所有与第一个解决方案相同的问题而且它还会导致所有未来调用错误组件的组件接收错误的值。正确的解决方案是检查程序并确定为什么值总是加倍，然后修复它

原则189 先变更需求

如果各方都同意对软件进行增强，那么/第一件事就是更新软件求规格说明(SRS )，并获得批准。

请先对 SRS 进行更改，然后再开始对设计和代码进行更改，并且在完成设计和代码的修改之前，批准对SRS的变更。

工业产品主要是满足客户的需求，先向甲方与你的管理层打招呼

发布之前的错误也会在发布之后出现

发布之前错误就比较多的组件，发布之后也会被发现会有比较多的错误

这对开发者来说是一个令人失望的消息，但确实是被经验数据所充分支持的(而且由原则 114 可知，假如你在一个组件中发现了很多错误，那将来还会发现更多错误。最好的建议是废弃、替换从头创建任何具有不良历史记录的组件。不要花钱填坑。

(其实找男女朋友也是一样，如果对方本就是一个渣男，你应该直接换一个，渣女同理)

原则191 一个程序越老，维护起来就越困难

在对软件系统进行更改(无论是维修还是增强)时，系统中必定有一些组件要被修改。

随着程序变“老”，每次改动时，整个系统中需要修改的组件的比例就会随之增加。

每次更改都会使所有后续的更改更加困难，因为程序的结构必然会恶化。

原则192 语言影响可维护

原则193 有时重新开始会更好

如今关于重建(reengineering ）、翻新(renovation )和逆向工程(reverse engineering)的讨论太多了，我们可能都开始信这样做很容易。

其实这很难做。有时这很有意义，值得投资。但有时这是对珍稀资源的浪费，从头开始设计和编码可能是更好的选择。

原则194 首先翻新最差的

完全重新设计和重新编码“最差”的组件。这里“最差”的组件是指那些消耗了最多改正性维护费用的组件。GeraldWeinberg 曾说，在一个系统中重写一个 800 行的模块占全部改正性维护成本的 30%)，就可以为整体维护工作节省大量的资源

盯着最差的先弄

原则195 维护阶段比开发阶段产生的错误更多

维护期间对程序的修改( 无论是改进功能还是修正缺陷)引入的错误远远超过最初的开发阶段。维护团队报告说，维护期间有 20%到50%的改动会引入更多的错误。

原则 196 每次变更后都要进行回归测试

回归测试，是在变更发生后，对所有先前已测试过的功能进行的测试。

你必须验证你的改动是否能正确地运行。也就是说你必须测试之前不能正确运行的部分，新的特性是否生效，或者确认性能是否确实得到了提升。

（要进行验证，并且你要对更多的功能进行验证，看看对其他的功能有没有影响）

你还必须要做回归测试，来验证之前那些运行正确的功能，现在是否还能正常工作。

“变更很容易”的想法，会使变更容易出错

因为软件是很复杂的，要正确运行必须处于“完美”的状态，所以必须认真考虑每一个改动可能带来的影响。

只要开发人员认为变更是简单的容易的或不证自明的，他们就会放松警惕，忽视那些能帮助保证质量的手段，在大部分情况下就会执行不正确的变更。

原则198 对非结构化代码进行结构化改造，并不一定会使它更好

假如你必须维护一个以非结构化方式编写的程序。你可以机械地将其转换为等效的结构化代码，还具有相同的功能。这样的程序不-定更好!通常这种机械化的重构会导致同样糟糕的代码。

重新考虑模块，并从买开始重新设计。

原则199 在优化前先进行性能分析

当需要优化程序以使其更快时,请记住80%的 CPU周期将被20%的代码消耗(Pareto 定律。

先找到那些能够带来优化效20%的代码。最好的方法是使用市场上可买到的可用的性能分析工具

性能分析工具在程序运行过程中执行监控，并识别出“热点”，也就是消耗最多 CPU 周期的部分。优化这部分。

原则200 保持熟悉

“熟悉守恒定律”(Law of ConservationofFamiliarity)。在软件产品的维护阶段，通常会采用增量版本方式来发布。每个新版本都包含一定数量的变化(即与早期版本中所熟悉的功能不同 )。新发布的版本如果要包含大于平均水平的变化，往往会出现“性能差，可靠性差，故障率高，成本和时间都超支”的问题

变化量高于平均水平越多,风险就越大。

系统的存在促进了演变

无论你认为自己多么完美地实现了需求，都必须为部署之后必要的变更做好计划。

即使这些假设成立，演变仍然会发生，因为将这个系统引入它要解决的问题的环境时，本身就改变了这个环境也就会引发新的问题。

必然会演化

看似给了你许多的自由，其实大多都是更新花样后的牢笼

我们都没有处理好自己的事情，但是却喜欢管其他人的事情

受虐者为什么要因为被施暴者在身体上留下难以抹去的伤疤而为了美观去纹身，从而让柔弱的人看起来凶神恶煞呢？

当今的日本也再也不复上个世纪七八十年代的辉煌，现在的日本也是非常节约的

我虽然很喜欢黑泽明的电影，但是，他说他不喜欢的年轻人就是一打开自己的包里面就是装着一堆打折劵的人，但是这也是没有办法的，很多东西就是，一去不复还，很多的劲也是如此，过了就没有了，那是属于一个时代的感召力，过了也就消逝了。

从小，其实都是觉得，这个世界永远是向前发展的，学到马克思哲学的时候，也是认为，事物是不断变化的，认为这个世界一定是会持续地好下去，因为自己生活在一个蓬勃发展的时代，每一天似乎都是在向着好的势头去发展，相信明天会更好，这是我长久以来秉持的一个观念，但是到了现在，似乎都又变了。

时代是会回滚的，事物不是永远地向前发展的

SCM计划

"SCM" 是供应链管理（Supply Chain Management）的缩写，是一个涉及到物资、信息和金融流动的领域，它旨在协调和优化从原材料生产到最终产品交付的整个供应链过程。在计算机领域，有时候也称为 "SCM计划"，是指应用计算机和信息技术来支持和管理供应链的规划和执行。

SCM计划的主要目标是实现以下几点：

流程优化： SCM计划通过优化供应链的各个环节，从而提高整体效率和生产力。它可以帮助降低成本、减少库存、提高交付速度，同时保持高质量的产品和服务。
需求预测： 通过分析历史数据、市场趋势和其他相关因素，SCM计划可以帮助预测产品的需求情况。这有助于避免过多或过少的库存，从而降低库存成本并提高客户满意度。
供应商管理： SCM计划可以协助企业与供应商建立紧密的合作关系，以确保原材料的及时供应和质量可靠。这有助于降低风险，减少供应链中断的可能性。
生产规划： SCM计划可以帮助企业合理规划生产活动，确保生产资源得到充分利用，同时避免过度生产造成的浪费。
库存管理： SCM计划可以通过预测需求、优化供应链流程等手段，帮助企业降低库存水平，减少库存成本。
物流和运输优化： SCM计划可以帮助企业优化物流和运输过程，选择最佳的运输路径和方式，以降低运输成本并提高交付效率。
信息共享： SCM计划通过信息技术，实现供应链各方之间的信息共享，以便更好地协调活动、解决问题和作出决策。

综上所述，SCM计划在计算机领域是指运用信息技术来支持供应链管理的规划和实施，以达到更高效、更优化的供应链运作，从而提供更好的产品和服务。

为什么东京电力公司一步步衰落了呢

东京电力公司（东电，Tokyo Electric Power Company Holdings，简称TEPCO）是日本最大的电力公司之一，总部位于东京。它因为2011年发生的福岛核事故而受到了严重的影响，导致公司声誉受损，经济状况恶化。以下是一些主要原因：

福岛核事故： 2011年发生的福岛核事故是东电公司衰落的关键原因之一。地震和海啸导致福岛核电站发生核泄漏，造成重大影响和损害。该事故不仅对环境造成了污染，还造成了人员伤亡和大规模的疏散。东电公司在事故处理和信息公开方面受到了批评，导致其声誉受损。
赔偿和成本压力： 福岛核事故导致大量的赔偿要求和法律诉讼。东电公司需要支付赔偿给受影响的居民、农民和其他相关方，这给公司造成了巨大的经济负担。此外，停用核电站、进行核电站安全升级以及购买替代能源等都增加了成本压力。
核能政策调整： 在福岛核事故之后，日本政府调整了核能政策，提高了核电站的安全标准。这使得东电公司需要进行大规模的核电站安全升级和改造，而这些改造成本高昂，进一步加大了公司的负担。
能源市场自由化： 日本在2016年实施了能源市场的自由化，允许消费者选择他们的能源供应商。这给东电公司带来了更大的竞争压力，以前的垄断地位受到了冲击，导致其市场份额减少。
声誉受损： 福岛核事故对东电公司的声誉造成了长期影响。公众对于公司的不信任感和对核能的担忧，影响了其业务和形象，也让它难以恢复以前的地位。

综合上述因素，福岛核事故是导致东电公司衰落的主要原因，该事故对公司的声誉、经济和市场地位产生了深远影响。公司不得不应对赔偿压力、成本上升以及竞争压力，这一系列挑战使得其逐步衰落。

软件工程更加讲究工程按时交付与人员管理、风险管控

软件工程解决的问题是如何着手处理实际工程上需要遇到的问题，没有多少合理性，大量的遇见的是妥协与将就，不是传统科学学术上的那种理想环境下所做的实验，我们更偏向于落地

生活水平、物质能力达不到一定层次，那玩的艺术都是假的，就像是食品一样，你拿它做艺术品，如果你的欣赏者都是一群吃不饱饭的时候，他们看到你的作品，肯定说的是，这多么浪费，这为什么不拿来给我吃，只有吃饱的人才有气力从物体本身人为修琢的美感来感知，所以，如果你想要让广大人民群众有一个审美的心，第一点就是让足够的人吃饱饭，不然审美、艺术在中国纯纯扯淡。

make for

记忆单词或词组时，使用创意和联想的方法可以帮助你更容易记住。对于 "make for" 这个词组，你可以考虑以下记忆方式：

图像联想法： 将 "make for" 想象成两个动作的结合。"Make" 表示制造、创建，而 "for" 可以理解为朝向、前往。你可以想象自己正在创造一个通往目标地点的道路，这个道路是你 "制造" 出来的，而你正在沿着这条道路 "前往" 目标地点。
情境场景法： 创造一个情境来使用这个词组。想象你正在准备一顿丰盛的晚餐。你正在制作各种美味的食物，这些食物都是为了满足你的家人或朋友的需要。在这个情境下，你可以联想到 "make for" 表示制作、创造以满足某种需求。
声音提示法： "Make for" 的发音可以让你联想到 "make" 和 "four" 两个词的组合。你可以想象你正在制作四个物品，这四个物品都是朝着某个方向前进的，这可以帮助你记住 "make for" 的意思。
句子记忆法： 创造一个简短的句子，其中包含 "make for"。例如："His hard work will make for a successful career."（他的努力将为他的职业生涯铺就成功之路。）

无论使用哪种方法，重要的是与词组建立一种有趣或有意义的联系。尝试使用你觉得最有用的方法，根据个人喜好和记忆方式来记忆 "make for" 这个词组。

behind the scenes

记忆单词或词组时，使用创意和联想的方法可以帮助你更容易记住。对于 "behind the scenes" 这个词组，你可以考虑以下记忆方式：

图像联想法： 将 "behind the scenes" 想象成一个戏剧或电影的背后情景。想象你正在观看一部电影，然后突然屏幕上转移到了幕后的情景，你看到了演员们准备、布景搭建等工作。这个背后的情景正是 "behind the scenes" 的含义。
情境场景法： 创造一个情境来使用这个词组。想象你是一个电影制片人，你正在制作一部电影。你会看到演员们在幕前表演，而幕后则有许多工作人员在忙碌地准备道具、布景和灯光等。这个情境可以帮助你联想到 "behind the scenes" 表示幕后情景或内部工作。
声音提示法： "Behind the scenes" 的发音可以让你联想到 "behind" 和 "beans" 两个词的组合。你可以想象你正在一个餐厅的厨房后面，看到厨师们正在做一些魔术，将一些看似普通的食材变成了美味的菜肴。这种幕后的工作可以帮助你记住 "behind the scenes" 的意思。
句子记忆法： 创造一个简短的句子，其中包含 "behind the scenes"。例如："The real work happens behind the scenes."（真正的工作发生在幕后。）

无论使用哪种方法，重要的是与词组建立一种有趣或有意义的联系。尝试使用你觉得最有用的方法，根据个人喜好和记忆方式来记忆 "behind the scenes" 这个词组。

不要去考验人性，它经不起考验

简单介绍一下卷积神经网络

卷积神经网络（Convolutional Neural Network，简称CNN）是一种专门用于处理图像和视频等二维数据的人工神经网络模型。它在计算机视觉领域取得了巨大成功，广泛应用于图像分类、目标检测、图像生成等任务。

CNN的核心思想是通过卷积操作捕捉图像中的特征，从而实现高效的图像处理和分析。以下是CNN的几个重要概念：

卷积层（Convolutional Layer）：卷积层是CNN的基础组件，通过应用一系列滤波器（也称为卷积核）对输入图像进行卷积操作。这些滤波器能够检测不同方向、不同尺度的特征，例如边缘、纹理等。
池化层（Pooling Layer）：池化层用于降低特征图的尺寸和复杂性，同时保留重要的信息。最常见的池化操作是最大池化，它从输入区域中选取最大值作为池化后的值。
激活函数（Activation Function）：在卷积神经网络的每个神经元中，都会引入一个激活函数，常用的激活函数包括ReLU（Rectified Linear Unit）等。激活函数引入非线性，使网络能够学习复杂的特征和模式。
全连接层（Fully Connected Layer）：在CNN的最后几层，通常会包含全连接层，将卷积和池化层提取到的特征映射连接到神经网络的输出。全连接层有助于对提取到的特征进行分类或其他任务。
卷积操作（Convolution Operation）：卷积操作是CNN的核心运算，它将滤波器与输入图像的不同位置进行逐元素相乘，并将结果相加，从而生成特征图。

CNN的训练过程通常包括前向传播和反向传播两个阶段。在前向传播中，网络根据输入图像逐层计算特征，并生成预测结果。而反向传播则用于计算损失并更新网络的权重，以最小化预测结果与实际标签之间的差异。

总之，卷积神经网络通过卷积、池化和全连接等操作，能够自动地从原始图像中学习并提取出高层次的特征，从而在图像处理任务中表现出色。

元宇宙

其实我认为元宇宙真的是一个展望的东西，至少在画饼的时候，我听的不是很厌烦

impinge on记忆方法

图像联想法： 将 "impinge on" 分解成两个部分。"Impinge" 可以想象成一种力量或影响，而 "on" 意味着对某物施加压力。你可以想象一个球体（代表影响或力量）正在向一个靶心（代表 "on"）施加压力，这样你就可以联想到 "impinge on" 表示影响或压力施加在某事物上。

"Impinge" 这个词的起源可以追溯到拉丁语 "impingere"，由 "im-"（进入）和 "pangere"（敲打）两部分组成。拉丁语中的 "impingere" 意味着 "撞击"、"碰撞" 或 "敲打"。

随着时间的推移，"impinge" 的含义从最初的 "撞击" 或 "碰撞" 演变为 "影响"、"干预" 或 "施加压力" 的含义。这种演变可能是因为碰撞或撞击会引发物体之间的影响，而 "impinge" 这个词则被引申用来表示外部事物对某物的影响或干预。

这种语言演变是很常见的，单词的意义可以随着使用和社会变化而变化。从 "impinge" 的起源可以看出，它的现代含义与其词源之间存在着一定的联系，即外部力量对某物的影响或干预。

"Impinge" 是一个动词，用来描述外部事物或力量对某事物产生影响、压力或干预。它通常表示一种直接的、明显的影响，可能是积极的也可能是消极的。这个词常常用来描述某物或某人在空间或时间上的干预，以及对某种情况、状态或进程的影响。

一些示例用法包括：