如何避免程序员的大脑超载？

富含逻辑与计算的程序员职业，并非任何人都可以胜任，那么对于身处其中的开发者，该怎么做，才能减轻自己脑部的压力？

作者 | Javier Casas Velasco

译者 | 弯月，责编 | 屠敏

出品 | CSDN（ID：CSDNnews）

以下为译文：

心理学中有一篇古老但非常重要的论文《神奇的数字：7±2：我们信息加工能力的局限》（The Magical Number Seven, Plus or Minus Two: Some Limits on Our Capacity for Processing Information）。作者对大脑处理信息的极限进行了定量研究：人脑可以同时处理5-9个概念。这其中有许多有趣的含义，但对于我们这些软件开发人员来说，有两个含义非常重要：

构造（模型、实现、设计、模式等等）越简单越好，因为你可以用更少的概念来描述它们。
良好的抽象自带的特殊规则越少越好，而且最好没有惊喜和意外，因为同样你只需用更少的概念来描述它们。

说到底，这是一场努力让占据大脑空间的概念趋近最少的战斗，因为大脑空间非常稀缺。

简单的构造

查尔斯·霍尔曾说：

构建一项软件设计有两种方式：一种是将软件设计得足够简单以至于明显找不到缺陷；另一种是软件设计得足够复杂以至于找不到明显的缺陷。

不幸的是，他还补充了一句：

第一种方法要困难得多。

在软件开发中，添加一个模块、一个类非常容易，代码也会越来越多。这固然可以解决大多数软件的需求，但需要的代码越来越多，获得的结果却越来越少。Jamie Zawinski曾说：

每个程序都会尝试扩展，直到能够阅读邮件。无法进行这种扩展的程序都将被它们所取代。

本质上，我们扩展程序是为了提供越来越多的功能。我们添加更多模块、更多类和更多的代码，而且添加的每一段代码都需要与之前的代码协同工作，故而随着各段代码之间的交互无限扩展，程序的复杂性也呈指数激增。我们这么做是因为这种做法很简单，至少在刚开始的时候很简单。

另一方面，制作尽可能简单的东西实际上非常困难。你需要寻找潜在的模式和行为，还需要去除不适合的东西。但是，最终这种方式制作的东西更好，因为你使用的概念较少，也无需浪费过多脑细胞就可以描述这些模式和行为，这意味着你可以专注于整体，而不必在意太多细节。

检测过于复杂的构造

实际上，检测过于复杂和臃肿的构造也并非难事。你只需查看一下手册。如果手册用大量文字描述了构造的上下文，则表示这个构造可能过于复杂。

让我们来看一个例子：AbstractFactory模式。为了描述该模式的工作方式，我们需要描述很多名称：

AbstractFactory：接口
<<creates>>：操作
Factory1（ConcreteFactory）
ProductA、ProductB：接口
ProductA1、ProductB1：类
new：关键字
抽象工厂类图
:Client、factory:Factory1：序列图

所有这些名称和图表之所以存在是因为制造复杂度比减少复杂度更容易。同时，它还会迫使程序员为创建这些对象而制定出过于特定化的解决方案，而忽略其他解决方案——例如重用存储在某处的对象等。实际上，我们可以降低复杂度：

从整个模式中删除“Factory”名称。
删除关键字new和<< creates >>操作。

现在，这个模式只有一个返回ProductA或ProductB实例的对象。它可以实例化类，从数据结构中获取预先构建的对象或从不明区域获得对象，这都无所谓，因为我们所关心的是开始的时候我们没有对象，结束的时候却有一个对象。现在，上述列表变成了：

两个操作：

第一个操作：通过接口ProductA获取对象
第二个操作：通过接口ProductB获取对象

