思考与实践的节奏

一般来说,当我们学习某一个领域里面的知识的时候,我们更多做的事情是跟着“某个人”(比如某书的作者)来学习这个领域里面众多的概念和这些概念之间的关系,清楚了概念和关系之后,再进行练习和实践。 即使学习的再好,如果不练习不实践,这些知识也是没有用处的。

那么,上面的学习方式有没有什么问题呢? 答案是肯定的,问题就在于我们探究领域里面概念之间关系的方式错误了,我们不应该只按照作者限定的思路去接触关系,而是应该从wishfull thinking的角度提出问题(或者说是一些问题的例子),通过解决这些一个一个具体“用例” 将这些关系驱动出来(理想的情况下这些用例的组合可以解决更大的问题),也就是应该lean-by-doing,这样做从另一个角度来说相当于给予这些关系另一个维度——“时间维度”。

解释一下wishfull thinking,这是一种假设和理想化的思考方法,是我从sicp这本书里面借用过来的词儿(先思考使用什么接口,再思考接口之间的协作方式,而暂时不思考接口背后的具体实现)。在解决某一个固定问题,或者学习某一个领域知识的时候,一个一个的具体用例就是使用wishfull thinking的方法思考出来的(不断的假设和验证流程),wishfullthinking 可以理解为对于实践的指引,同时,在进行wishfull thinking时候需要注意一个一个用例的大小(太大很难实践,太小可能用例无法粘合起来)以及这些用例组合起来是否能够达到预期的目标,这就是经常说的思维构造力(出色的侦探小说,一定是环环相扣,构造力好的小说)。

  事实上这样的过程就像测试驱动开发,开发完成之后的代码看起来是一个相互关联的一起作用的整体,就好像一起出现的一样,事实上他们是为了满足一个一个的需求驱动出来的(是有时间顺序的,他们的联系并不是后期很多人使用结构化的方式总结出来的样子的,我们更应该关注的是解决核心问题的联系)。同样这里面的核心技术在于使用什么样的用例才能将结果驱动出来,还有就是每一次驱动之后都需要重构(在思维层面来说就是需要抽象,需要从已经形成的阶段性解决方案出发进行简化)。

所以说,有思维体力的人,可以长时间的思考问题,他们做的事情就是限定一个大的问题,从而不断的wishfull thinking提出问题,解决问题,最终大圈套小圈地把问题搞定,不会wishfull thinking 的人很难长时间思考,因为他们由于没有高层次的解决问题的脉络,而很容易陷入一个细节的难题而无法自拔,很容易陷入”走的太远而不知道为什么出发的“境地。

但是在真正的实践中,还要在很多情况下遵循下面两个关键点:

一、向外行一样思考、向专家一样实践(金出武雄)

因为在解决很多问题的时候,提出问题是一个重要的环节,大师曾说定义了问题,就相当于解决了问题的60%;但是如果我们“向专家一样思考问题”,我们一定会在我们的已有思维能力的基础之上思考问题(问题提出的背后隐藏着潜意识的解决方面),这样思考问题通常无法跳出已有思维模式是无法真正解决难题的。我们只有向外行一样思考后提出问题(创造性的、简单地思提出问题,提出需求,而不思考方案),这些问题被深入思考解决之后才能真正突破重围(其实没有什么问题是解决不了的,只是没有深入的思考,过早的放弃可以解决的问题主要的原因就是思维体力差和一贯性的浅思考者)

二、缠线圈的方式提高解决问题的能力

还有就是一些问题提出之后,从问题出发确实很难思考清楚,这时就需要提出一些简单的用例,自己构造这个领域的细节,不断的提问和添加条件,进行训练,觉得自己成为这个领域的高手之后再回头看看之前提出的问题。这种遇到强敌深山练功的方式,有一个特点就是要循序渐进,所以也可以比喻成产线圈一样提升能力的方式。

综上,当你实践的越多,越会发现在宏观调度上的思考不总是逻辑的,要创造性的思考,要简单地理想化地思考,当深入细节之后再向专家一样实践,总结下来的关键字就是:

抽象(简单)、想象力、用例、逻辑、实践验证、快速反馈。

时间: 2024-10-03 17:22:02

思考与实践的节奏的相关文章

中国联通SDN/NFV的思考与实践

编者按:2015中国SDN/NFV大会在北京召开,本次大会围绕SDN/NFV展开讨论,来自运营商.服务提供商等业界巨头纷纷参与此次大会.中国联通技术部技术战略处经理裴小燕发表了题为<中国联通SDN/NFV的思考与实践>的演讲. 大家中午好!我简单的介绍,汇报一下中国联通对SDN/NFV的思考.我是制订公司发展战略的工作,因此借用网络上流行的话"世界很大,我们要去看看".我汇报的技术层面东西比较少,主要分享一下,我们去世界看看的一些结果. 关于运营商对于NFV的一些需求,我不

腾讯IVWEB前端工程化工具feflow思考与实践

