馬上面臨畢業(yè) 對于整個社會的價值觀和眼界都會不斷的擴大 這幾天看到Deltamote的一篇文章 認為很有道理

思考方式及狀態(tài)進入：
工作產(chǎn)出不是由寫代碼的效率決定的，一些不恰當?shù)墓ぷ鞣椒ê艽蟪潭扔绊懼愕漠a(chǎn)出。
首先要問自己三個問題：
我現(xiàn)在是一個什么水平？
我想達到什么水平？我將怎樣達到那個目標？
這三個問題實際上是幫我們確定：現(xiàn)狀；目標；實現(xiàn)路徑。
如果一個人能夠清晰地回答出這三個問題，通常意味著他對要做的事情有著清晰的任認識，這個框架雖然看起來簡單但非常有效，它已經(jīng)成為一件非常稱手的思考工具。
在實際工作中，作為產(chǎn)品經(jīng)理也需要經(jīng)常問以下幾個問題：
為什么要做這個特性，它會給用戶帶來怎樣的價值？
什么樣的用戶會用到這個特性，他們在什么場景下使用，他們又會怎樣使用它？
達成這個目的是否有其它手段？是不是一定要開發(fā)一個系統(tǒng)？
這個特性上線之后，怎么衡量它的有效性？
為了把這個框架應用到程序中，需要以下四個原則：
以終為始，確定好真實目標；（我們要到哪里去）
任務分解，找到實施路徑；（我們?nèi)绾蔚竭_那里）
溝通反饋，解決與人打交道出現(xiàn)的問題；（我們?nèi)绾蔚竭_那里）
自動化，解決與機器打交道出現(xiàn)的問題，自動化就是將繁瑣的工作通過自動化的方式交給機器執(zhí)行，這是我們程序員本職工作的一部分。。（我們?nèi)绾蔚竭_那里）
我們不是一個人孤獨地在工作，而是與其他人在協(xié)作，想要做到高效工作，我們就要“抬起頭”來，跳出寫代碼這件事本身。
程序員的優(yōu)秀程度最能體現(xiàn)在自動化這個環(huán)節(jié)中，高手首先對自己要到達的目的地的實現(xiàn)細節(jié)了如指掌，同時可以用較短的時間轉(zhuǎn)化為自動化工具或者程序。同時超前的視野和豐富的開發(fā)經(jīng)驗也不是一個新手能。
如何快速進入工作狀態(tài)：
首先要運用上面的三個框架：處于什么水平，要到達什么水平，怎么達到那個水平
技術是要肯定了解的，技術解決的是怎么做的問題，但我們第一個應該了解的問題是做什么。
一個軟件到底在做什么，能夠回答這個問題的就是業(yè)務，所以我們排在第一優(yōu)先級的事情就是業(yè)務。
所以不管做什么項目，首先要從大圖景入手，只有了解了大圖景，各種知識才能各歸其位。對于一個程序員來說，業(yè)務就是大圖景，如果你了解了業(yè)務，你自己就可以推演出基本的代碼結構。但反過來，如果讓你看了代碼，從中推演出業(yè)務，那幾乎是不可能的。事實上，每次了解到一個業(yè)務，我都會在腦子中過一下，如果是我做這個業(yè)務，我會怎么做。這樣一來，我就會先在整體上有一個預判，后面再對應到實際的代碼上，就不會那么陌生了。要了解業(yè)務，我一般都會請人給我講一下，這個業(yè)務是做什么的，解決什么樣的問題，具體的業(yè)務流程是什么樣子的，等等。在初期的了解中，我并不會試圖弄懂所有的細節(jié)，因為我的目標只是建立起一個基本的框架，有了這個初步的了解，后續(xù)再有問題，我就知道該從哪里問起了。
理論上，了解業(yè)務是每個程序員都該做的事，但事實上，這也常常是出問題的地方。在請別人給我講解業(yè)務的過程中，我發(fā)現(xiàn)，很多人是分不清業(yè)務和技術的，經(jīng)常把二者混在一起講。如果你跟著他的思路走，很容易就會陷入到對細節(jié)的討論中。所以，了解業(yè)務時，一定要打起精神，告訴自己，這個階段，我要了解的只是業(yè)務，千萬別給我講技術。
技術
了解完業(yè)務，就該到技術了。這是程序員最喜歡的話題。但即便是了解技術，也要有個順序，所以，我們先從宏觀內(nèi)容開始。第一個問題就是這個系統(tǒng)的技術棧：Java、JavaScript 還是 .NET，這樣，我就可以對用到的工具和框架有個大致的預期。
接下來是系統(tǒng)的業(yè)務架構，這個系統(tǒng)包含了哪些模塊，與哪些外部系統(tǒng)有交互等等。最好能夠有一張或幾張
圖將架構展現(xiàn)出來。現(xiàn)實情況是，不少項目并沒有現(xiàn)成的圖，那就大家一起討論，在白板上一起畫一張出來，之后再來慢慢整理。
有了一個初步的體系，接下來，就可以稍微深入一些。
我會選擇從外向內(nèi)的順序了解起。首先是外部，這里的外部包括兩個部分：
這個系統(tǒng)對外提供哪些接口，這對應著系統(tǒng)提供的能力；
這個系統(tǒng)需要集成哪些外部系統(tǒng)，對應著它需要哪些支持。
一旦涉及到與外部打交道，就涉及到外部接口是什么樣子的，比如，是用 REST 接口還是 RPC（RemoteProcedure Call，遠程方法調(diào)用） 調(diào)用，抑或是通過 MQ（Message queue，消息隊列）傳遞消息。
不要簡單地認為所有接口都是你熟悉的，總有一些項目會采用不常見的方式，比如，我曾見過有系統(tǒng)用 FTP做接口的。
所有這些都相當于信息承載方式，再進一步就是了解具體的信息是什么格式，也就是協(xié)議。
今天常見的協(xié)議是 JSON 格式，或者是基于某個開源項目的二進制編碼，比如：
Protocol Buffers、Thrift 等等。一些有年頭的系統(tǒng)可能會采用那時候流行的協(xié)議，比如：XML；有一些系統(tǒng)則采用自己特定領域的協(xié)議，比如，通信領域有大量3GPP 定義的協(xié)議。
一般來說，從外部接口這件事就能看出一個項目所處的年代，至少是技術負責人對技術理解的年代。
了解完外部，就該了解內(nèi)部了。了解內(nèi)部系統(tǒng)也要從業(yè)務入手，對應起來就是，這個系統(tǒng)由哪些模塊組成，每個模塊承擔怎樣的職責。如果系統(tǒng)已經(jīng)是微服務，每個服務就應該是一個獨立的模塊。通常這也是一個發(fā)現(xiàn)問題的點，很多系統(tǒng)的模塊劃分常常是職責不清的，因此會產(chǎn)生嚴重的依賴問題。在前面的內(nèi)容中，我多次提到限界上下文，用限界上下文的視角衡量這些模塊，通常會發(fā)現(xiàn)問題，這些問題可以成為后續(xù)工作改進的出發(fā)點。
業(yè)務之后是技術，對應著我需要了解分層。前面說過，分層結構反應著系統(tǒng)的抽象。我希望了解一個模塊內(nèi)部分了多少個層，每個層的職責是什么。了解了這些對系統(tǒng)的設計，也就對系統(tǒng)有了一個整體的認識。設計之后，就到了動手的環(huán)節(jié)，但還不到寫代碼的時候。我會先從構建腳本開始，了解項目的常用命令。我預期從版本控制里得到的是一個可以構建成功的腳本，如果不是這樣，我就知道哪里需要改進了。
最后才是代碼，比如，代碼的目錄結構、配置文件的位置、模塊在源碼上的體現(xiàn)等等，這是程序員最熟悉的東西，我就不多說了。作為初步的接觸，了解基本的東西就夠了，代碼是我們后期會投入大量精力的地方，不用太著急。
團隊運作
最后，我們還要了解一下團隊運作。同樣從外部開始，這個團隊有哪些外部接口，比如，需求是從哪來的，
產(chǎn)品最終會由誰使用，團隊需要向誰匯報。如果有外部客戶，日常溝通是怎么安排的。
再來就是內(nèi)部的活動，一方面是定期的活動，比如，站會、回顧會議、周會，這些不同活動的時間安排是怎樣的；另一方面是團隊的日常活動，比如，是否有每天的代碼評審、是否有內(nèi)部的分享機制等等。
通過了解這些內(nèi)容，基本上可以大致判斷出一個團隊的專業(yè)程度，也可以知道自己需要幫助的時候，可以找誰幫忙，為自己更好地融入團隊打下基礎。你也許會問，了解這么多東西需要很長時間吧？其實不然，因為只需要從整體上有認知，如果有人很清楚團隊現(xiàn)狀的話，你可以去請教，也許一天就夠了，這也是我往往能夠快速上手的原因。接下來，就該卷起袖子干活了！
最后感謝Deltamote
原文：https://blog.csdn.net/xianrenqiu1234/article/details/94734729

轉(zhuǎn)載于:https://www.cnblogs.com/suhaohao/p/11154120.html

總結

以上是生活随笔為你收集整理的思考方式的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。