被动状态下的反转控制

你要主动管理的不是你的时间,而是管理你的同事,管理你的信息。

无论什么事情,如果你发现你持续处于被动的状态下,那么你一定要停下来想一想如何把被动变为主动。我是一个非常不喜欢被动的人,所以,对于任何被动状态,我都要“反转控制”,想尽一切方式变成主动。

我一直说,时间是人生中最宝贵的财富,今天我就来跟你聊聊时间管理方面的话题。

关于时间管理,以前在外企工作时,受过一个专门的培训,我在工作中也总结过自己的方式。时间管理是非常重要的,因为时间过得实在是太快了,快得让你有点受不了,而看似忙碌的我们似乎在这一年中也没有做太多事,尤其是让自己能成长的事情。

有那么一句话是这么说,老天很公平,给了所有人同样多的时间,而有的人能够把时间用好,有的人则没有把时间用好。日积月累,人和人的差距就越来越大了。

之前的(极客时间专栏)文章和你讲过,我在工作强度很大的情况下依然可以找到时间来学习和提升自己,主要是对学习的渴望程度很大。今天想和你谈一下,除了自己对某件事情的热情外,我们该怎么管理好自己的时间。

不过,说实话,在安排时间方面,我成长于一个相对于今天算是比较好的环境,举几个例子。

那个年代,没有智能手机,工作中也不用实时聊天工具。而现在,很多公司都会有若干个聊天群,所有人都可以把信息发给所有的人,而不管这个事是否与你相关。但这些信息无法像邮件那样根据邮件标题聚合,或是通过设置规则自动分类……于是你工作在了一个信息杂乱无章的环境里,而且还在不断地被人打扰,不断地被打断。

那个年代,别人要来找我开会,需要先给我发会议邀请,而且发会议邀请的时候,会找我日历上空闲的时间段来订会议。所以,我可以把很多工作安排在我的日历上,通过邮箱(Outlook 或是 Gmail 都有这样的功能)共享出去。这样,别人都会自觉地不在我有安排的时间段来找我。

而今天,我看到很多公司直接在微信上联系。你要是回复慢了,电话直接打过来,直接叫你去开会。不像我那个年代,老板临时给员工开会也要问一下员工有没有时间,但现在的工作环境连问都不问,直接一句,你来一下。

那个年代,工作被非常有计划地安排。还记得在路透工作的时候,管理者们都说,你工作时如果有 70% 的时间能花在项目开发上,算是很高效了,一般来说,正常值也就是 50% 左右。在亚马逊的时候,每次开会都会把会议要讨论的事打印出来,前 10 分钟大家都在读文档,然后直接讨论,基本上会议都保持在半小时左右。

这可能是外企的好处吧,从上到下都知道时间管理是很重要的事,所以,从管理层到执行层都会想方设法帮助程序员专注地做好开发工作。包括尽可能的不开会,不开长会,需求和设计都是要论证很久才会决定做不做,项目管理会帮你把你处理额外工作的时间也算进去,还会把你在学习上花的时间也计算进去。所以,时间在整个组织上能够被有效地管理和安排着。完全不像今天国内的互联网公司。

所以,我以前管理自己的时间还是比较容易的,然而,现在人的工作环境的确是非常不利于管理。不过,我还是想在这里谈一下如何管理自己的时间,希望对你有帮助。

主动管理

无论什么事情,如果你发现你持续处于被动的状态下,那么你一定要停下来想一想如何把被动变为主动。因为在被动的方式下工作,你是不可能做好工作的,无论什么事。我是一个非常不喜欢被动的人,所以,对于任何被动状态,我都要“反转控制”,想尽一切方式变成主动。

如果你发现你的时间老是被别人打断,那么你就要告诉大家,我什么时间段在做什么事,请大家不要打扰我。我以前在国外看到有个老外就在自己的工位上挂了一个条幅,上面写着“正在努力写代码中,请勿打断……”而我在亚马逊工作时,亚马逊也允许员工想沉浸于工作时不用来公司而是可以在家办公(work from home)。我在阿里的时候有时候也怕被人打断,所以,我会跑到别的楼里找个空的工位工作。

在今天,我觉得你也可以这么干,你可以在群里事先告诉大家,我在几点到几点要无间断地做某个事,这个期间不会看任何微信或是钉钉的群聊,也不会接任何的电话,请大家不要来打扰我。而且还可以学习一下那个我见过的老外,在自己的工位上挂一个不要打扰我的条幅。人肉 Mute 掉所有的打扰。