本篇文章主要介绍腾讯IVWEB团队从0到1在工程化的思考和实践.feflow的全称是Front-end flow(前端工作流),致力于提升研发效率和规范的工程化解决方案.愿景是通过feflow,可以使项目创建.开发.构建.规范检查到最终项目上线的整个过程更加自动化和标准化. 要解决的问题 项目的目录结构按约定生成 团队有一套开发规范进行约束 支持多种类型的构建,包括Fis构建和webpack构建 团队内部的代码贡献统计.离线包内置App等 为了解决上述问题,我们于17年2月底开始投入工程化fef

前后端分离的思考与实践(六)

原文出处: 淘宝UED - 筱谷 Nginx + Node.js + Java 的软件栈部署实践 起 关于前后端分享的思考,我们已经有五篇文章阐述思路与设计.本文介绍淘宝网收藏夹将 Node.js 引入传统技术栈的具体实践. 淘宝网线上应用的传统软件栈结构为 Nginx + Velocity + Java,即: 在这个体系中,Nginx 将请求转发给 Java 应用,后者处理完事务,再将数据用 Velocity 模板渲染成最终的页面. 引入 Node.js 之后,我们势必要面临以下几个问题: 技

关于后台部分业务重构的思考及实践

关于后台部分业务重构的思考及实践 作者: ljmatlight 时间: 2017-09-25 积极主动,想事谋事,敢作敢为,能做能为. 当职以来,随着对公司业务和项目的不断深入,不断梳理业务和公司技术栈. 保证在完成分配开发任务情况下,积极思考优化方案并付诸实践. 一.想法由来 由于当前我司主要针对各大银行信用卡平台展开相关业务, 故不难看出,各银行信用卡平台虽然有各自的特性, 但其业务相似程度仍然很高,除必要的重复性工作外,仍有很大提升优化空间. 例如: 各个银行平台都需要对账工作.都要安排人

关于数据库‘状态’字段设计的思考与实践

最近在做订单及支付相关的系统,在订单表的设计阶段,团队成员就‘订单状态’数据库字段设计有了一些分歧,网上也有不少关于这方面的思考和探讨,结合这些资料和项目的实际情况,拟对一些共性问题进行更深一层的思考,笔耕在此,和大家一起探讨. 问题综述 这里的分歧点即有团队内部的分歧点,也有网络上常见的一些分歧点,先将存在的分歧点抛出来: 1.订单表的‘订单状态’字段对应的字典值应当包含哪些状态值?对于‘已评论’.‘已退货’.’已退款’这类状态是放到‘订单状态’中?还是独立一个字段标识? 2.订单表的‘订单状

从单体架构迁移到微服务,8个关键的思考、实践和经验

转载本文需注明出处:EAII企业架构创新研究院(微信号:eaworld),违者必究.如需加入微信群参与微课堂.架构设计与讨论直播请直接回复此公众号:“加群 姓名 公司 职位 微信号”.   随着微服务架构的持续火热,网络上针对微服务和单体架构的讨论也是越来越多.去年的时候,社区更多的关注点是在二者的区别以及优缺点辨析上,而今年,越来越多的人开始关注如何从单体架构迁移到微服务上.毋庸置疑,微服务的理念正在席卷整个开发者社区,像Netflix.Uber这样的公司都是非常成功的应用案例. 但需要注意的

平衡成本与业务风险 “去IOE”话题的思考与实践

很多人谈到"去IOE"话题,会理所当然的认为,将IBM.Oracle.EMC的全部产品从信息架构中移去就是去IOE,其实不然.IOE其实是特指IBM.Oracle.EMC的专有系统:"I"指的是IBM大/小型机;"O"指Oracle专有数据库;"E"指EMC存储设备.由于推出较早,行业应用丰富,性能指标优秀,所以"IOE"架构成为针对各行各业的企业关键应用而设计,基于向上扩展(Scale-up)技术高端设备

服务器端文件分片合并的思考和实践

笔者在项目中处理大文件上传的需求,仿照七牛云存储的接口设计.然而,在服务器端文件合并时遇到了很大的问题:合并太慢.本文记录了当时的思路和解决的方案 大文件的需求 文件上传是个很常见的需求.尽管HTTP是基于TCP上层的协议,但是HTTP协议本身并不适合处理超大的请求体,文件上传有很大的稳定性问题,如果中途断开了,将前功尽弃.为了改善用户体验或者缓解服务器压力,通常会考虑将文件分成小片,将小片一个个上传,如果中途断开了也能从某个失败的小片开始继续上传. 在前端的处理上,对于Web页面,可以采用pl

前后端分离的思考与实践(一)

原文出处: 淘宝UED - 常胤 也谈基于NodeJS的全栈式开发(基于NodeJS的前后端分离) 前言 为了解决传统Web开发模式带来的各种问题,我们进行了许多尝试,但由于前/后端的物理鸿沟,尝试的方案都大同小异.痛定思痛,今天我们重新思考了"前后端"的定义,引入前端同学都熟悉的NodeJS,试图探索一条全新的前后端分离模式. 随着不同终端(Pad/Mobile/PC)的兴起,对开发人员的要求越来越高,纯浏览器端的响应式已经不能满足用户体验的高要求,我们往往需要针对不同的终端开发定制