马上面临毕业 对于整个社会的价值观和眼界都会不断的扩大 这几天看到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
原文地址：https://www.cnblogs.com/suhaohao/p/11154120.html