另外,可以仿照一下以前在 Outlook 里设置工作日程的方式,把你的工作安排预先设置到一个可以共享的日历上,然后分享给大家,让大家了解你的日程。这样,可以让你的同事和老板能事先有个谱儿,而不至于想打断你就打断你。

你甚至可以要求你的同事,重要的事,不要发微信,而是要发邮件,因为微信会有很大概率看不到。这样一来,你就再也不用在一大堆聊天信息中做人肉的大数据挖掘,来找到和你有关的信息。

信息管理真的非常重要,因为将信息做好分类,才方便检索,方便你通过自己的优先级来处理信息。而目前看来,这些只有邮件才能够更好地完成(邮件可以帮你通过邮件标题聚合,你可以设置很多规则来自动化分类邮件,还可以帮你设置自动化回复)。

换句话说,你要主动管理的不是你的时间,而是管理你的同事,管理你的信息。

学会说“不”

上面说了如何主动地管理你的时间。但是,那只是能让你有大块可以专注于工作的时间。然而,这并不能帮助你解决时间不够的问题。比如,现在的很多公司总是把工作安排得非常紧,今天提的需求,恨不得明天就上线,这也就是为什么今天加班的严重程度比我那个时候还更为严重。我认为,现在的很多公司已经不尊重科学和客观规律了,如果让他来管理孕妇,我觉得他们恨不得要把 10 个月的产期缩短成 2 个月。

所以,在这种情况下,你要学会对某些事说“不”,甚至是要学习对老板说不。这其实是一种“向上管理”的能力。

以前在外企接受到的管理方面的培训,有这么一条“Never Say No”——永不说不。的确是这样,说“不”会让人产生距离和不信任。所以,真是这样的,永远不要说不。但是,你明明做不到,还不能说不,这应该怎么办呢?这里面的诀窍如下。

  1. 当你面对做不到的需求时,你不要说这个需求做不到。尤其是,你不要马上说做不到,你要先想一下,这样让别人觉得你是想做的,但是,在认真思考过后,你觉得做不到,并且给出一个你觉得做得到的方案。这里的诀窍是——给出另一个你可以做到的方案,而不是把对方的方案直接回绝掉。
  2. 当你面对过于复杂的需求时,你不要说不。你要反问一下,为什么要这样做?这样做的目的是什么?当了解完目的以后,你可以给出一个自己的方案,或是和对方讨论一个性价比更好的方案。你可以回复说,这个需求好复杂,我们能不能先干这个,再做那个,这样会更经济一些。这里的诀窍是——我不说我不能完全满足你,但我说我可以部分满足你。
  3. 当你面对时间完全不够的需求时,你也不要说不。既然对方把压力给你,你要想办法把这个压力还回去,或是让对方来和你一同分担这个压力。

这个时候,我惯用的方式是给回三个选择:a. 我可以加班加点完成,但是我不保证好的质量,有 bug 你得认,而且事后你要给我 1 个月的时间还债。b. 我可以加班加点,还能保证质量,但我没办法完成这么多需求,能不能减少一些?c. 我可以保质保量地完成所有的需求,但是,能不能多给我 2 周时间?

这里的诀窍是——我不能说不,但是我要有条件地说是。 而且,我要把你给我的压力再反过来还给你,看似我给了需求方选择,实际上,我掌握了主动。

这就是学会说“不”的方法。说白了,你要学会在“积极主动的态度下对于不合理的事讨价还价”。只有学会了说“不”,你才能够控制好你的时间。

加班和开会

国内的公司和国外公司还有一个很不同的事情,就是大量的加班和大量冗长的会议。我见过很多国内的公司,无论大公司还是小的创业公司,都是这个样子的。老实说,我对这个事情也能理解也不能理解。一方面,我能理解为什么会有这么多的加班和会议,主要原因还是管理者在管理上只会使用低级的通过劳动密集型的方式来做事。

另一方面,我不能理解的是,国外公司的加班和会议长度根本不像国内的公司,人家做的也比中国的公司好得多。在国内的公司,老板们看到团队在拼命加班,会很高兴,而在国外的公司,老板看到团队在拼命加班,会觉得这个团队一定是哪里出了问题,老板会比较焦虑。

那么,对于身处于这样环境中的我们,应该怎样管理好自己的时间,或是为自己争取时间呢?老实说,在恶劣的环境中优雅的行动,基本上是一件不可能的事情。我也经历过这样的事,我也没有太好的办法。不过,我还是可以跟你分享几个我的实践方式。

对于加班的事,除了像上面说的那样,学会如何说“不”外,我发现很多时候造成加班的原因是一个恶性循环。也就是说,因为加班干出来了质量不好的软件,于是线上故障很多,要花时间处理,而后面的需求也过来了,发现复杂代码的扩展性很差,越干越慢,越干越烂,越干故障越多。于是,你会被抱怨得越来越多。