你可以将操作放在一个类、一个结构或指针中，放在哪儿都行（甚至是你家客厅）。使用的时候，可以通过任何参数调用其中一个操作，然后它们会为你提供相应的对象。设置的时候，可以将第一个操作设置为生成ProductA的操作，将第二个操作设置为生成ProductB的操作。没有类图，没有序列图，没有额外的类，没有额外的词语。没有歧义，因为你可以执行的操作无非是调用它，将它作为参数传递，返回它并存储它。因为函数和操作只不过是带参数的值。那么如何通过ProductA接口获得对象呢？ProductA能返回怎样的对象呢？只能是第一个操作，因此你只能使用它。

构造良好的抽象能很好地组合

上述我们通过修改AbstractFactory描述了一个构造良好的抽象。构造良好的抽象能很好地组合，这句话包含两部分：

构造良好的抽象

AbstractFactory模式是一个糟糕的抽象，因为它暴露了我们不关心的细枝末节，例如它是抽象，它必须创建对象，以及它使用new关键字。作为用户，我们并不关心这些细节，但所有这些都出现在我眼前时，就必须处理。

相反，我只想要“一个操作，一个能够让我通过ProductA接口获取对象的操作。”我调用这个操作，而它则返回一个ProductA。我不知道，也不在乎它获取对象的过程。

很好地组合

AbstractFactory模式是一个糟糕的抽象（再说一次），因为它没有进行组合。它有两个对象：一个创建ProductA，另一个创建ProductB。为什么我必须把它们放在同一个Factory里？为什么我不能分开这两个操作？如果有人想合并在一起，则可以将它们放在同一个元组中。即便它们在同一个类中，也没有良好地组合。我该如何合并它们？如果我在某处需要ProductA的其他操作该怎么办？该操作是否需要了解AbstractFactory的错误链？

AbstractFactory myFactory = new Factory1();
ProductA myProduct = myFactory.createProductA();
AbstractFactory somethingDifferent = new SomethingDifferentFactory();
SomethingDifferent result = somethingDifferent.fabricate(myProduct);
return result

相反，如果我有“一个能够让我通过ProductA接口获取对象的操作”，以及另一个通过ProductA构造不同东西的操作，那么我就可以先调用第一个操作来获取ProductA，然后再调用第二个操作。类型定义如下：

operation : () -> ProductA
otherOperation: ProductA -> SomethingDifferent

因此，只需调用otherOperation(operation())即可。

检测良好的组合能力

不幸的是，我们很难检测良好组合能力的语义，因为我们这些开发人员习惯于那些没有组合能力的东西，我们不知道能够很好地组合的东西“长什么样子”。良好的组合能力很容易感觉到。感觉就像乐高积木，每一块都可以很轻松地与其他块拼凑起来，制作一个大型作品的过程也很简单：

我有一个三角形的凸起，看看哪里有三角形的孔。

如果你有良好的组合能力，就无需再使用适配器（或者你甚至无需命名适配器，因为它们都很简单）。如果你有良好的构造，则只需将各个部分连接起来就可以构成一个整体，而不必担心各个部分之间会以意想不到的方式相互作用。

总和即为各部分的求和，不多不少。

总结

在本文中，我们看到AbstractFactory违反了七大规则，它将一个简单的概念“获取ProductA”变成了：

一个Abstract的Factory，实现了createProductA 方法，该方法利用new来<<construct>>一个包含ProductA << interface >>的ProductA1。

这句话中包含了10个单词和概念，超出了大脑的处理极限。更糟糕的是，它过于刻板，因为它只允许创建对象，却不允许重用对象。

这就是编程工作困难重重的原因之一：因为我们自己给自己制造了困难。

原文：http://www.javiercasas.com/articles/rule-of-seven

【End】

国家承认的Python工程师有哪些能力要求？

https://edu.csdn.net/topic/python115?utm_source=csdn_bw

5G进入元年，物联网发展愈加火爆！

你是否身怀绝技、却无人知晓；别让你的IoT项目再默默无闻了！

继第一届AI优秀案例评选活动之后，2019年案例评选活动再度升级，CSDN将评选出TOP 30优秀IoT案例，赶快扫码参与评选吧！重磅福利，等你来领！

