责任链模式实践

1、前言

       当今软件开发中,设计模式是一种重要的方法论,它们帮助开发人员解决了各种常见的问题,并提高了代码的可维护性和可扩展性。本文将重点介绍责任链模式(Chain of Responsibility Pattern),并使用Java语言来解释它的概念、用途以及如何实现。

2、责任链模式简介

       责任链模式是一种行为型设计模式,它允许你将请求沿着处理链传递,直到有一个对象处理它为止。这种模式非常适合处理请求的分发和处理,特别是当您不知道哪个对象能够处理请求时。

       在责任链模式中,通常有多个处理对象(处理器),每个处理对象都有一个处理请求的方法。当一个请求进入责任链时,它从链的起始点开始传递,每个处理对象检查是否能够处理该请求。如果可以处理,则该请求被处理,否则它会被传递给链中的下一个处理对象,直到找到一个合适的处理器。

3、责任链模式的优点

责任链模式有以下几个优点:

  1. 解耦性: 责任链模式将请求发送者和接收者解耦,发送者无需知道请求最终由哪个接收者处理。
  2. 可扩展性: 可以轻松地添加新的处理对象或修改处理顺序,而不会影响其他部分的代码。
  3. 灵活性: 可以动态配置责任链,根据需要添加、删除或修改处理对象。
  4. 单一职责原则: 每个处理对象只需关心自己是否能够处理请求,符合单一职责原则。

4、责任链模式的实现

让我们使用Java语言来实现一个简单的责任链模式示例。假设我们有一个报销审批系统,根据报销金额不同,有三个处理对象:经理、财务部门和CEO。让我们一步一步实现这个示例。

首先,我们创建一个请求类表示报销请求:

public class ReimbursementRequest {
    private double amount;

    public ReimbursementRequest(double amount) {
        this.amount = amount;
    }

    public double getAmount() {
        return amount;
    }
}

接下来,我们创建一个处理接口,表示处理请求的方法:

public interface ReimbursementHandler {
    void handleRequest(ReimbursementRequest request);
    void setNextHandler(ReimbursementHandler nextHandler);
}

然后,我们创建三个具体的处理对象:经理、财务部门和CEO,它们实现了ReimbursementHandler接口:

public class Manager implements ReimbursementHandler {
    private ReimbursementHandler nextHandler;

    @Override
    public void handleRequest(ReimbursementRequest request) {
        if (request.getAmount() <= 1000) {
            System.out.println("经理审批通过,报销金额:" + request.getAmount());
        } else {
            if (nextHandler != null) {
                nextHandler.handleRequest(request);
            } else {
                System.out.println("无法处理该报销申请");
            }
        }
    }

    @Override
    public void setNextHandler(ReimbursementHandler nextHandler) {
        this.nextHandler = nextHandler;
    }
}

public class FinanceDepartment implements ReimbursementHandler {
    private ReimbursementHandler nextHandler;

    @Override
    public void handleRequest(ReimbursementRequest request) {
        if (request.getAmount() <= 5000) {
            System.out.println("财务部门审批通过,报销金额:" + request.getAmount());
        } else {
            if (nextHandler != null) {
                nextHandler.handleRequest(request);
            } else {
                System.out.println("无法处理该报销申请");
            }
        }
    }

    @Override
    public void setNextHandler(ReimbursementHandler nextHandler) {
        this.nextHandler = nextHandler;
    }
}

public class CEO implements ReimbursementHandler {
    @Override
    public void handleRequest(ReimbursementRequest request) {
        System.out.println("CEO审批通过,报销金额:" + request.getAmount());
    }

    @Override
    public void setNextHandler(ReimbursementHandler nextHandler) {
        // CEO是责任链中的最后一个处理对象,不需要设置下一个处理对象
    }
}

最后,我们可以创建一个责任链并测试它:

