互連網項目中的工具式架構

在需要敏捷開發的互連網項目中，不要讓一個所謂的架構師把所有東西封裝起來，藏的嚴嚴實實，然後告訴所有人都按照我的結構去執行，這樣的話：
1、這個架構師會成為瓶頸，他很累，專案經理很揪心。
2、這個所謂的架構師通常不僅是技術的主力還是業務的主力（因為不熟悉業務的架構師不配做架構師），他的精力往往沒有那麼多。
3、架構師很辛苦，實現了一個很美好的結構，制定了一個很嚴整的規範，等版本發出來之後，發現滿眼都是莫名其妙的崩潰。不得己，跟一下，發現制定並宣講了N遍的規範根本就沒有得到執行。管理中最基本的問題：執行力，擺在面前，寫程式也需要執行力。脾氣好些的，發現了誰的問題就去告訴誰，一遍遍的，像祥林嫂一樣。硬氣點兒的漢子就會發布一個懲罰條例，發現一個斃一個，然後直到只剩下光杆司令。
面對第三個問題，傳統的軟體行業技術架構師們會出一堆的靜態結構、動態結構圖，把每個條文列出來。但現在互連網行業，規範在完整，但更講究快，一個項目三個月就要出，後面每一版的迭代都很快。產品需求變的比結構設計更快。腫麼辦？

拋磚引玉，提一些自己在互連網項目開發方面的心得：
1、把架構性的東西盡量拆分成工具，分散到參與項目的各個成員身上，並提出一個寫工具的規範，如注釋、調用、命名、使用規則等。所有成員提供的工具都應該按照這個規範執行並由一個沒有使用過的人來驗收，標準就是很短的時間內把所有要點掌握，這個時間越短，工具越成功。
2、寫工具的人一定要從使用它的人中選一個，他自己才知道怎麼用得方便，出了問題也好在自己的代碼裡面調試。
3、所有的團隊積累都應該是按分類存在的工具，然後根據不同的項目進行組合，而沒有很強勢的“底層結構”。這樣也才能避免團隊的積累帶有很深厚的個人風格，團隊的積累才不會與需求的頻繁變動和人才的流動侵蝕相衝突。

4、不要想一年甚至半年以後我要發展成什麼樣子，然後以堆積木的心態去創造龐大的結構。老老實實按業務拼出功能，把花大力氣協調來的資源用在最佳化UI／UE和服務細節上面，同時努力提高用戶端程式的效能和穩定性。然後根據使用者的愛好和傾向迅速調整自己的業務方向和技術方向。

5、測試主要應該從三方面著手：商務邏輯（與需求是否一致）、記憶體佔用穩定性（程式在使用時是否存在記憶體高峰、記憶體流失等）、流暢度（如長列表滑動、頁面切換時的流暢度）、UI是否和一致（UI走查）

根據這幾點，我認為，能根據業務要求迅速調整技術方向的人，熟悉業務並關注產品細節的人，懂得技術是為產品細節服務並願意為之付出努力的人，通過不停的溝通使項目參與各方節奏一致的人，都是項目中最重要的資產。