思考方式
馬上面臨畢業 對于整個社會的價值觀和眼界都會不斷的擴大 這幾天看到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
總結
- 上一篇： 想要变强大
- 下一篇： js Object的属性 Configu