public class Main {
    public static void main(String[] args) {
        ReimbursementHandler manager = new Manager();
        ReimbursementHandler finance = new FinanceDepartment();
        ReimbursementHandler ceo = new CEO();

        // 构建责任链
        manager.setNextHandler(finance);
        finance.setNextHandler(ceo);

        // 创建报销请求
        ReimbursementRequest request1 = new ReimbursementRequest(800);
        ReimbursementRequest request2 = new ReimbursementRequest(3500);
        ReimbursementRequest request3 = new ReimbursementRequest(10000);

        // 发送请求
        manager.handleRequest(request1);
        manager.handleRequest(request2);
        manager.handleRequest(request3);
    }
}

运行以上代码,你会看到不同金额的报销请求会被不同的处理对象处理。

5、责任链模式在检查系统中的运用

检查系统具有以下检查-申诉-整改-奖惩链路,在该链路中我们可以使用责任链模式,使代码变得更容易维护和扩展。

首先我们创建一个包含各个链路中需要用到的请求类对象。

/**
 * @author: guojiangtao
 * @description:
 * @param: 
 **/
@Data
@Builder
@NoArgsConstructor
@AllArgsConstructor
public class CheckRewardPunishmentRequest implements Serializable {

    private static final long serialVersionUID = 8676996408255323152L;

    /**
     * 检查结果ID
     **/
    private Long checkListResultId;

    /**
     * 检查基本事实
     **/
    CheckBaseBO checkBaseBO;
    /**
     * 检查整改事实
     **/
    CheckRectifyBO checkRectifyBO;
    /**
     * 检查申诉事实
     **/
    CheckAppealBO checkAppealBO;

}

我们创建一个处理接口,表示处理请求的方法。

/**
 * @author: guojiangtao
 * @description: 处理请求
 * @param:
 **/
public interface CheckRewardPunishmentPhaseActionInterface {

    CheckRewardPunishmentPhaseResult proceed(PhaseChain chain);

    /**
     * @author: guojiangtao
     * @description: 获取request以及转发请求
     * @param: 
     **/
    interface PhaseChain {
        // 获取当前Request
        CheckRewardPunishmentRequest request();
        // 转发Request
        CheckRewardPunishmentPhaseResult dispatch(CheckRewardPunishmentRequest request);
    }

}

创建一个客户端类来维护处理的实现类。

/**
 * @author guojiangtao
 */
@Data
public class PhaseChainClient {

    public static final List<CheckRewardPunishmentPhaseActionInterface> phaseActionInterfaceList = Lists.newArrayList();
    private static void addPhaseActionInterface(CheckRewardPunishmentPhaseActionInterface phaseActionInterface) {
        phaseActionInterfaceList.add(phaseActionInterface);
    }

    public static PhaseChainClient getChainClient(CheckRewardPunishmentPhaseActionInterface ... interfaces) {

        List<CheckRewardPunishmentPhaseActionInterface> interfaceList = Lists.newArrayList(interfaces);

        if (CollectionUtil.isNullOrEmpty(interfaceList)) {
            throw new BizException(BizErrorCodeEnum.ILLEGAL_OPERATION, "getChainClient exception");
        }

        interfaceList.forEach(PhaseChainClient::addPhaseActionInterface);

        return new PhaseChainClient();
    }

    public CheckRewardPunishmentPhaseResult execute (CheckRewardPunishmentRequest request) {

        RealPhaseChain realChain = new RealPhaseChain(request, phaseActionInterfaceList, 0);

        return realChain.dispatch(request);
    }

}

检查提交实现类。

/**
 * @author: guojiangtao
 * @description: 检查提交
 * @param:
 **/
@Service
@Slf4j
public class CheckSubmit implements CheckRewardPunishmentPhaseActionInterface {

    @Autowired
    private CheckAppeal checkAppeal;
    @Autowired
    private CheckRpProducer checkRpProducer;

