我是一個假的架構師，真的程序員。
現在所在的項目，是去年八九月份啟動的，雖然不是一個網站，但是大部分工作都是類似的，那么我給大家介紹一下這半年我做了哪些工作。
一般新建一個項目有兩種背景：
一種是沒有系統，需要重新建立；
一種是有老系統，但是因為種種原因，需要新建一個系統把老系統替換掉（或替換部分功能）；
我們算是后者，老系統已經運行多年，主要工作是對外提供接口服務，現在服務的效率和抗壓性都無法滿足業務需求。
需求梳理
需求，在開發之前一定要明確需求。因為是對老系統的改造，所以需求相對來說比較明確。
梳理老系統有多少接口，壓力比較大的接口有哪些，確定接口遷移的優先級。
確定第一批遷移的接口之后，需要對接口的處理邏輯進行梳理，包括出參入參都是什么，對參數有哪些校驗，出參的是從什么表的什么字段取得，查詢條件是什么，是否對數據進行了加工、轉移等處理。
主要是通過“扒代碼”的手段，這一步很痛苦（程序員們都懂的）。
壓力預估
因為是老改新，壓力容易預估出來，我們主要關注的幾個點：
現有系統的數據量有多少，年增長的數據量是多少。
多少系統在調用，大概服務器的數量是多少。
平均每天的調用量，如果業務幾種在某些時間段內，比如工作時間，那么就要估計出每小時的量大概是多少。
業務高峰期的時候，量有多少。
架構設計
其實我也是野路子出身，我在做這一步所做的工作有這些：
整理項目的功能點，比如我們這個項目主要功能有：數據抽取、數據存儲、數據加工、服務提供；這一步形成整體的功能架構。
對每個大的功能點，評估需要使用的資源，拿數據加工為例：數據加工主要就是批處理，需要Tomcat部署Java程序，需要Redis做分布式鎖和緩存，需要MongoDB做加工后的數據存儲；這一步形成整體的方案規劃。
繼續詳細的評估，根據前期統計的數據量，對MongoDB的部署進行評估：是否需要分片，如果分片的話，前期部署幾個分片，容量申請多少；當這些評估都做完之后，就可以把一個一個的點匯總起來，就形成了物理部署架構。
到了這一步，基本上技術架構圖也就出來了。
在設計過程中，還要和很多人進行溝通，比如DBA、比如領導。
開發
到了開發階段，我依然在。
這時候，一邊招人（招人有些晚了），一邊搭框架；一邊面試，一邊寫代碼。
最后開發人員招的差不多的時候，我從無到有，第一個接口基本上開發完成了...
現在嘛，我依然在項目里面，溝通需求、設計、任務分配、寫寫代碼、看看開發人員寫的代碼再給他們提提意見，如果別的項目組有設計或開發方面的問題，我也會幫忙處處主意；
我總覺得我是個假的架構，真的程序員。