热文 推荐

☞雷军：小米推动山寨机灭亡；苹果回应禁止第三方换电池；Javascript 引擎 V8 7.7 发布 | 极客头条

从ACM班、百度到亚马逊，深度学习大牛李沐的开挂人生

Chrome 为何会成功？

《乐队的夏天》很酷？程序员式的摇滚才燃爆了！

Kubernetes要成为一个企业友好平台，到底还缺啥？

糟了，上网记录被 Python 扒下来了！

AI芯片技术“分叉”百害无利，国产芯片大有可为

☞比特币勒索出新招，佳能单反被黑客攻破，白帽却利用一个漏洞赎回了照片，这波操作简直了……

行！这下 CSDN 玩大了！粉丝：太良心

点击阅读原文，输入关键词，即可搜索您想要的 CSDN 文章。

你点的每个“在看”，我都认真当成了喜欢

如何避免程序员的大脑超载？相关推荐

这道愚人节逻辑题足矣验证你是否拥有程序员的大脑！
请听题: 四月一日愚人节当天,因公司所运营的核心产品出现了极其严重的弱智BUG,并给公司造成了无法弥补的巨大损失,故临时招开紧急会议! 五分钟后,与会人员悉数到场. 每个人的表情虽五味杂陈,但均默不作 ...
中学再不学编程就晚了？MIT、JHU研究：程序员大脑思考代码的机制不对劲
视学算法报道转载自:机器之心编辑:泽南.小舟 MIT.约翰霍普金斯大学的研究人员发现,思考编程并不像组织语言,但也不靠纯粹的逻辑.这是因为我们通常是在成年之后才开始学代码? 很多时候,我们认为优秀 ...
《Java程序员，上班那点事儿》目录
第一卷生存法则第1章知己知彼,百战不殆 1.1 问题1:这个职业赚钱吗?赚多少钱 1.1.1 修炼第一层境界:剑指四方,试问天下谁与争锋 1.1.2 修炼第二层境界:世界 ...
优秀程序员写代码一定会用的 11 条经验
这是一篇值得收藏起来,隔三差五就拿来重读的文章!因为作者向你保证,他"遇到的所有糟糕的代码,都是因为没采纳这些实践经验.而任何一段优秀的代码,都采纳了至少部分实践经验." 还等什么 ...
优秀程序员写代码一定会用的 11 条经验！
这是一篇值得收藏起来,隔三差五就拿来重读的文章!因为作者向你保证,他"遇到的所有糟糕的代码,都是因为没采纳这些实践经验.而任何一段优秀的代码,都采纳了至少部分实践经验." 还等什么 ...
程序员debug三大定律
声明首先声明,本文其实是写给管理程序员的人看的.如果你是程序员,看了以后可能会对你的职业生涯产生负面影响,慎入! 至于其他闲杂人等,可以了解一下码农的工作状态,看个乐子. 什么是debug? 程序员 ...
网上收集的一些程序员笑话
1.老婆给当程序员的老公打电话:下班顺路买十个包子,如果看到卖西瓜的,买一个.当晚老公手捧一个包子进了家门-老婆怒道:你怎么只买一个包子?!老公甚恐,喃喃道:因为我真看到卖西瓜的了." 2. ...
程序员的种种崩溃瞬间
如果有想学习java的程序员,可来我们的java学习扣qun:723197800,免费送java的视频教程噢!我每晚上8点还会在群内直播讲解Java知识,欢迎大家前来学习哦程序员其实很容易崩溃的,只 ...
给游戏开发者和程序员的10个建议：如何平衡工作与生活
工作与生活的平衡是互联网上最备受争议的话题.我们在网上可以看到很多围绕这个话题的文章,它们给我们提出了许多建议,帮助我们提高生活质量,也建议我们哪些东西是应该放弃的.以下的10个给游戏开发者和程序员的 ...

如何避免程序员的大脑超载？

如何避免程序员的大脑超载？相关推荐

最新文章

热门文章