    @Override
    public CheckRewardPunishmentPhaseResult proceed(PhaseChain chain) {

        CheckRewardPunishmentRequest request = chain.request();

        // 参数校验
        if (null == request) {
            log.warn("CheckSubmit proceed with null request");
            return null;
        }

        CheckBaseBO checkBaseBO = request.getCheckBaseBO();

        if (null == checkBaseBO) {
            log.warn("CheckSubmit proceed with null checkBaseBO");
            return null;
        }

        // 检查单配置
        if (AppealTypeEnum.OPEN_APPEAL.getCode().equals(checkBaseBO.getAppealType())) {
            // 构建检查申诉事实实例
            CheckAppealBO appealBO = new CheckAppealBO(checkBaseBO.getCheckItemId(), checkBaseBO.getCheckItemResultId(), 1);
            request.setCheckAppealBO(appealBO);
            return PhaseChainClient.getChainClient(checkAppeal).execute(request);
        }

        checkRpProducer.sendMessage(request);

        return new CheckRewardPunishmentPhaseResult(Boolean.TRUE, "");
    }

}

检查申诉实现类:

/**
 * @author: guojiangtao
 * @description: 检查申诉
 * @param:
 **/
@Service
@Slf4j
public class CheckAppeal implements CheckRewardPunishmentPhaseActionInterface {

    @Autowired
    private CheckRpProducer checkRpProducer;
    @Autowired
    private CheckResultRectifyListRepository checkResultRectifyListRepository;
    @Autowired
    private CheckRectifyTemplateItemRelationRepository rectifyTemplateItemRelationRepository;
    @Autowired
    private CheckRectify checkRectify;

    @Override
    public CheckRewardPunishmentPhaseResult proceed (PhaseChain chain) {

        CheckRewardPunishmentRequest request = chain.request();

        // 参数校验
        if (null == request) {
            return new CheckRewardPunishmentPhaseResult(Boolean.FALSE, "");
        }

        CheckBaseBO checkBaseBO = request.getCheckBaseBO();
        CheckAppealBO appealBO = request.getCheckAppealBO();

        if (null == checkBaseBO || null == appealBO) {
            return new CheckRewardPunishmentPhaseResult(Boolean.FALSE, "");
        }

        // 根据检查项ID查询 检查项与整改任务模板 1:1
        CheckRectifyTemplateItemRelationDAO templateItemRelationDAO = rectifyTemplateItemRelationRepository.queryByItemId(checkBaseBO.getCheckItemId());

        if (null != templateItemRelationDAO) {
            // 整改单模板ID
            Long rectifyTemplateId = templateItemRelationDAO.getRectifyTemplateId();
            // 整改单
            CheckResultRectifyListDAO rectifyListDAO = checkResultRectifyListRepository.getByCheckResultIdAndTemplateId(checkBaseBO.getCheckListResultId(), rectifyTemplateId);
            if (null != rectifyListDAO && Objects.equals(RectifyResultListStatusEnum.FINISH.getCode(), rectifyListDAO.getStatus())) {
                // 构建检查整改事实实例
                CheckRectifyBO rectifyBO = new CheckRectifyBO(checkBaseBO.getCheckItemId(), rectifyListDAO.getStatus());
                request.setCheckRectifyBO(rectifyBO);
                return PhaseChainClient.getChainClient(checkRectify).execute(request);
            }
        }

        checkRpProducer.sendMessage(request);

        return new CheckRewardPunishmentPhaseResult(Boolean.TRUE, "");
    }

}

检查整改实现类:

@Service
@Slf4j
public class CheckRectify implements CheckRewardPunishmentPhaseActionInterface {
    @Autowired
    private CheckRpProducer checkRpProducer;

