思考方式

Posted suhaohao

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了思考方式相关的知识,希望对你有一定的参考价值。

马上面临毕业 对于整个社会的价值观和眼界都会不断的扩大 这几天看到Deltamote的一篇文章 认为很有道理

思考方式及状态进入:
工作产出不是由写代码的效率决定的,一些不恰当的工作方法很大程度影响着你的产出。
首先要问自己三个问题:
我现在是一个什么水平?
我想达到什么水平?我将怎样达到那个目标?
这三个问题实际上是帮我们确定:现状;目标;实现路径。
如果一个人能够清晰地回答出这三个问题,通常意味着他对要做的事情有着清晰的任认识,这个框架虽然看起来简单但非常有效,它已经成为一件非常称手的思考工具。
在实际工作中,作为产品经理也需要经常问以下几个问题:
为什么要做这个特性,它会给用户带来怎样的价值?
什么样的用户会用到这个特性,他们在什么场景下使用,他们又会怎样使用它?
达成这个目的是否有其它手段?是不是一定要开发一个系统?
这个特性上线之后,怎么衡量它的有效性?
为了把这个框架应用到程序中,需要以下四个原则:
以终为始,确定好真实目标;(我们要到哪里去)
任务分解,找到实施路径;(我们如何到达那里)
沟通反馈,解决与人打交道出现的问题;(我们如何到达那里)
自动化,解决与机器打交道出现的问题,自动化就是将繁琐的工作通过自动化的方式交给机器执行,这是我们程序员本职工作的一部分。。(我们如何到达那里)
我们不是一个人孤独地在工作,而是与其他人在协作,想要做到高效工作,我们就要“抬起头”来,跳出写代码这件事本身。
程序员的优秀程度最能体现在自动化这个环节中,高手首先对自己要到达的目的地的实现细节了如指掌,同时可以用较短的时间转化为自动化工具或者程序。同时超前的视野和丰富的开发经验也不是一个新手能。
如何快速进入工作状态:
首先要运用上面的三个框架:处于什么水平,要到达什么水平,怎么达到那个水平
技术是要肯定了解的,技术解决的是怎么做的问题,但我们第一个应该了解的问题是做什么。
一个软件到底在做什么,能够回答这个问题的就是业务,所以我们排在第一优先级的事情就是业务。
所以不管做什么项目,首先要从大图景入手,只有了解了大图景,各种知识才能各归其位。对于一个程序员来说,业务就是大图景,如果你了解了业务,你自己就可以推演出基本的代码结构。但反过来,如果让你看了代码,从中推演出业务,那几乎是不可能的。事实上,每次了解到一个业务,我都会在脑子中过一下,如果是我做这个业务,我会怎么做。这样一来,我就会先在整体上有一个预判,后面再对应到实际的代码上,就不会那么陌生了。要了解业务,我一般都会请人给我讲一下,这个业务是做什么的,解决什么样的问题,具体的业务流程是什么样子的,等等。在初期的了解中,我并不会试图弄懂所有的细节,因为我的目标只是建立起一个基本的框架,有了这个初步的了解,后续再有问题,我就知道该从哪里问起了。
理论上,了解业务是每个程序员都该做的事,但事实上,这也常常是出问题的地方。在请别人给我讲解业务的过程中,我发现,很多人是分不清业务和技术的,经常把二者混在一起讲。如果你跟着他的思路走,很容易就会陷入到对细节的讨论中。所以,了解业务时,一定要打起精神,告诉自己,这个阶段,我要了解的只是业务,千万别给我讲技术。
技术
了解完业务,就该到技术了。这是程序员最喜欢的话题。但即便是了解技术,也要有个顺序,所以,我们先从宏观内容开始。第一个问题就是这个系统的技术栈:Java、javascript 还是 .NET,这样,我就可以对用到的工具和框架有个大致的预期。
接下来是系统的业务架构,这个系统包含了哪些模块,与哪些外部系统有交互等等。最好能够有一张或几张
图将架构展现出来。现实情况是,不少项目并没有现成的图,那就大家一起讨论,在白板上一起画一张出来,之后再来慢慢整理。
有了一个初步的体系,接下来,就可以稍微深入一些。
我会选择从外向内的顺序了解起。首先是外部,这里的外部包括两个部分:
这个系统对外提供哪些接口,这对应着系统提供的能力;
这个系统需要集成哪些外部系统,对应着它需要哪些支持。
一旦涉及到与外部打交道,就涉及到外部接口是什么样子的,比如,是用 REST 接口还是 RPC(RemoteProcedure Call,远程方法调用) 调用,抑或是通过 MQ(Message queue,消息队列)传递消息。
不要简单地认为所有接口都是你熟悉的,总有一些项目会采用不常见的方式,比如,我曾见过有系统用 FTP做接口的。
所有这些都相当于信息承载方式,再进一步就是了解具体的信息是什么格式,也就是协议。
今天常见的协议是 JSON 格式,或者是基于某个开源项目的二进制编码,比如:
Protocol Buffers、Thrift 等等。一些有年头的系统可能会采用那时候流行的协议,比如:XML;有一些系统则采用自己特定领域的协议,比如,通信领域有大量3GPP 定义的协议。
一般来说,从外部接口这件事就能看出一个项目所处的年代,至少是技术负责人对技术理解的年代。
了解完外部,就该了解内部了。了解内部系统也要从业务入手,对应起来就是,这个系统由哪些模块组成,每个模块承担怎样的职责。如果系统已经是微服务,每个服务就应该是一个独立的模块。通常这也是一个发现问题的点,很多系统的模块划分常常是职责不清的,因此会产生严重的依赖问题。在前面的内容中,我多次提到限界上下文,用限界上下文的视角衡量这些模块,通常会发现问题,这些问题可以成为后续工作改进的出发点。
业务之后是技术,对应着我需要了解分层。前面说过,分层结构反应着系统的抽象。我希望了解一个模块内部分了多少个层,每个层的职责是什么。了解了这些对系统的设计,也就对系统有了一个整体的认识。设计之后,就到了动手的环节,但还不到写代码的时候。我会先从构建脚本开始,了解项目的常用命令。我预期从版本控制里得到的是一个可以构建成功的脚本,如果不是这样,我就知道哪里需要改进了。
最后才是代码,比如,代码的目录结构、配置文件的位置、模块在源码上的体现等等,这是程序员最熟悉的东西,我就不多说了。作为初步的接触,了解基本的东西就够了,代码是我们后期会投入大量精力的地方,不用太着急。
团队运作
最后,我们还要了解一下团队运作。同样从外部开始,这个团队有哪些外部接口,比如,需求是从哪来的,
产品最终会由谁使用,团队需要向谁汇报。如果有外部客户,日常沟通是怎么安排的。
再来就是内部的活动,一方面是定期的活动,比如,站会、回顾会议、周会,这些不同活动的时间安排是怎样的;另一方面是团队的日常活动,比如,是否有每天的代码评审、是否有内部的分享机制等等。
通过了解这些内容,基本上可以大致判断出一个团队的专业程度,也可以知道自己需要帮助的时候,可以找谁帮忙,为自己更好地融入团队打下基础。你也许会问,了解这么多东西需要很长时间吧?其实不然,因为只需要从整体上有认知,如果有人很清楚团队现状的话,你可以去请教,也许一天就够了,这也是我往往能够快速上手的原因。接下来,就该卷起袖子干活了!
最后感谢Deltamote
原文:https://blog.csdn.net/xianrenqiu1234/article/details/94734729

以上是关于思考方式的主要内容,如果未能解决你的问题,请参考以下文章

学会聪明人的思考方式-解读《聪明人是如何思考的》

如何以递归方式思考?

重新思考面向过程与面向对象

如何以递归方式思考?

思考方式

1.5 面向对象的思考方式