- 浏览: 151352 次
- 性别:
- 来自: 北京
-
文章分类
最新评论
-
august_000:
很有道理,我已经亲自测试过了:
public class ...
单例模式之线程安全解析 -
Chris_bing:
一个单例有这么多名堂,最后那个内部类的解决方案很有创意啊,受教 ...
单例模式之线程安全解析
原文:http://en.wikipedia.org/wiki/Anti-pattern
译文:http://www.yeeyan.com/articles/view/27472/7244
[前言]
design pattern是设计模式,通常是前人在软件开发过程中积累出来的解决一些问题的现成套路,按它们来做可获益无穷。anti-pattern也是一些现成的套路,但它们是现成的错误套路,避免它们则亦可获益无穷。本文译者Korner Hill的更多其它翻译和原创文章可在blog上找到http://blog.csdn.net/KornerHill。
计算机领域内的很多词汇都缺少公认的中文翻译,anti-pattern也是如此,这里译为反面模式,乃是因为它本身是作为反面教材使用的模式。其实直接用“反面教材”更通俗易懂,但这里为了保持它与设计模式之间的内在关联,而使用了“反面模式”一词。
文中有些个别单词没有翻译,一是如bug和bugfix这样在计算机领域内已经广泛使用的词,二是像Staralised这种在字典里都查不到词,三是像perkele这种有文化背景的名字(perkele是芬兰神话里的雷神)。
有些地方即使翻译过来,可能读者还是不一定会明白,毕竟代码的事情不是纸上谈兵。例如Circle-ellipse problem,涉及的概念较多,虽然能翻译过来,但读者若要理解,还是得到wikipedia上再查。
翻译这篇文章确实很不容易,既要英文好,又要有编程的背景,最好还要有西方生活的背景,在下水平有限,很多地方翻译不到位,请各们谅解。
================================================================================
= 以下是译文部分
================================================================================
来自Wikipedia, 自由百科全书
在软件工程中,一个反面模式(anti-pattern或antipattern)指的是在实践中明显出现但又低效或是有待优化的设计模式。
Andrew Koenig在1995年造了anti-pattern这个词,灵感来自于GoF的《设计模式》一书。而这本书则在软件领域发明了“设计模式”(design pattern)一词。三年后antipattern因《AntiPatterns》这本书而获得普及,而它的使用也从软件设计领域扩展到了日常的社会互动中。按《AntiPatterns》作者的说法,可以用至少两个关键因素来把反面模式和不良习惯、错误的实践或糟糕的想法区分开来:
* 行动、过程和结构中的一些重复出现的乍一看是有益的,但最终得不偿失的模式
* 在实践中证明且可重复的清晰记录的重构方案
很多反面模式只相当于是错误、咆哮、不可解的问题、或是可能可以避免的糟糕的实践,它们的名字通常都是一些用反话构成的词语。有些时候陷阱(pitfalls)或黑色模式(dark patterns)这些不正式的说法会被用来指代各类反复出现的糟糕的解决方法。因此,一些有争议的候选的反面模式不会被正式承认。
原文:http://en.wikipedia.org/wiki/Anti-pattern
译文:http://www.yeeyan.com/articles/view/27472/7244
[目录]
[1. 已知的反面模式]
[1.1 组织结构的反面模式]
[1.2 项目管理的反面模式]
[1.3 团队管理的反面模式]
[1.4 分析方式的反面模式]
[1.5 通常的设计反面模式]
[1.5.1 面向对象设计的反面模式]
[1.6 编程方面的反面模式]
[1.7 方法学上的反面模式]
[1.8 测试反面模式]
[1.9 配置管理反面模式]
[Contents]
[1 Known anti-patterns]
[1.1 Organizational anti-patterns]
[1.2 Project management anti-patterns]
[1.3 Team management anti-patterns]
[1.4 Analysis anti-patterns]
[1.5 Software design anti-patterns]
[1.5.1 Object-oriented design anti-patterns]
[1.6 Programming anti-patterns]
[1.7 Methodological anti-patterns]
[1.8 Testing anti-patterns]
[1.9 Configuration management anti-patterns]
[1. 已知的反面模式]
[1.1 组织结构的反面模式]
* 从天而降的责任(accidental ownership):雇员们接手了一个与当前系统完全无关的系统,在没有合适的训练、学习或关心下就得维护它(在90年代的电话->网络管理员中很常见)
* 分析麻痹(Analysis paralysis):在项目的分析阶段付出的努力太少
* 引擎室里的船长(Captain in the engine room):团队带头人把时间和精力全花在技术问题上,没有人开船
* 摇钱树(cash cow):盈利的老产品通常会导致对新产品的自满
* 持续退化(Continuous obsolescence):不成比例地投入精力把系统移植到新环境下
* 经费转移(Cost migration):项目经费转移到弱势的部门或商业伙伴那里
* 危机模式(Crisis mode)或救火模式(firefighting mode):硬是等到火烧屁屁的时候才去解决问题,结果是每个问题都成了危机问题
* 委员会设计(Design by committee):很多人同时进行设计,却没有统一的看法
* 委员会扩张(Escalation of commitment):明知错了还不能收回之前的决定
* 英雄模式(Hero-mode):长期依赖成员的英雄式的努力来满足不可能的任务期限,同时又忽视从一开始就没有注重软件品质带来的损失
* 我早就说过(I told you so):某人之前的警告没得到重视,事后又被人发现是正确的,并引起了关注
* 主观管理(Management by hope):认为平静的表象就代表一切顺利
* 通过忽视的管理(Management by neglect):过多地委任
* 用数字管理(Management by numbers):过于关注非本质而又不易取得的数字指标
* Perkele管理(Management by perkele):用完全听不进异议的独裁作风进行管理
* 思考管理(Management by wondering):希望一个团队定义自己的目标,然后考虑他们要做什么
* 精神危险(Moral hazard):不让做决定的人知道他的决定会带来什么结果
* 蘑菇管理(Mushroom management):有事也不通知雇员或是错误地通知(像种蘑菇一样放在黑地里施肥)
* 不是这里发明的(Not invented here):拒绝使用组织外的主意或方案
* 精益求精(Polishing the polish):把已经完成的项目交给下属去做,禁止他们做其它的事,又报怨他们低效率
* 规模爬行(另外两个类似的词是复杂度陷阱和功能主义者):不适当控制项目的规模的增加
* 烟囱(Stovepipe):结构上支持数据主要在上下方面的流动,却禁止平行的通信
* 客户套牢(Vendor lock-in):使一个系统过于依赖外部提供的部件
* 小提琴弦组织(Violin string organization):高度调整和裁减却没有灵活性的组织
[1.2 项目管理的反面模式]
* 死亡征途(Death march):除了CEO,每个人都知道这个项目会完蛋。但是真相却被隐瞒下来,直到大限来临
* 拖后腿的无知(Heel dragging blindness):项目经理的无知拖了后腿。出于某些动机,员工趋向于减少努力来延长项目时限。例如,他们是按时间(而非结果)付费,又没有能顺利转移过去的后续项目
* 烟和镜(Smoke and mirros):展示还没完成的函数会是怎样
* 软件膨胀(Software bloat):允许系统的后续版本使用更多的资源
[1.3 团队管理的反面模式]
* 缺席的经理(Absentee manager):经理长时间不出现的情况
* Cage match negotiator:经理用“不惜一切代价也要取胜”的方式来管理
* Doppelganger:某些经理或同事刚才还平易近人,过了一下就变得难于相处
* 无底洞(Fruitless hoops):经理在做出决定前要求大量的(通常是无意义的)数据
* 黄金小孩(Golden child):依据人情而不是实际的表现,特殊的责任、机会、认可、奖励被给予团队成员
* 无头苍蝇(Headless chicken):经理总是处于恐慌中
* 领导而非经理(Leader not manager):经理是一个好的领导,却缺乏行政和管理能力
* 管理克隆(Managerial cloning):经理对所有人的雇佣和指导的方法都是一样的:像他们的老板
* 经理而非领导(Manager not leader):经理能胜任行政和管理职责,却缺乏领导能力
* 指标滥用(Metric abuse):恶意或是不适当地使用指标
* 好好先生(Mr. nice guy):经理想成为每个人的朋友
* 鸵鸟(Ostrich):有些人员整天做些空洞的事情却忽视那些需要在最后期限前被解决的事情还以为会没事,通常更希望看起来很忙,但实际上会浪费和用尽时间
* 平民英雄(Proletariat hero):口头上称赞普通员工技术如何如何之牛,实际上管理层只是把他们当成棋子,目的是有借口更多的摊派任务以及增加生产目标
* 得势的暴发户(Rising upstart):指这样一些潜在的新星,他们急不可耐地想要爬上去,不愿花费量些必要的时间去学习和成长
* 海鸥管理(Seagull management):飞进来,弄得鸡飞狗跳、一片儿狼藉,然后就拍拍屁股走人
* 懦弱的执行者(Spineless executive):管理者没有勇气来面对当前形势、来承担责任、或是来保护自己的下属
* 三个脑袋的骑士(Three-headed knight):没有决断力的管理者
* 终极武器(Ultimate weapon):有些人完全依赖自己的同事或是组织,好像他们自己只是一个导体,把问题全部传给别人
* 热身状态(Warm bodies):指有些员工几乎不能达到工作的最低要求,因此不断地从一个项目转到另一个项目,或是从一个团队换到另一个团队。
* 只会说是的人(Yes man):指一些管理者当面对CEO说的每句话都说是,CEO不在的情况
下他可能说的又是另一回事
[1.4 分析方式的反面模式]
* 尿布说明(Napkin specification):把给开发团队的功能或技术说明写在尿布上(即是说,不正式,又缺乏细节),和根本就没有说明一样
* 假需求(Phony requirements):所有的需求都是通过网络会议或是电话通知给开发团队的,没有任何功能、技术上的说明或其它说明文档
* 火箭说明(Retro-specification):在项目已经启动之后才开始写技术、功能说明
[1.5 通常的设计反面模式]
* 抽象倒置(Abstraction inversion):不把用户需要的功能直接提供出来,导致他们要
用更上层的函数来重复实现
* 用意不明(Ambiguous viewpoint):给出一个模型(通常是OOAD,面向对象分析与设计)却没有指出用意何在
* 大泥球(Big ball of mud):系统的结构不清晰
* 斑点(Blob):参考上帝对象(God object)
* 气体工厂(Gas factory):复杂到不必要的设计
* 输入问题(Input kludge):无法指出和实现对不正确的输入的处理
* 接口膨胀(Interface bloat):把一个接口做得过于强大以至于极其难以实现
* 魔力按键(Magic pushbutton):直接在接口的代码里编写实现,而不使用抽象
* 竞争危机(Race hazard):无法知道事件在不同顺序下发生时产生的结果
* 铁轨方案(Railroaded solution):由于没有预见和在设计方面欠缺灵活性,提出的方案即使很烂,也成了唯一选择
* 重复耦合(Re-coupling):不必要的对象依赖
* 烟囱系统(Stovepipe system):根本就不能维护的被病态的组合在一起的组件
* (Staralised schema):指这样的数据库方案,包含了两种用途的表,一是通用的,另一种是有针对性的
[1.5.1 面向对象设计的反面模式]
* 贫血的域模型(Anemic Domain Model):仅因为每个对象都要有属性和方法,而在使用域模型的时候没有加入非OOP的业务逻辑
* (BaseBean):继承一个工具类,而不是代理它
* 调用父类(Call super):需要子类调用父类被重载的方法
* 圆还是椭圆问题(Circle-ellipse problem):基于变量的子类化关系进行子类化(原句是Subtyping variable-types on the basis of value-subtypes)
* 空子类的错误(Empty subclass failure):创建不能通过“空子类测试”的类,因为它和直接从它继承而来没有做其它任何修改的子类表现得不同
* 上帝对象(God object):在设计的单一部分(某个类)集中了过多的功能
* 对象粪池(Object cesspool):复用那些不满足复用条件的对象
* 不羁的对象(Object orgy):没有成功封装对象,外部可以不受限制地访问它的内部
* 幽灵(Poltergeists):指这样一些对象,它们唯一的作用就是把信息传给其它对象
* 顺序耦合(Sequential coupling):指这样一些对象,它们的方法必须要按某种特定顺序调用
* 单例爱好者(Singletonitis):滥用单例(singleton)模式
* 又TMD来一层(Yet Another Fucking Layer):向程序中添加不必要的层次结构、库或是框架。自从第一本关于编程的模式的书出来之后这就变得很普遍。
* 唷唷问题(Yo-yo problem):一个结构(例如继承)因为过度分裂而变得难于理解
[1.6 编程方面的反面模式]
* 意外的复杂度(Accidental complexity):向一个方案中引入不必要的复杂度
* 积累再开火(Accumulate and fire):通过一系列全局变量设置函数的参数
* 在远处行动(Action at distance):意料之外的在系统分离的部分之间迭代
* 盲目信任(Blind faith):缺乏对bugfix或子函数返回值的正确性检查
* 船锚(Boat anchor):在系统中保留无用的部分
* bug磁铁(Bug magnet):指很少被调用以至于最容易引起错误的代码,或是易出错的构造或实践
* 忙循环(Busy spin):在等待的时候不断占用CUP,通常是因为采用了重复检查而不是适当的消息机制
* 缓存失败(Caching failure):错误被修正后忘记把错误标志复位
* 货运崇拜编程(Cargo cult programming):在不理解的情况下就使用模式和方法
* 检查类型而不是接口(Checking type instead of interface):仅是需要接口符合条件的情况下却检查对象是否为某个特定类型。可能导致空子类失败
* 代码动力(Code momentum):过于限制系统的一些部分,因为在其它部分反复对这部分的内容做出假设
* 靠异常编程(Coding by exception):当有特例被发现时才添加新代码去解决
* 隐藏错误(Error hiding):在显示给用户之前捕捉到错误信息,要么什么都不显示,要么显示无意义的信息
* 异常处理(Expection handling):使用编程语言的错误处理系统实现平常的编程逻辑
* 硬编码(Hard code):在实现过程中对系统环境作假设
* 熔岩流(Lava flow):保留不想要的(冗余的或是低质量的)代码,仅因为除去这些代码的代价太高或是会带来不可预期的结果
* loop-switch序列(Loop-switch sequence)使用循环结构来编写连续步骤而不是switch语句
* 魔幻数字(Magic numbers):在算法里直接使用数字,而不解释含义
* 魔幻字符串(Magic strings):直接在代码里使用常量字符串,例如用来比较,或是作为事件代码
* 猴子工作(Monkey work):指在一些代码复用性或设计上很差的项目中的反复出现的支持性的代码。通常会被避免或是匆忙完成,因此易于出错,有可能会很快变为bug磁铁。
* Packratting:由于长时间不及时释放动态分配的内存而消耗了过量的内存
* 类似保护(Parallel protectionism):随着代码变得复杂和脆弱,很容易就克隆出一个类似的的结构,而不是直接往现有的结构中添加一些琐碎的属性
* 巧合编程(Programming by accident):尝试用试验或是出错的方式解决问题,有时是因为很烂的文档或是一开始就没把东西搞清楚
* 馄饨代码(Ravioli code):系统中有许多对象都是松散连接的
* 软代码(Soft code):在配置文件里保存业务逻辑而不是在代码中
* 面条代码(Spaghetti code):指那些结构上完全不可理解的系统,尤其是因为误用代码结构
* 棉花里放羊毛(Wrapping wool in cottom):常见的情况是某些类的方法只有一行,就是调用框架的代码,而没有任何其它有用的抽象
[1.7 方法学上的反面模式]
* 拷贝粘贴编程(Copy and paste programming):拷贝(然后修改)现有的代码而不是假造通用的解决方案
* 拆除(De-factoring):去掉功能,把它转化成文档的过程
* 黄金大锤(Golden hammer):认为自己最喜欢的解决方案是到处通用的(见:银弹)
* 未必有之事(Improbability factor):认为已知的错误不会出现
* 低处的果子(Low hanging fruit):先处理更容易的问题而忽略更大更复杂的问题。这个问题有些类似于这种情况:科学、哲学和技术上的发现在早期都比较容易得到,一旦问题已经被人研究过了,再要有所创新就难了
* 不是这里做的(Not built here):见“重新发明轮子”、“不是这里发明的”
* 不成熟的优化(Premature optimization):在编码的早期追求代码的效率,牺牲了好的设计、可维护性、有时甚至是现实世界的效率
* 转换编程法(Programming by permutation):试图通过连续修改代码再看是否工作的方式来解决问题
* 重新发明方的轮子(Reinventing the square wheel):已经有一个很好的方案了,又再搞一个烂方案来替代它
* 重新发明轮子(Reinventing the wheel):无法采纳现有的成熟的方案
* 银弹(Silver bullet):认为自己最喜欢的技术方案能解决一个更大的问题
* 测试人员驱动开发(Tester driven development):软件工程的需求来自bug报告
[1.8 测试反面模式]
* 敌意测试(hostile testing):对抗实际的开发方案,使用过量的测试
* 自身测试(Meta-testing):过度设计测试过程以至于它本身都需要测试,也被称为“看门人的看门人”
* 移动标的(Moving target):连续修改设计和实现从而逃避现现有的测试过程
* 奴隶测试(Slave testing):通过发匿名电邮或贿赂的方式控制测试人员,从而达到股东的要求
[1.9 配置管理反面模式]
* 依赖的地狱(Dependency hell):需要的产品的版本导致的问题
* 路径地狱(Classpath hell):和特定库有关的问题,例如依赖关系和要满足程序运行所需的版本
* 扩展冲突(Extension conflict):苹果系统在Mac OS X版本之前的不同扩展的问题
* DLL地狱(DLL hell):不同版本带来的问题,DLL可见性和多版本问题,在微软的Windows上尤为突出
* JAR地狱(JAR hell):JAR文件不同版本或路径带来的问题,通常是由于不懂类加载模型导致的
译文:http://www.yeeyan.com/articles/view/27472/7244
[前言]
design pattern是设计模式,通常是前人在软件开发过程中积累出来的解决一些问题的现成套路,按它们来做可获益无穷。anti-pattern也是一些现成的套路,但它们是现成的错误套路,避免它们则亦可获益无穷。本文译者Korner Hill的更多其它翻译和原创文章可在blog上找到http://blog.csdn.net/KornerHill。
计算机领域内的很多词汇都缺少公认的中文翻译,anti-pattern也是如此,这里译为反面模式,乃是因为它本身是作为反面教材使用的模式。其实直接用“反面教材”更通俗易懂,但这里为了保持它与设计模式之间的内在关联,而使用了“反面模式”一词。
文中有些个别单词没有翻译,一是如bug和bugfix这样在计算机领域内已经广泛使用的词,二是像Staralised这种在字典里都查不到词,三是像perkele这种有文化背景的名字(perkele是芬兰神话里的雷神)。
有些地方即使翻译过来,可能读者还是不一定会明白,毕竟代码的事情不是纸上谈兵。例如Circle-ellipse problem,涉及的概念较多,虽然能翻译过来,但读者若要理解,还是得到wikipedia上再查。
翻译这篇文章确实很不容易,既要英文好,又要有编程的背景,最好还要有西方生活的背景,在下水平有限,很多地方翻译不到位,请各们谅解。
================================================================================
= 以下是译文部分
================================================================================
来自Wikipedia, 自由百科全书
在软件工程中,一个反面模式(anti-pattern或antipattern)指的是在实践中明显出现但又低效或是有待优化的设计模式。
Andrew Koenig在1995年造了anti-pattern这个词,灵感来自于GoF的《设计模式》一书。而这本书则在软件领域发明了“设计模式”(design pattern)一词。三年后antipattern因《AntiPatterns》这本书而获得普及,而它的使用也从软件设计领域扩展到了日常的社会互动中。按《AntiPatterns》作者的说法,可以用至少两个关键因素来把反面模式和不良习惯、错误的实践或糟糕的想法区分开来:
* 行动、过程和结构中的一些重复出现的乍一看是有益的,但最终得不偿失的模式
* 在实践中证明且可重复的清晰记录的重构方案
很多反面模式只相当于是错误、咆哮、不可解的问题、或是可能可以避免的糟糕的实践,它们的名字通常都是一些用反话构成的词语。有些时候陷阱(pitfalls)或黑色模式(dark patterns)这些不正式的说法会被用来指代各类反复出现的糟糕的解决方法。因此,一些有争议的候选的反面模式不会被正式承认。
原文:http://en.wikipedia.org/wiki/Anti-pattern
译文:http://www.yeeyan.com/articles/view/27472/7244
[目录]
[1. 已知的反面模式]
[1.1 组织结构的反面模式]
[1.2 项目管理的反面模式]
[1.3 团队管理的反面模式]
[1.4 分析方式的反面模式]
[1.5 通常的设计反面模式]
[1.5.1 面向对象设计的反面模式]
[1.6 编程方面的反面模式]
[1.7 方法学上的反面模式]
[1.8 测试反面模式]
[1.9 配置管理反面模式]
[Contents]
[1 Known anti-patterns]
[1.1 Organizational anti-patterns]
[1.2 Project management anti-patterns]
[1.3 Team management anti-patterns]
[1.4 Analysis anti-patterns]
[1.5 Software design anti-patterns]
[1.5.1 Object-oriented design anti-patterns]
[1.6 Programming anti-patterns]
[1.7 Methodological anti-patterns]
[1.8 Testing anti-patterns]
[1.9 Configuration management anti-patterns]
[1. 已知的反面模式]
[1.1 组织结构的反面模式]
* 从天而降的责任(accidental ownership):雇员们接手了一个与当前系统完全无关的系统,在没有合适的训练、学习或关心下就得维护它(在90年代的电话->网络管理员中很常见)
* 分析麻痹(Analysis paralysis):在项目的分析阶段付出的努力太少
* 引擎室里的船长(Captain in the engine room):团队带头人把时间和精力全花在技术问题上,没有人开船
* 摇钱树(cash cow):盈利的老产品通常会导致对新产品的自满
* 持续退化(Continuous obsolescence):不成比例地投入精力把系统移植到新环境下
* 经费转移(Cost migration):项目经费转移到弱势的部门或商业伙伴那里
* 危机模式(Crisis mode)或救火模式(firefighting mode):硬是等到火烧屁屁的时候才去解决问题,结果是每个问题都成了危机问题
* 委员会设计(Design by committee):很多人同时进行设计,却没有统一的看法
* 委员会扩张(Escalation of commitment):明知错了还不能收回之前的决定
* 英雄模式(Hero-mode):长期依赖成员的英雄式的努力来满足不可能的任务期限,同时又忽视从一开始就没有注重软件品质带来的损失
* 我早就说过(I told you so):某人之前的警告没得到重视,事后又被人发现是正确的,并引起了关注
* 主观管理(Management by hope):认为平静的表象就代表一切顺利
* 通过忽视的管理(Management by neglect):过多地委任
* 用数字管理(Management by numbers):过于关注非本质而又不易取得的数字指标
* Perkele管理(Management by perkele):用完全听不进异议的独裁作风进行管理
* 思考管理(Management by wondering):希望一个团队定义自己的目标,然后考虑他们要做什么
* 精神危险(Moral hazard):不让做决定的人知道他的决定会带来什么结果
* 蘑菇管理(Mushroom management):有事也不通知雇员或是错误地通知(像种蘑菇一样放在黑地里施肥)
* 不是这里发明的(Not invented here):拒绝使用组织外的主意或方案
* 精益求精(Polishing the polish):把已经完成的项目交给下属去做,禁止他们做其它的事,又报怨他们低效率
* 规模爬行(另外两个类似的词是复杂度陷阱和功能主义者):不适当控制项目的规模的增加
* 烟囱(Stovepipe):结构上支持数据主要在上下方面的流动,却禁止平行的通信
* 客户套牢(Vendor lock-in):使一个系统过于依赖外部提供的部件
* 小提琴弦组织(Violin string organization):高度调整和裁减却没有灵活性的组织
[1.2 项目管理的反面模式]
* 死亡征途(Death march):除了CEO,每个人都知道这个项目会完蛋。但是真相却被隐瞒下来,直到大限来临
* 拖后腿的无知(Heel dragging blindness):项目经理的无知拖了后腿。出于某些动机,员工趋向于减少努力来延长项目时限。例如,他们是按时间(而非结果)付费,又没有能顺利转移过去的后续项目
* 烟和镜(Smoke and mirros):展示还没完成的函数会是怎样
* 软件膨胀(Software bloat):允许系统的后续版本使用更多的资源
[1.3 团队管理的反面模式]
* 缺席的经理(Absentee manager):经理长时间不出现的情况
* Cage match negotiator:经理用“不惜一切代价也要取胜”的方式来管理
* Doppelganger:某些经理或同事刚才还平易近人,过了一下就变得难于相处
* 无底洞(Fruitless hoops):经理在做出决定前要求大量的(通常是无意义的)数据
* 黄金小孩(Golden child):依据人情而不是实际的表现,特殊的责任、机会、认可、奖励被给予团队成员
* 无头苍蝇(Headless chicken):经理总是处于恐慌中
* 领导而非经理(Leader not manager):经理是一个好的领导,却缺乏行政和管理能力
* 管理克隆(Managerial cloning):经理对所有人的雇佣和指导的方法都是一样的:像他们的老板
* 经理而非领导(Manager not leader):经理能胜任行政和管理职责,却缺乏领导能力
* 指标滥用(Metric abuse):恶意或是不适当地使用指标
* 好好先生(Mr. nice guy):经理想成为每个人的朋友
* 鸵鸟(Ostrich):有些人员整天做些空洞的事情却忽视那些需要在最后期限前被解决的事情还以为会没事,通常更希望看起来很忙,但实际上会浪费和用尽时间
* 平民英雄(Proletariat hero):口头上称赞普通员工技术如何如何之牛,实际上管理层只是把他们当成棋子,目的是有借口更多的摊派任务以及增加生产目标
* 得势的暴发户(Rising upstart):指这样一些潜在的新星,他们急不可耐地想要爬上去,不愿花费量些必要的时间去学习和成长
* 海鸥管理(Seagull management):飞进来,弄得鸡飞狗跳、一片儿狼藉,然后就拍拍屁股走人
* 懦弱的执行者(Spineless executive):管理者没有勇气来面对当前形势、来承担责任、或是来保护自己的下属
* 三个脑袋的骑士(Three-headed knight):没有决断力的管理者
* 终极武器(Ultimate weapon):有些人完全依赖自己的同事或是组织,好像他们自己只是一个导体,把问题全部传给别人
* 热身状态(Warm bodies):指有些员工几乎不能达到工作的最低要求,因此不断地从一个项目转到另一个项目,或是从一个团队换到另一个团队。
* 只会说是的人(Yes man):指一些管理者当面对CEO说的每句话都说是,CEO不在的情况
下他可能说的又是另一回事
[1.4 分析方式的反面模式]
* 尿布说明(Napkin specification):把给开发团队的功能或技术说明写在尿布上(即是说,不正式,又缺乏细节),和根本就没有说明一样
* 假需求(Phony requirements):所有的需求都是通过网络会议或是电话通知给开发团队的,没有任何功能、技术上的说明或其它说明文档
* 火箭说明(Retro-specification):在项目已经启动之后才开始写技术、功能说明
[1.5 通常的设计反面模式]
* 抽象倒置(Abstraction inversion):不把用户需要的功能直接提供出来,导致他们要
用更上层的函数来重复实现
* 用意不明(Ambiguous viewpoint):给出一个模型(通常是OOAD,面向对象分析与设计)却没有指出用意何在
* 大泥球(Big ball of mud):系统的结构不清晰
* 斑点(Blob):参考上帝对象(God object)
* 气体工厂(Gas factory):复杂到不必要的设计
* 输入问题(Input kludge):无法指出和实现对不正确的输入的处理
* 接口膨胀(Interface bloat):把一个接口做得过于强大以至于极其难以实现
* 魔力按键(Magic pushbutton):直接在接口的代码里编写实现,而不使用抽象
* 竞争危机(Race hazard):无法知道事件在不同顺序下发生时产生的结果
* 铁轨方案(Railroaded solution):由于没有预见和在设计方面欠缺灵活性,提出的方案即使很烂,也成了唯一选择
* 重复耦合(Re-coupling):不必要的对象依赖
* 烟囱系统(Stovepipe system):根本就不能维护的被病态的组合在一起的组件
* (Staralised schema):指这样的数据库方案,包含了两种用途的表,一是通用的,另一种是有针对性的
[1.5.1 面向对象设计的反面模式]
* 贫血的域模型(Anemic Domain Model):仅因为每个对象都要有属性和方法,而在使用域模型的时候没有加入非OOP的业务逻辑
* (BaseBean):继承一个工具类,而不是代理它
* 调用父类(Call super):需要子类调用父类被重载的方法
* 圆还是椭圆问题(Circle-ellipse problem):基于变量的子类化关系进行子类化(原句是Subtyping variable-types on the basis of value-subtypes)
* 空子类的错误(Empty subclass failure):创建不能通过“空子类测试”的类,因为它和直接从它继承而来没有做其它任何修改的子类表现得不同
* 上帝对象(God object):在设计的单一部分(某个类)集中了过多的功能
* 对象粪池(Object cesspool):复用那些不满足复用条件的对象
* 不羁的对象(Object orgy):没有成功封装对象,外部可以不受限制地访问它的内部
* 幽灵(Poltergeists):指这样一些对象,它们唯一的作用就是把信息传给其它对象
* 顺序耦合(Sequential coupling):指这样一些对象,它们的方法必须要按某种特定顺序调用
* 单例爱好者(Singletonitis):滥用单例(singleton)模式
* 又TMD来一层(Yet Another Fucking Layer):向程序中添加不必要的层次结构、库或是框架。自从第一本关于编程的模式的书出来之后这就变得很普遍。
* 唷唷问题(Yo-yo problem):一个结构(例如继承)因为过度分裂而变得难于理解
[1.6 编程方面的反面模式]
* 意外的复杂度(Accidental complexity):向一个方案中引入不必要的复杂度
* 积累再开火(Accumulate and fire):通过一系列全局变量设置函数的参数
* 在远处行动(Action at distance):意料之外的在系统分离的部分之间迭代
* 盲目信任(Blind faith):缺乏对bugfix或子函数返回值的正确性检查
* 船锚(Boat anchor):在系统中保留无用的部分
* bug磁铁(Bug magnet):指很少被调用以至于最容易引起错误的代码,或是易出错的构造或实践
* 忙循环(Busy spin):在等待的时候不断占用CUP,通常是因为采用了重复检查而不是适当的消息机制
* 缓存失败(Caching failure):错误被修正后忘记把错误标志复位
* 货运崇拜编程(Cargo cult programming):在不理解的情况下就使用模式和方法
* 检查类型而不是接口(Checking type instead of interface):仅是需要接口符合条件的情况下却检查对象是否为某个特定类型。可能导致空子类失败
* 代码动力(Code momentum):过于限制系统的一些部分,因为在其它部分反复对这部分的内容做出假设
* 靠异常编程(Coding by exception):当有特例被发现时才添加新代码去解决
* 隐藏错误(Error hiding):在显示给用户之前捕捉到错误信息,要么什么都不显示,要么显示无意义的信息
* 异常处理(Expection handling):使用编程语言的错误处理系统实现平常的编程逻辑
* 硬编码(Hard code):在实现过程中对系统环境作假设
* 熔岩流(Lava flow):保留不想要的(冗余的或是低质量的)代码,仅因为除去这些代码的代价太高或是会带来不可预期的结果
* loop-switch序列(Loop-switch sequence)使用循环结构来编写连续步骤而不是switch语句
* 魔幻数字(Magic numbers):在算法里直接使用数字,而不解释含义
* 魔幻字符串(Magic strings):直接在代码里使用常量字符串,例如用来比较,或是作为事件代码
* 猴子工作(Monkey work):指在一些代码复用性或设计上很差的项目中的反复出现的支持性的代码。通常会被避免或是匆忙完成,因此易于出错,有可能会很快变为bug磁铁。
* Packratting:由于长时间不及时释放动态分配的内存而消耗了过量的内存
* 类似保护(Parallel protectionism):随着代码变得复杂和脆弱,很容易就克隆出一个类似的的结构,而不是直接往现有的结构中添加一些琐碎的属性
* 巧合编程(Programming by accident):尝试用试验或是出错的方式解决问题,有时是因为很烂的文档或是一开始就没把东西搞清楚
* 馄饨代码(Ravioli code):系统中有许多对象都是松散连接的
* 软代码(Soft code):在配置文件里保存业务逻辑而不是在代码中
* 面条代码(Spaghetti code):指那些结构上完全不可理解的系统,尤其是因为误用代码结构
* 棉花里放羊毛(Wrapping wool in cottom):常见的情况是某些类的方法只有一行,就是调用框架的代码,而没有任何其它有用的抽象
[1.7 方法学上的反面模式]
* 拷贝粘贴编程(Copy and paste programming):拷贝(然后修改)现有的代码而不是假造通用的解决方案
* 拆除(De-factoring):去掉功能,把它转化成文档的过程
* 黄金大锤(Golden hammer):认为自己最喜欢的解决方案是到处通用的(见:银弹)
* 未必有之事(Improbability factor):认为已知的错误不会出现
* 低处的果子(Low hanging fruit):先处理更容易的问题而忽略更大更复杂的问题。这个问题有些类似于这种情况:科学、哲学和技术上的发现在早期都比较容易得到,一旦问题已经被人研究过了,再要有所创新就难了
* 不是这里做的(Not built here):见“重新发明轮子”、“不是这里发明的”
* 不成熟的优化(Premature optimization):在编码的早期追求代码的效率,牺牲了好的设计、可维护性、有时甚至是现实世界的效率
* 转换编程法(Programming by permutation):试图通过连续修改代码再看是否工作的方式来解决问题
* 重新发明方的轮子(Reinventing the square wheel):已经有一个很好的方案了,又再搞一个烂方案来替代它
* 重新发明轮子(Reinventing the wheel):无法采纳现有的成熟的方案
* 银弹(Silver bullet):认为自己最喜欢的技术方案能解决一个更大的问题
* 测试人员驱动开发(Tester driven development):软件工程的需求来自bug报告
[1.8 测试反面模式]
* 敌意测试(hostile testing):对抗实际的开发方案,使用过量的测试
* 自身测试(Meta-testing):过度设计测试过程以至于它本身都需要测试,也被称为“看门人的看门人”
* 移动标的(Moving target):连续修改设计和实现从而逃避现现有的测试过程
* 奴隶测试(Slave testing):通过发匿名电邮或贿赂的方式控制测试人员,从而达到股东的要求
[1.9 配置管理反面模式]
* 依赖的地狱(Dependency hell):需要的产品的版本导致的问题
* 路径地狱(Classpath hell):和特定库有关的问题,例如依赖关系和要满足程序运行所需的版本
* 扩展冲突(Extension conflict):苹果系统在Mac OS X版本之前的不同扩展的问题
* DLL地狱(DLL hell):不同版本带来的问题,DLL可见性和多版本问题,在微软的Windows上尤为突出
* JAR地狱(JAR hell):JAR文件不同版本或路径带来的问题,通常是由于不懂类加载模型导致的
发表评论
-
(转)重述——组合/聚合复用原则
2013-10-30 09:10 1096组合/聚合复用原则(Com ... -
(转)重述——迪米特法则
2013-10-29 10:51 1298迪米特法则(Law of Demeter) 又叫最 ... -
(转)重述——依赖倒置原则
2013-10-29 10:50 857依赖倒置原则(Dependence Inversion Pri ... -
(转)重述——里氏替换原则
2013-10-29 10:46 1504里氏替换原则(Liskov Substitution Prin ... -
(转)重述——开放封闭原则
2013-10-29 10:41 855开发封闭原则(Open-Closed Principle OC ... -
(转)重述——单一职责原则
2013-10-29 10:37 866单一职责原则(Single Respo ... -
(转)Java之美[从菜鸟到高手演变]系列之博文阅读导航
2013-10-28 17:00 1779Java之美[从菜鸟到高手演变]系列之博文阅读导航 http: ... -
(转)面向接口编程详解
2013-10-25 12:34 5老文章,自己学习。 面向接口编程详解(一) http://w ... -
(转)细说业务逻辑
2013-10-25 12:30 597前篇 http://www.cnblogs.com/leoo2 ... -
励志感悟
2013-10-15 09:14 0不是大项目就能锻炼人,能够锻炼和提升自我的只有求知的欲望 ... -
IBM之学习线路
2013-10-14 18:15 0Java 并发性 为 Java 平台构建和测试并发应用程序 h ... -
精品站点集锦
2013-10-11 19:58 00. jar包搜索 http://www.jarfinder. ... -
(转)中国历史上最高水平的36首诗词排行榜
2013-09-26 19:39 1506桃花坞里桃花庵,桃花 ... -
(转)浅谈HTTPS传输协议原理
2013-09-13 16:04 0我们常常在使用网上银行时看到的连接都是以“https”开始的, ... -
LNMP
2013-04-07 17:22 0简介 LNMP是一个基于CentOS/Debian编写的Ng ... -
业务系统与监控系统并存
2013-03-31 15:41 936无论任何系统,一定要有监控系统并存,当故障发生的时候你 ... -
神奇的莫比乌斯带
2012-12-18 11:30 3314这学期有幸承担学校人文讲坛的任务,原来任四年级数学老师的时候, ... -
Java 多线程并发控制框架(转)
2012-12-14 11:28 1266Java 提供了语言级 ... -
(转)设计模式综述
2012-11-02 13:29 833设计模式主要分三个类 ... -
(转)面向接口编程详解(三)
2012-10-28 12:55 954讲解几个设计模式 ...
相关推荐
anti-pattern 没想到什么好词,且就叫反面模式 反模式1:‘Browse-up’ for administration(浏览模式管理的不安全性) Unfortunately it is all too common to see ‘browse-up’ approaches to administering ...
软件工程第三章实验报告.docx
第三章-第八节通信礼仪.ppt
智能家居股份合作协议.docx
内容概要:本文详细介绍了基于西门子S7-1200 PLC的双轴定位控制系统在电池焊接项目中的应用。主要内容涵盖双轴定位算法的设计与实现,包括使用SCL语言编写的运动控制函数块,以及梯形图用于处理IO互锁和焊接时序控制。文中还讨论了威纶通触摸屏的界面设计,如动态元素映射、宏指令的应用,以及电气图纸的安全回路设计。此外,文章分享了多个调试技巧和注意事项,如加速度参数设置、伺服驱动器订货号核对、BOM清单管理等。 适合人群:从事工业自动化领域的工程师和技术人员,尤其是熟悉PLC编程和触摸屏界面设计的专业人士。 使用场景及目标:适用于需要深入了解PLC编程、运动控制算法、触摸屏界面设计及电气图纸绘制的工程项目。目标是提高双轴定位控制系统的精度和稳定性,确保电池焊接的质量和安全性。 其他说明:文中提供了完整的工程文件包下载链接,并强调了在实际应用中需要注意的具体事项,如硬件配置检查、参数调整等。
内容概要:本文详细介绍了如何利用Simulink和Carsim进行联合仿真,实现基于PID(比例-积分-微分)和MPC(模型预测控制)的自适应巡航控制系统。首先阐述了Carsim参数设置的关键步骤,特别是cpar文件的配置,包括车辆基本参数、悬架系统参数和转向系统参数的设定。接着展示了Matlab S函数的编写方法,分别针对PID控制和MPC控制提供了详细的代码示例。随后讨论了Simulink中车辆动力学模型的搭建,强调了模块间的正确连接和参数设置的重要性。最后探讨了远程指导的方式,帮助解决仿真过程中可能出现的问题。 适合人群:从事汽车自动驾驶领域的研究人员和技术人员,尤其是对Simulink和Carsim有一定了解并希望深入学习联合仿真的从业者。 使用场景及目标:适用于需要验证和优化自适应巡航控制、定速巡航及紧急避撞等功能的研究和开发项目。目标是提高车辆行驶的安全性和舒适性,确保控制算法的有效性和可靠性。 其他说明:文中不仅提供了理论知识,还有大量实用的代码示例和避坑指南,有助于读者快速上手并应用于实际工作中。此外,还提到了远程调试技巧,进一步提升了仿真的成功率。
内容概要:本文深入探讨了利用MATLAB/Simulink搭建变压器励磁涌流仿真模型的方法和技术。首先介绍了空载合闸励磁涌流仿真模型的搭建步骤,包括选择和配置电源模块、变压器模块以及设置相关参数。文中详细讲解了如何通过代码生成交流电压信号和设置变压器的变比,同时强调了铁芯饱和特性和合闸角控制的重要性。此外,还讨论了电源简化模型的应用及其优势,如使用受控电压源替代复杂电源模块。为了更好地理解和分析仿真结果,文章提供了绘制励磁涌流曲线的具体方法,并展示了如何提取和分析涌流特征量,如谐波含量和谐波畸变率。最后,文章指出通过调整电源和变压器参数,可以实现针对不同应用场景的定制化仿真,从而为实际工程应用提供理论支持和技术指导。 适合人群:从事电力系统研究、变压器设计及相关领域的科研人员、工程师和技术爱好者。 使用场景及目标:适用于希望深入了解变压器励磁涌流特性的研究人员,旨在帮助他们掌握MATLAB/Simulink仿真工具的使用技巧,提高对励磁涌流现象的理解和预测能力,进而优化继电保护系统的设计。 其他说明:文中不仅提供了详细的建模步骤和代码示例,还分享了一些实用的经验和技巧,如考虑磁滞效应对涌流的影响、避免理想断路器带来的误差等。这些内容有助于读者在实践中获得更加准确可靠的仿真结果。
内容概要:本文详细介绍了利用三菱FX3U PLC与Factory IO通讯仿真进行PID液位调节的方法,旨在降低学习PID控制的成本和难度。文中首先指出了传统硬件学习PID控制面临的高昂成本和复杂接线问题,随后介绍了仿真程序的优势,包括PID配置参数、调节参数、自整定和手动整定的学习方法。接着阐述了所需的设备和软件环境,以及具体的代码示例和寄存器配置。最后,通过实例展示了如何通过仿真环境进行PID参数调整和测试,验证了该方案的有效性和实用性。 适合人群:初学者和有一定PLC基础的技术人员,特别是那些希望通过低成本方式学习PID控制的人群。 使用场景及目标:适用于希望在不购买昂贵硬件的情况下,快速掌握PID控制原理和技术的应用场景。目标是通过仿真环境,熟悉PID参数配置和调整,最终能够应用于实际工业控制系统中。 其他说明:本文不仅提供了理论指导,还给出了详细的实践步骤和代码示例,使读者能够在实践中更好地理解和掌握PID控制技术。同时,强调了仿真环境与实际项目的相似性,便于知识迁移。
智慧城市树木二维码智能管理系统概述.docx
内容概要:本文详细介绍了基于.NET框架和Oracle数据库构建的大型MES(制造执行系统)生产制造管理系统的源码结构及其技术特点。该系统采用了BS架构,适用于Web端和WPF客户端,涵盖了从数据库设计、业务逻辑处理到前端展示等多个方面。文中不仅提供了具体的代码示例,还深入剖析了系统的技术难点,如Oracle数据库的高效连接方式、多线程处理、实时数据推送以及高级特性(如分区表、压缩技术和批量操作)的应用。此外,作者还分享了一些关于系统部署和维护的经验。 适合人群:主要面向拥有五年以上.NET开发经验的专业人士,特别是那些对Oracle数据库有一定了解并且参与过大中型项目开发的技术人员。 使用场景及目标:①帮助开发者深入了解MES系统的工作原理和技术实现;②为现有的MES系统提供优化思路;③作为学习资料,用于掌握.NET框架与Oracle数据库的最佳实践。 其他说明:尽管缺少完整的安装说明和数据库备份文件,但凭借丰富的代码片段和技术细节,这套源码仍然是一个宝贵的学习资源。同时,文中提到的一些技术点也可以应用于其他类型的工业控制系统或企业管理信息系统。
lesson6_点阵.zip
OpenNMS 依赖组件 jicmp 的完整解析与安装指南 一、jicmp 的核心作用 ICMP 协议支持 jicmp(Java Interface for ICMP)是 OpenNMS 实现网络设备可达性检测(如 Ping)的关键组件,通过原生代码高效处理 ICMP 报文,替代纯 Java 实现的性能瓶颈17。 依赖版本要求:OpenNMS 33.1.5 需 jicmp >= 3.0.0,以支持 IPv6 及多线程优化7。 与 jicmp6 的协同 jicmp6 是 jicmp 的扩展组件,专用于 IPv6 网络环境检测,二者共同构成 OpenNMS 网络监控的底层通信基础78。 二、jicmp 安装问题的根源 仓库版本不匹配 OpenNMS 官方旧版仓库(如 opennms-repo-stable-rhel6)仅提供 jicmp-2.0.5 及更早版本,无法满足新版 OpenNMS 的依赖需求78。 典型错误:Available: jicmp-2.0.5-1.el6.i386,但 Requires: jicmp >= 3.0.07。 手动编译未注册到包管理器 手动编译的 jicmp 未生成 RPM 包,导致 yum 无法识别已安装的依赖,仍尝试从仓库拉取旧版本57。 三、解决方案:正确安装 jicmp 3.0 通过源码编译生成 RPM 包 bash Copy Code # 安装编译工具链 yum install -y rpm-build checkinstall gcc-c++ autoconf automake libtool # 编译并生成 jicmp-3.0.0 RPM wget https://sourceforge.net/projects/opennms/files/JICMP/stable-3.x/j
机械CAD零件图.ppt
内容概要:本文详细介绍了制冷站智能群控管理系统的构成及其核心技术实现。首先阐述了系统的四大组成部分:环境感知模块、数据处理模块、决策控制模块以及设备控制模块。接着通过具体的Python代码示例展示了如何利用MQTT协议进行设备间的通信,实现了温度控制等功能。此外,文中还探讨了数据处理中的噪声过滤方法、设备控制中的状态锁定机制、以及采用强化学习进行能效优化的具体案例。最后展望了未来的发展方向,如引入能量管理和AI集成等。 适合人群:从事制冷站自动化控制领域的工程师和技术人员,尤其是对智能群控管理系统感兴趣的从业者。 使用场景及目标:适用于希望提升制冷站自动化水平的企业和个人。目标在于提高系统的稳定性和效率,减少人为干预,实现节能减排。 其他说明:文章不仅提供了理论性的介绍,还有大量的实战经验和代码片段分享,有助于读者更好地理解和应用相关技术。
内容概要:本文详细介绍了将卷积神经网络(CNN)从软件到硬件的全过程部署,特别是在FPGA上的实现方法。首先,作者使用TensorFlow 2构建了一个简单的CNN模型,并通过Python代码实现了模型的训练和权值导出。接着,作者用Verilog手写了CNN加速器的硬件代码,展示了如何通过参数化配置优化加速效果。硬件部分采用了滑动窗口和流水线结构,确保高效执行卷积操作。此外,文中还讨论了硬件调试过程中遇到的问题及其解决方案,如ReLU激活函数的零值处理和权值存储顺序的对齐问题。最后,作者强调了参数化设计的重要性,使得硬件可以在速度和面积之间灵活调整。 适合人群:对深度学习和FPGA感兴趣的开发者,尤其是有一定编程基础和技术背景的研究人员。 使用场景及目标:适用于希望深入了解CNN算法硬件实现的人群,目标是掌握从软件到硬件的完整部署流程,以及如何通过FPGA加速深度学习任务。 其他说明:文中提供了详细的代码片段和调试经验,有助于读者更好地理解和实践。同时,项目代码可在GitHub上获取,方便进一步研究和改进。
内容概要:本文详细介绍了无人驾驶车辆高速MPC(模型预测控制)控制系统的复现过程,主要涉及MATLAB和CarSim软件工具的应用。作者通过调整caraim文件、构建Simulink控制逻辑以及优化MPC算法,将原有的直线跟车场景成功转换为双移线场景。文中不仅展示了具体的技术实现步骤,如路径点设置、权重矩阵调整、采样时间对齐等,还分享了调试过程中遇到的问题及其解决方案,如参数不匹配、模型不收敛等。最终实现了车辆在虚拟环境中按预定双移线轨迹行驶的目标。 适合人群:从事无人驾驶车辆研究和技术开发的专业人士,尤其是对MPC控制算法感兴趣的工程师。 使用场景及目标:适用于需要深入了解无人驾驶车辆控制系统的设计与实现的研究人员和技术开发者。目标是帮助读者掌握如何利用MATLAB和CarSim进行无人驾驶车辆的模拟实验,特别是在高速场景下的双移线控制。 其他说明:文章强调了MPC在高速场景下的挑战性和调参技巧,提供了宝贵的实践经验。同时提醒读者注意环境配置、控制器核心代码解析以及联合仿真可能出现的问题。
监控场景下基于CLIP的细粒度目标检测方法.pdf
内容概要:本文详细介绍了如何使用MATLAB进行频谱和功率谱分析,涵盖了从基础概念到高级应用的各个方面。首先,通过生成人工信号并绘制时域图,帮助读者熟悉基本操作。接着,深入探讨了频谱分析的关键步骤,如快速傅里叶变换(FFT)、窗口函数的选择、频谱横坐标的正确转换等。对于功率谱分析,则介绍了Welch法及其具体实现。针对真实数据处理,讨论了如何读取外部数据、处理非均匀采样、去除趋势项等问题,并提供了多种实用技巧,如滑动平均、自动标注主要频率成分等。此外,还强调了一些常见的错误和注意事项,确保读者能够避免常见陷阱。 适用人群:适用于具有一定MATLAB基础的科研人员、工程师和技术爱好者,特别是那些从事信号处理、通信工程、机械振动分析等领域的人士。 使用场景及目标:① 学习如何使用MATLAB进行频谱和功率谱分析;② 掌握处理实际工程中复杂信号的方法;③ 提高对信号特征的理解能力,以便更好地应用于故障诊断、质量检测等实际工作中。 其他说明:文中提供的代码片段可以直接用于实践,读者可以根据自己的需求进行适当修改。通过跟随文中的步骤,读者不仅能够学会如何绘制频谱图和功率谱图,还能深入了解背后的数学原理和技术细节。 标签1,MATLAB,频谱分析,功率谱,Welch法,FFT
内容概要:本文详细介绍了基于FAST与MATLAB/Simulink联合仿真平台,对5MW非线性风力发电机进行统一变桨(CPC)和独立变桨(IPC)控制策略的研究。首先,通过将OpenFAST编译成Simulink可调用的S-Function模块,构建了联合仿真环境。接着,分别实现了统一变桨和独立变桨的PID控制器,并在三维湍流风场中进行了性能测试。结果显示,独立变桨在转速稳定性和载荷控制方面表现出色,能够显著降低叶根挥舞弯矩和偏航力矩,从而提高风机的可靠性和使用寿命。然而,独立变桨也带来了作动器磨损增加的问题。 适合人群:从事风电控制系统设计、仿真建模以及希望深入了解变桨控制策略的研发工程师和技术研究人员。 使用场景及目标:适用于需要评估不同变桨控制策略在复杂风场条件下的性能表现,优化风机运行效率和可靠性,以及探索新的控制算法的应用场景。 其他说明:文中提供了详细的模型搭建步骤、关键代码片段和仿真结果分析,并附有相关参考文献和GitHub资源链接,方便读者进一步深入研究。
内容概要:本文详细介绍了如何利用S7-200 PLC和组态王软件对Z35摇臂钻床进行控制系统升级改造。主要内容涵盖IO分配、梯形图编程、接线图与原理图设计以及组态王的画面制作。通过合理的IO分配确保信号正确传递,梯形图编程实现了各种控制逻辑,如摇臂上升/下降、主轴启动/停止等,并加入了互锁机制保障安全性。接线图展示了PLC与外部设备的具体连接方式,而原理图则揭示了整个系统的运作机制。组态王创建的人机界面使得操作更加直观便捷。 适合人群:从事工业自动化领域的工程师和技术人员,特别是那些熟悉PLC编程和HMI开发的专业人士。 使用场景及目标:适用于需要对老旧机械设备进行现代化改造的企业或单位,旨在提高生产设备的安全性和工作效率,降低维护成本。 其他说明:文中提供了多个具体的实例和技巧,帮助读者更好地理解和应用相关技术和方法。此外,还分享了一些调试过程中遇到的问题及其解决方案,为实际项目的实施提供宝贵的参考经验。