    @Override
    public CheckRewardPunishmentPhaseResult proceed(PhaseChain chain) {

        CheckRewardPunishmentRequest request = chain.request();

        if (null == request) {
            return null;
        }

        CheckRectifyBO rectifyBO = request.getCheckRectifyBO();

        // 无整改事实 不处理
        if (null == rectifyBO) {
            return null;
        }

        checkRpProducer.sendMessage(request);

        return new CheckRewardPunishmentPhaseResult(Boolean.TRUE, "");
    }

6、责任链模式的适用场景

责任链模式在以下情况下特别有用:

  1. 当您希望将请求的发送者和接收者解耦时,可以使用责任链模式。发送者无需知道最终哪个对象会处理请求。
  2. 当您有多个对象可以处理请求,但您不确定哪个对象应该处理时,可以使用责任链模式。这种情况下,您可以将请求传递给责任链,直到有一个对象能够处理它。
  3. 当您希望动态配置处理对象的顺序或添加新的处理对象时,可以使用责任链模式。这使得系统更加灵活和可扩展。
  4. 在需要应用单一职责原则的情况下,责任链模式可以帮助将处理逻辑分散到不同的对象中,每个对象只负责一部分功能。

7、总结

责任链模式是一种有用的设计模式,可以帮助您构建灵活的、可扩展的系统。它通过将请求传递给一系列处理对象来解耦请求发送者和接收者,使得代码更容易维护和扩展。通过示例代码和解释,我们希望您现在更好地理解了责任链模式及其在Java中的实现方式。希望这篇分享文档有助于您在实际项目中应用责任链模式以解决类似的问题。

谈谈开发如何做好自测

一、为什么要做好开发自测(why)