这里,我觉得,如果怎么做都要受伤害,那么两害相权取其轻。你要学会比较是项目延期的伤害大,还是线上故障的伤害大,是先苦后甜好,还是积压问题好,聪明的你应该能做出正确的判断。

对于开会,我觉得今天大多数的会都开错了。在会上抛出问题,还是开放性的问题,然后公说公有理,婆说婆有理,任大家自由发挥,各种跑题跑偏,最后还没有任何的答案。开会,不是讨论问题,而是讨论方案,开会不是要有议题,而是要有议案。

所以,作为与会者,如果你发现没有议案,大家海了去说,那么你有两种选择,跳出来帮大家理一理,或者也可以说一下,如果会上讨论不清,要不先线下讨论,有了方案再来评审。也许在一些会上你不敢这么干,但是有些会你是可以这么干的。能影响的这些都能为你争取到很多时间。

好了,总结一下。今天我主要跟你分享了几个能为自己争取更多时间的方法,比如主动管理时间、学会说“不”,以及面对高强度的加班和冗长的会议时,该如何应对和解决等。因为我认为,只有将使用时间的主动权掌握在自己手上,才能更好地利用时间,才能更为高效率的工作。所以,这是时间管理中非常关键的事!

<think> 首先,用户的问题是:“我想了解Scala中控制反转的相关内容 请问Scala中的控制反转”。这是一个关于Scala编程语言中的控制反转(Inversion of Control, IoC)概念的问题。 回顾之前的对话历史: - 系统级指令要求所有回答使用中文,结构化,生成相关问题等。 - 用户提供了几个引用: - 引用[1]:关于Scala构造器的顺序、线性化、访问修饰符(private、protected、public)等。 - 引用[2]:关于Scala流程控制,如if-else、switch、for循环、while循环,以及break的使用示例。 - 引用[3]:关于Scala的函数式编程风格、并行集合处理并发编程的例子。 这些引用覆盖了Scala的基本语法、访问控制、流程控制和并发编程,但没有直接提到“控制反转”(IoC)。控制反转是一种设计模式,常用于依赖注入(DI),在Java中常见于Spring框架。在Scala中,类似的概念也存在。 用户的上一次问题和我的回答没有被提供。在对话历史中,用户说:“上述引用仅供参考,并不是用户真正的需求,请尽可能多的参考用户上一次的问题和你的回答。” 但由于这是第一个可见的用户消息(除了系统指令),所以用户上一次的问题可能就是这个问题本身。我需要基于当前问题回答。 关键点: - 控制反转(IoC)的核心是反转程序的控制流:传统上,代码调用库,但在IoC中,框架调用自定义代码。 - 在Scala中,IoC可以通过多种方式实现: - 依赖注入:使用框架如MacWire、Scaldi或Spring for Scala。 - 函数式编程:利用高阶函数传递依赖。 - 特征(Traits)和蛋糕模式(Cake Pattern):Scala特有的方式来实现组件化和依赖注入。 - 蛋糕模式是Scala中用于依赖注入的流行方式:通过组合特征来构建应用,依赖在编译时注入。 结构化我的回答: 1. **解释控制反转的概念**:用简单语言定义IoC,为什么有用。 2. **在Scala中的实现**: - 依赖注入框架。 - 蛋糕模式。 - 函数式方法。 3. **示例代码**:提供简单的代码示例来说明。 4. **参考引用**:如果相关,引用提供的材料(尽管引用中没有直接提到IoC)。 - 引用[1]提到访问修饰符和线性化,可能与组件化和继承有关。 - 引用[3]提到函数式编程和并发,IoC在并发中可能有应用。 5. **生成相关问题**:在末尾添加相关问题,如系统指令要求。 回答应使用中文: - 所有文本用中文书写。 - 行内数学表达式用$...$,但这里可能不需要很多数学,除非提到算法。 - 独立公式用$$...$$,但IoC概念更多是编程概念,所以可能不需要公式。 - LaTeX语法正确:用于代码块或特定表达式。 系统指令要求“生成相关问题”,所以在回答结尾添加相关问题。 大纲回答: - **引言**:解释控制反转在Scala中的重要性。 - **概念**:简述IoC。 - **实现方式**: - 蛋糕模式:Scala特有。 - 依赖注入框架。 - 其他方法。 - **代码示例**:展示一个简单例子。 - **优点和应用**:为什么在Scala中使用。 - **相关问题**:生成2-3个相关问题。 确保真实可靠:基于Scala知识,IoC在Scala中常通过蛋糕模式或DI框架实现。 参考提供的引用: - 引用[1]:关于访问修饰符——在组件化中,private修饰符有助于隐藏实现细节。 - 引用[2]:流程控制——不直接相关。 - 引用[3]:函数式编程和并发——IoC可以简化并发代码。 在回答中自然地引用,如果适用。 最终回答结构: - 标题:Scala中的控制反转 - 解释 - 代码块(如使用cake pattern) - 相关问题列表 </think> ### Scala中的控制反转 控制反转(Inversion of Control, IoC)是一种软件设计模式,其核心思想是将程序的控制权从应用代码转移到框架或容器中,从而降低组件之间的耦合度,增强代码的可测试性和可维护性。在Scala中,IoC主要通过依赖注入(Dependency Injection, DI)实现,常见于函数式编程风格和特定模式(如蛋糕模式),允许开发者更灵活地管理对象生命周期和依赖关系。下面我将逐步解释Scala中的IoC概念、实现方式及示例。 #### 1. **控制反转的基本概念** - **定义**:IoC反转了传统编程中的控制流:传统模式下,代码主动创建或调用依赖对象;但在IoC中,框架(或容器)负责实例化和注入依赖,代码被动接收这些依赖。这类似于引用[3]提到的“函数式编程风格结合强大的库使得并发编程更容易”,因为它抽象了底层细节,让开发者专注于业务逻辑[^3]。 - **Scala中的优势**: - 减少硬编码依赖,提高代码可测试性(例如,通过Mock对象测试)。 - 支持模块化设计,便于扩展和维护。 - 结合Scala的函数式特性(如高阶函数),IoC可以更简洁地实现。 #### 2. **Scala中实现控制反转的主要方式** Scala提供了多种IoC实现机制,以下是常见方法: **a. 蛋糕模式(Cake Pattern)** 蛋糕模式是Scala特有的IoC解决方案,通过组合特征(Traits)实现依赖注入。每个组件定义为一个trait,依赖通过self-type注解声明,容器在编译时解析依赖。示例代码如下: ```scala // 定义服务组件 trait UserServiceComponent { def userService: UserService trait UserService { def getUser(id: Int): String } } // 实现具体服务和依赖 trait UserServiceComponentImpl extends UserServiceComponent { class UserServiceImpl extends UserService { def getUser(id: Int): String = s"User $id" } } // 组合组件(控制反转点) object App extends UserServiceComponentImpl { val userService = new UserServiceImpl def main(args: Array[String]): Unit = { println(userService.getUser(1)) // 输出: User 1 } } ``` - **关键点**:self-type(如`this: UserServiceComponent =>`)确保了依赖在编译时注入,无需运行时容器。这与引用[1]提到的“类的线性化”相关,Scala的线性化规则确保trait组合顺序正确,避免了Java式的继承冲突[^1]。 **b. 依赖注入框架** Scala社区开发了轻量级DI框架(如MacWire、Scaldi或Guice for Scala),这些框架在运行时自动注入依赖。例如,使用MacWire: ```scala import com.softwaremill.macwire._ class Database class UserService(database: Database) object App extends App { lazy val database = wire[Database] lazy val userService = wire[UserService] // 框架自动注入database依赖 println(userService) // 输出: UserService实例 } ``` - **优点**:简化配置,适合大型项目。注意,Scala的访问修饰符(如`private`)在DI中用于封装细节,引用[1]指出Scala的`private`比Java更严格,有助于防止意外访问[^1]。 **c. 函数式方法(高阶函数)** Scala的函数式特性允许通过高阶函数传递依赖,实现轻量级IoC。例如: ```scala def processData(dependency: Int => String)(input: Int): String = { dependency(input) // 依赖由外部传入 } val myDependency: Int => String = id => s"Data $id" val result = processData(myDependency)(10) // 输出: Data 10 ``` - **应用场景**:结合引用[3]的并行集合示例,IoC可用于并发任务,如传递数据处理函数到并行操作中[^3]。 #### 3. **控制反转的应用优点** - **可测试性**:依赖可Mock,单元测试更简单。 - **模块化**:组件松散耦合,便于替换(如切换数据库实现)。 - **并发友好**:在并发编程中,IoC简化资源管理,避免状态共享问题,类似引用[3]描述的并行集合API[^3]。 #### 4. **注意事项** - **性能**:运行时DI框架(如MacWire)可能引入轻微开销,但蛋糕模式在编译时解析,无额外成本。 - **适用场景**:适合中大型应用;小型项目可能过于复杂。 - **与流程控制的关系**:IoC不同于引用[2]的流程控制(如循环),它关注架构层依赖管理[^2]。
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值