在thoughworks有一句流傳甚廣的話 —— 「在thoughtworks需要有擁抱隨時變化的心態「，因為我們踐行敏捷、我們有各種各樣的客戶，而商機稍縱即逝。作為普通的dev，最明顯的感受是不會像其他網際網路公司一樣長期待在乙個固定的專案，有足夠的時間了解專案的上下文和背景。我們的專案週期足夠短，甚至有時候幾周都算很正常，專案的頻繁切換對dev的要求就是需要快速了解乙個新的專案。
工作之前覺得專案上的「事」應該更重要，隨著工作的時間越長，越能體會「人」對專案成功的決定作用更大。雖然有時候我們調侃某某專案「坑」還是「不坑」，但是實際上了專案才知道，乙個專案「坑」還是「不坑」取決於誰來做這個專案，因此我把這段放到了最前面。
站會應該是第一次接觸到團隊幾乎所有人最好的機會，在第一次站會的時候就應該去了解團隊裡面的所有的角色，以便在後面的工作中找到合適的人去開卡（kick off）、desk check、關卡（sign off），需要注意不是所有的專案都有「全明星陣容」，往往有時候很多角色是兼任的，例如pm兼ba（business analyst，業務分析師），ba兼ux等。
可以主動詢問是否專案中有相關的on boarding的check list 快速了解乙個這個團隊的工作方式，每個專案的工作習慣有一定的差異，工作中on boarding的文件可以快速了解這些，例如需要怎麼開卡、是否需要做desk check，提交**時的comment規範是怎樣的。
另外，主動尋找乙個合適的人一起pair，一起pair來了解乙個新的專案在thoughtworks是非常常規的操作，在剛到專案會給新人一些時間設定環境，熟悉**，這個時候能熟練地老手一起pair幾天可以說事半功倍。
還有乙個重要的tip就是，學會快速記住其他人的名字，這會讓你更方便的融入團隊和得到尊重。
作為乙個dev需要對業務整體的了解才能對單個故事卡有足夠的理解，否則單個故事卡就是橫看成嶺側成峰了。當然最直觀的做法就是去找ba聊聊業務，不過在找ba之前比較好的建議是先找qa要一下測試或者uat（user acceptance testing，使用者驗收測試）環境的位址和賬號，作為乙個普通使用者的角色使用一遍，這樣會從使用者的角度有乙個初步的認識。
在和ba過業務的時，ba 會把原型圖拿出來，這個時候再結合之前自己對應用使用的印象來了解業務背後的邏輯。因為應不是所有的業務邏輯都能在原型圖上得到體現，在實現過程中也會對最初的設計做一些小的調整。還有就是結合現有的功能看原型圖，可以知道哪些已經開發完成哪些還在開發中，這樣後面在自己開發過程中可以參考已經實現了的功能或**。關於原型圖另外乙個tip就是很多專案為了保持專案風格統一，會給出乙個style guide來指定乙個基本的樣式規則，例如間距、字型、顏色等。
有時間可以整體過一下卡牆（story wall），看下專案工作到哪個階段和狀態。很難有足夠的時間細緻的看完所有的故事卡，需要整體有乙個印象即可，但是需要注意的是有些跨功能需求很重要但沒有在故事卡上表現，因為跨功能需求是一些共同的、預設的需求，例如對表單進行驗證、分頁等，如果不注意這一點在開卡時可能會忽略，但是qa測試中會覆蓋相應需求。
其他了解專案業務的方式還有閱讀專案inception（啟動）報告和wiki文件（如果有的話），inception 報告的資訊來自於inception期間從客戶得來的第一手資料。有時候會覺得有些很奇怪的需求（比如使用奇怪的儲存媒介excel而不是資料庫，使用者業務人員需要直接修改資料等），但是往往是因為一些既定背景下妥協的產物，這樣就能理解前任維護者的真實意圖了。
工程師習慣往往是第一時間開啟**，但是隨著專案越來越規範化，一般來說都會被分成多個**倉庫。如果直接讀**有時候會很難整理理解專案的結構。如果專案提供了一些架構圖、流程圖可以拿來參考，如果沒有我們也可以通過一些方法了解了解專案的架構然後嘗試自己畫一些圖形來幫助自己了解專案。
使用c4模型表現專案架構和依賴關係
c4模型是一種層層遞進展開的方式來描述專案結構（系統-容器-元件-類），避免把在繪製圖形的時候把不同層級的實體放到一起，造成架構圖看起來非常混亂。為了表達專案依賴關係，我們可以系統一級（即以每個系統為單位）；表達自身專案架構，用容器這一級。
例如：
這個例子中虛線外部可以表達為系統之間的依賴關係，虛線內部為當前系統展開的各個組成部分。如果很複雜可以畫在兩個圖中表現，當然系統中的每個部分可以進一步放大。
通過檢視**倉庫中的配置檔案可以很容易解專案的依賴情況，因為規範的專案都會把第三方依賴的資訊放到配置檔案中，便於根據不同的環境切換，不會硬編碼到業務**中。
考慮技術架構需要考慮：
使用e-r模型表現資料庫關係結構
e-r圖也稱實體-關係圖，關係型資料庫的靈魂在資料模式之間的關係，通過這種方式達到資料的完整性、一致性、正確性。為了降低冗餘和提高一致性就需要合理的拆分多個資料表。如果資料庫比較大就很難理解實體之間的關係。因為我們可以使用實體-關係圖來表現資料庫的關係結構，一般來說實體-關係圖也會畫出屬性，但是如果屬性較多或者想重點體現關係我們可以也可以省略屬性。
（來自：
使用時序圖表現關鍵邏輯
如果遇到單個業務流程比較複雜，例如下單流程。前後端可能會發生多次api的呼叫情況，這種情況下使用uml的時序圖就非常清晰了。
（無對應專案，僅作為案例展示）
閱讀**時除了檢視通常的**邏輯之外，最好著重看下專案的配置相關的**。例如spring boot中使用@config註解下的類，每個專案的不同點通常在這裡，如果不清楚一些bean的配置方式，往往會被一些簡單的問題坑到。通常來說一些***、過濾器都會放到配置相關的**附近。對全域性的配置多一些了解就可以避開一些奇怪的問題。
另外專案中的打包流程也很值得一看，比如gradle的build檔案，前端的webpack相關的指令碼。
有一些專案會有乙個技術債務清單或者圖表，了解下技術債務能避開一些重複的工作，因為有一些**可能會被重構或棄用，我們沒有必要再在這些**之上做修改。
專案中deveops的check list
專案中的deveops工作很瑣碎，但是如果了解這些資訊，對上線、除錯都有很多幫助，這裡不一一展開，只是提供了乙個清單說明一般的專案都會有那些deveops相關的內容。
定時任務
備份日誌
使用網路拓撲圖表現部署情況
當我們遇到一些線上問題，想要進行除錯，或者準備上線的時候。需要知道網路和伺服器相關的情況，這個時候可以通過網路拓撲圖來描述應用的部署情況。
我把了解專案這部分放到了最後，因為在團隊中有pm和teach lead 對專案整理方面更為關心。但隨著對專案的熟悉，知道一些專案管理方面的情況也必不可少，至少了解一些重要的時間點很必要。
這些時間點串起來基本上就是乙個專案的flight plan。
在專案管理中，干係人管理作為很重要的一部分，因為客戶方往往不可能只會接觸乙個人。聲音大的、要求多的不一定最終拍板，經常不出現的也有可能是能做出重要決定的人。但對dev來說如果需要和客戶其他系統對接，更重要的是找到以下幾類人：
這篇文章基本上屬於check list 型別的「水」文，但是還是決定發出來。交付時間就是實打實的金錢，如果做到讓新成員快速上手最重要的還是要團隊的敏捷實踐做的足夠好、**足夠規範、文件足夠完善。盡量避免在人員的切換上帶來的上下文丟失，團隊交流也不能只是口口相傳，更不能讓某些關鍵的資訊成為「單點故障」，應該及時的傳遞到整個團隊。
附錄
用於軟體架構的c4模型
如何成為乙個偉大的開發者（二）
作者簡介 peter nixey，ruby on rails程式設計師，前計算機視覺學者 企業家，clickpass公司ceo，yc孵化器的企業規劃導師，brojure公司cto。程式設計師在開發過程中，常常會遇到各種各樣的問題，但很少是完全陌生 其它團隊也沒有遇到過的。在stack overflo...
如何保持乙個開發者技術棧更新
作為乙個剛畢業三年的研究僧，並且本科學的是機械，在面對複雜多變的it技術圈時，常常感到困惑。我該拿什麼是作為立身之本?要怎麼樣才能時常保持競爭力？銷售靠嘴巴，碼農靠鍵盤。因此個人理解碼農的立身之本就是高效率基於功能完成編碼，交付需求。高效率編碼如果糾結細節，是乙個永恆討論不完的話題，原因是不同時代有...
乙個開發者的全域性思考
我最近要開發乙個需求，就是統一改一下ui標註，專案採用了元件化，標註是放在底層元件中的，供其他元件共用。需求開發前，我認為我要做的準備如下 1 ui要給我統一的標註 2 本需求涉及到多個元件庫，所以我需要多個元件庫的許可權。準備工作做完之後我就開始開發了，開發過程比較簡單，之後就是交付ui同學驗收。...