   1. 避免把线下bug暴露到线上,争取在开发阶段就全部扫清所有显性和隐藏的问题;
   2. 个人能力和价值的体现,也是逐步提升个人技术水平,积累业务经验的过程;
   3.  减少线下bug能提升整个团队的开发效率,提升整体的交付质量和用户口碑;
   4. 满足公司对开发质量规范的要求,为团队争取更多的荣誉和奖励。

二、开发自测方法论

1. 思想意识上,提升对自测的重视程度
  • 开发阶段不仅是代码开发完成,编译通过,更重要的是自测通过;
  • 自测工作必须覆盖全面的自测场景:正向、逆向、正常、异常、并发性能等等;
  • 自测是开发阶段最重要的一环,如果不重视自测,测试阶段可能会产生大量的Bug、提测被打回、直接影响研发、测试进度;
  • 自测直接决定了产品的质量。
2. 日常开发中保持良好的心情和积极的心态,不带情绪做事
  •  迭代开发中允许有争论、有分歧、有权利发表自己的观点,沟通中要学会调整自己的心态,确保对话氛围安全,避免情绪失控;
  •  有争议情况下的对话氛围尽量控制主观想法、臆断,主动回到客观事实;
  •  学会征询对方的观点,切记独断专行,多站在对方的立场考虑问题,虚心接受和采纳正确的观点和建议;
  • 不赌气,多沟通,以团队的利益和出发点考虑问题,少计较个人得失。
3. 做好前期计划,并合理估计投入时间,给自测预留充足的时间和资源
  • 在规定的时间内尽量放慢开发的速度,做到慎之又慎,切记追求速度,需求上来就干 ;
  • 合理地规划好时间,尽量避免多线程做事,多迭代并行开发;
  • 对于复杂功能要梳理出开发顺序、先做什么后做什么,制定阶段性的开发目标和时间排期表,切记打乱仗。
 4. 做好高效率、直接有效的沟通,及时暴露和反馈问题
  • 对于不明确的需求、场景要主动、提前确认,确认后要告知相关的参与者;
  • 需求问题确认最好当面或语音沟通、尽量做到产品、前后端开发、测试对需求的理解能达成一致;
  • 不隐藏问题,尽早发现并提出问题,力所能及地加以解决。
 5. 评估、衡量自测的质量:以关键结果为导向
  • 做好全流程的自测,用户操作—前端页面—-后台接口—–数据库数据check
  • 核心方法是否都通过了单元测试;
  • 交叉Review已实现的功能,发现更多的Bug,完善到自测场景中。

三、具体如何做(do—执行)

1.需求立项、评审阶段
  •  需求评审前,我们应该先仔细阅读prd及交互文档,先形成自己对产品的思考,通过脑图的方式列出对产品设计的疑问点, 从用户或者从行业角度找出产品设计缺陷点;
  •  需求评审不能流于形式,要把业务问题都理解吃透,确保产品设计的准确性以及合理性;带着自己的疑问点向产品、开发沟通自己对产品的疑惑和质疑点,多提几个为什么?如何实现?数据获取来源?超出预期的数据怎么处理?缓存处理机制如何?数据保存何处?逻辑由前端处理还是后端服务?后端服务逻辑是否跟第三方关联?
  •  评审后要主动、反复确认跟进不明确的需求和待确认的问题,特别是一句话的需求。
2.设计、开发阶段
  •  开发前要做功能设计,特别是核心复杂的功能或流程,首先是确立最优的技术方案或架构设计;
  •  对于不熟悉的新功能要想办法梳理出整体流程,再有针对性地钻研突破难点和瓶颈问题;对于熟悉的业务功能要梳理出这次改动的影响点和之前的遇到过的bug;
  •  详细、完善的功能设计要包含正常场景和异常场景的覆盖;
  • 考虑并发、性能相关问题的出现场景及相对应的技术解决方案;
  • 开发阶段尽量考虑代码的公用性、拓展性及可维护性,多学习优秀的代码结构和设计思想。
3. 联调、自测阶段
  • 一定要在测试环境自测流程, 确保基本的核心流程不出错,不出低级bug;
  • 如时间充裕,组织组内用例评审也是非常必须的。特别是一些经验老道或者业务熟悉的老司机们,可以在用例评审上快速的帮忙指出用例的遗漏点,有助于测试人员打开思路,尽可能多的覆盖用户场景,值得注意的是用例评审上遇到不确定的,应立即记录下来,结束后及时找相关人员确认,避免猜测。开发人员对照达成一致的测试用例完成自测,特别留意异常场景和核心流程的测试;
  • 多人协作开发的功能要注意提前界定好开发边界,确保整个功能的完整性,自测时要相互交叉测试;
  • 和外部系统对接、联调要充分预计到对方系统、接口可能存在的问题,采取适当的补偿、降级和异常处理策略。
其实还有很多的方法和途径来提升开发自测,提升自测的质量是一个不断完善和改进的过程。

清醒思考的策略

好的思维方式能帮助我们应对复杂世界,提升我们拥有美好生活的概率。
以下思维工具的来源:
1.心理学研究。比如:精神心理学、社会心理学、幸福研究、策略法研究、行为经济学、临床心理学等。
2.葛多斯学派,即坚忍克己主义。
3.投资类著作。包含查理芒格、巴菲特

完美是不存在的,我们必须不断修正计划

假如你正乘坐航班从法兰克福飞往纽约,那你觉得这班飞机有多长时间是行驶在航线上的呢?90%?80%?70%?
正确答案是:从没有。如果你坐在靠窗的位置,只要扫视一下机翼边缘,便能观察到副翼的躁动——副翼就是用来不断修正航线的。自动驾驶系统每秒钟都会数千次计算飞机实际航线和预设航线间的偏差,然后将校正的指令传导到副翼。
生活的运转方式同飞机和汽车一样,尽管我们更希望让它变成另一种样子:可规划,可预见,无干扰。如果真能如此,那我们只需要专注于预设,专注于理想的起始状态就好。教育、事业、爱情,如果一开始就能做出完美的规划,之后再如预期般完成目标,那该多好。然而正如你所知,生活并非如此。生活这架航班总要不断地经历气流,我们要同所有可能出现的侧风和恶劣天气做斗争。尽管如此,我们表现得却如同一个天真的、期待着好天气的飞行员一般。我们高估了预设的作用,低估了修正的作用。

起飞的状态并不是那么重要,关键是起飞之后的调整。

德怀特·艾森豪威尔曾经说过:“计划本身一文不值,计划的过程才是一切。”关键并不是制订一个一成不变的计划,而是不间断地持续规划,这个过程是永远不会停止的。最迟等到己方部队遇到敌方部队时,艾森豪威尔就会意识到所有的计划都已经过时了。

为什么我们不愿意进行校准和修正?

因为,我们会将每一次微小的调整视作一个计划错误。我们往往会告诉自己,计划并没有奏效。我们遭受了沉重的打击,觉得自己是失败者。
我们必须把修正带来的“耻辱感”放到一边。与那些花了很多时间构建完美的“预设”,并徒劳地期待自己的计划能够绽放的人相比,能够早早开始调整的人将会占据优势。理想的教育是不存在的,唯一可行的终生目标亦不存在。这世上没有完美无缺的企业战略、理想的选股方案,或唯一正确的职业,这一切都是神话。正确的做法是以一种预设开始,然后不断修正自己的预设。世界越复杂,你的起点越无关紧要。所以,无论是在职场里还是在生活中,请不要把资源都用在制定完美的预设上,相反,你应该当机立断、毫不愧疚地调整那些不顺利的方面。

为什么节省时间的因素往往会成为时间的窃贼

你觉得自己汽车的实际平均速度会是多少呢?

我的路虎发现款汽车提供的数据是每小时50公里。其实,这个估算是错误的。你必须把以下几个因素考虑进去:
(1)为了挣出买车钱而花费的工作时间;
(2)为了支付保险、维修保养、汽油费用和罚单而花费的工作时间;
(3)为了挣出前两点所需要的钱,开车去工作时花费在路上的时间(包含堵车的时间)。天主教神父伊凡·伊里奇就为美国国内的汽车算过这笔账。结果,美国汽车的真实平均速度才刚刚达到每小时6公里,也就是步行的速度。
“反生产力”。这个概念表述了一个事实,即很多科技产物乍一看为我们节省了时间和金钱,然而只要计算一下所有的成本,这种节省的效果便不复存在。无论你最喜欢的出行方式是什么,你都应当注意,“反生产力”是一个应当远远躲开的决策陷阱。
请提前对“反生产力”加以防范,因为它的效果不会立即暴露。我已经让自己习惯了只用一台笔记本电脑(我的家中没有网络),将手机中的App(应用程序)压缩到最少,并尽可能不用更小巧的新手机换掉还能使用的旧款手机。其他一切科技产品,包括电视、收音机、游戏机、智能手表、Alexa(网站排名查询系统)等,我都不会使用。智能家居真是让我一想就害怕。与其用App,我宁可亲自动手开关灯,因为这个App需要安装、联网并不断更新。此外,我的老式电灯开关不可能被黑客侵袭,这又为我减少了一个“反生产力”因素。
科技往往会被打上万能的标签,但经常会给我们的生活品质带来消极影响。快乐生活的一条基本原则是:如果一样东西无法为我们做出真正的贡献,那我们便可以省下它,尤其是针对科技而言。在将手伸向下一个小设备之前,请先打开头脑中的那盏灯。

你只能改变自己,无法改变他人

试着回忆一下,20年前你是什么样子。请不要去想那些外在的方面(例如工作、住处、外貌),而是来回忆一下你的品格、性格、脾气、价值观,以及兴趣爱好等。将当时的你和现在的你对比一下,然后为自己的改变程度打个分吧,从0分(毫无变化)到10分(彻底改变,即仿佛完全变了一个人)。我问过的大多数人都能发觉自己在过去的20年中,在个性、价值观和喜好等方面发生了一定程度的改变。
他们通常会给自己的改变打2至4分。虽然没有像苏黎世机场一样经历彻头彻尾的变化,但我们多少都还是变了一些。
接下来的问题是:你觉得在接下来的20年里,自己会有多大变化?这个问题的答案分值通常都会比上一个要低得多,即在0至1分之间。也就是说,大多数人都不相信自己在未来20年中,在内心的最深处还能经历什么改变,即便有的话,改变的程度也会非常小。

1.你能够为自己个性的改变施加些许影响,但影响的幅度却有限,因为人格变化极大程度上是由基因程序决定的。尽管如此,你还是应该抓住一些改变自己的机会。控制人格发展最有效的方式便是借助自己的偶像。

2.你无法改变他人,甚至连你的爱人和孩子,你都无法改变。只有来源于内心的动力才能促成性格的改变,外界的压力或理性的论证对此都是无效的。

我针对美好生活提出的最重要的原则之一,便是学会避开那些你不得不改变他人的情况。正是这一简单的策略,让我摆脱了很多痛苦、亏损和失望。具体来说,我从不会雇用那些需要改变性格的人,因为我知道我做不到。无论可能获得的利润有多大,我都从不和那些与自己性情相差太大的人做生意。此外,假如我必须要改变某个组织中成员的思维方式,那我是断然不会去领导该组织的。

关闭忧虑

假设上帝设计了一个物种。
如果你将物种的“危险传感器”设置得太过迟钝,那它过不了多久便会坠崖而亡或被天敌吃掉,这会导致该物种很快便从地球上消失。相反,如果“危险传感器”太过敏感,那该物种便会因为巨大的恐惧而不敢挪动一步,最终在繁衍后代之前便已饿死。
内心的不安是我们大脑中一个很普通的程序构件。这个生物学程序是被锁死的,我们几乎不可能将它关掉。而这种忧虑一旦消失,亲爱的读者,无论是你还是我,或者任何人,都将不复存在。数百万年的历史已经证明,持久存在的焦虑是一种完美的生存策略。(人类能生存在世界上正因为有忧虑)。
长期的焦虑会导致慢性压力,这种压力会耗费我们数年的阳寿。
来自古希腊和古罗马的斯多葛学派哲学家,曾建议我们使用以下技巧消除忧虑:

1、明确你能改变什么,不能改变什么;
2、解决能改变的问题,而不要让不能改变的问题困扰自己。

作者的经验

第一,留出固定的时间,专注于你的焦虑。具体来说:找出一个笔记本,并将其命名为“我的忧虑之书”。每天留出十分钟,在本子上记下令你忧虑的一切,无论这种焦虑是合理、是愚蠢,还是模糊不清。一旦这样做了,一天中剩下的时光包含的忧虑就会相对少些,因为大脑已经知道,它的忧虑没有被忽视,而是都被记录在册。
首先设想出最坏的结果,而后再强迫自己跳出这个思维局限。这时你会发现,绝大部分的忧虑都会烟消云散,而剩余的一小部分,则是我们真正要做好准备面对的危险。
第二,购买保险。保险制度是一项伟大的发明,也是最优雅的忧虑杀手之一,其真正的价值并非事后做出的理赔,而是在事前减轻我们的焦虑。
第三,专注于工作,是应对胡思乱想的最佳疗法。令人着迷的、内容充实的工作,胜过沉思冥想,而且比任何其他事情都更能转移我们的注意力。

意见的陷阱,为什么一定要持有观点呢?

人类的大脑是一个蕴藏着各种意见的火山,它会不断喷发出各式各样的观点和想法。无论问题重要与否、是否有解,也无论问题是复杂还是简单,答案都会像五彩纸屑一般从大脑中喷发出来。
我们会因此犯下三类错误。
第一,我们会对自己不感兴趣的话题发表意见。在最近与朋友的一次谈话中,我发现自己又一次情绪激动地阐述了个人立场。那次谈话的主题是兴奋剂丑闻,而我其实对竞技体育毫无兴趣。随便翻开一张报纸,我们头脑中那座意见的火山就会喷发。所以,你应该为自己的火山盖上盖子,我当时也本该这么做。

第二,我们会对无法回答的问题发表意见。下一次股市崩盘会在何时?宇宙之外还有宇宙吗?明年夏天的天气会如何?没人能给出确切的答案,就算专家也没有把握。所以,要提高警惕,别让你的观点脱口而出。

第三,我们还倾向于对复杂的问题(比如本章开头的那些问题)做出草率的回答。这个错误最为严重。美国心理学家乔纳森·海特针对大脑在作答时的状态进行了大量研究,结果表明:我们在作答时,会迅速偏向问题的积极面或消极面,尤其是在问题比较复杂的时候。只有这样,我们才能向理性思维求助,从而为自己的观点提供佐证和支持。
迅速形成的观点会令我们做出错误的决策,其后果可能会很严重。此外,避免无节制地生成观点还有一个原因:“我并非一定要有自己的观点”——这种暗示会让你的内心平静下来,并让你活得更加洒脱,而这些都是构成美好生活的重要元素。
那么我的建议是什么呢?在你的脑海中放一个大桶,我们可以称它为“复杂之桶”。把那些你不感兴趣的、无法回答的,或是太过繁杂的问题都一股脑丢进去。别担心,即便如此,生活每天也会为你留下足够多的话题,即那些你可以表态或不得不表态的话题。
无须对所有的问题持有观点,这简直是极大的自由。没有观点绝不意味着知识匮乏,你完全不必为此而感到羞愧。相反,不持立场是智慧的象征,是闪光点。困扰我们这个时代的并非信息爆炸,而是观点泛滥。
总而言之,发表的草率意见越少,生活就会越美好。我甚至敢说,99%的意见都是多余的。对你而言,无论是在私生活还是在工作中,真正重要的意见只有1%。即使在谈及这一小部分问题时,你也不能死抓住“意见的火山”喷发出的第一个观点不放。

如何避开专注力陷阱,将资源投入到合理的地方?

专注力、时间和金钱,这三者对我们而言是最重要的资源。我们对后两种更加熟悉。时间和金钱甚至已经拥有了属于自己的学科,在学科内,它们被称作“工作”和“资本”。然而,尽管专注力在这三种资源中价值最高,对我们的成功和幸福而言也最为重要,但我们对其却了解甚少。遗憾的是,一旦涉及专注力,我们总会不可避免地犯错误。要想避免这种错误,下面几条建议尤为重要。

第一,不要将新事物和重要的事物混为一谈。
无论是产品、观点还是新闻,每一个新事物都想赢得我们的关注。世间越是喧嚣,它们就会叫得越响,只为让人们都能听到它们的声音。然而,你不应该把这种声音太当回事儿。绝大多数被誉为具有突破性的成果,其实都平淡无奇。我们很容易将那些聒噪的“新闻”当成真相,然而事实却并非如此。

第二,请避开免费的信息或技术,因为这些都是由广告资助的专注力陷阱。既然如此,你为什么要故意让自己掉进陷阱呢?

第三,与多媒体有关的一切,你都应当远远避开。图像、动态图片以及未来的虚拟现实技术会令你的情绪运转陷入超速状态,而这则会对你的决策质量造成严重影响。你最好通过文字的形式来接收信息,并且文档中的超链接要尽可能少。因此,书籍是最理想的信息媒介。

第四,你必须意识到专注力是不可分割的,这一点与时间和金钱不同。你在用手机刷脸书时花费的专注力,本应属于坐在你对面的那个人。

第五,在与信息打交道的过程中,你应当占据主动,而不是处于弱势地位。如果他人将某件事贸然地摆在你的眼前,你就会自动处于一种弱势地位。为什么要由一个广告商、记者,或脸书上的好友来决定你的专注点呢?
在摄入信息时,要像对待食物和药物一样挑剔、严格、谨慎。