很多it新人都對架構感興趣，我的團隊裡打算往架構方向發展的同事也不少（我在乙個二十人左右的軟體團隊裡任部門經理），他們會問我要往哪個方向去努力，看什麼書啊，積累什麼技能啊，但怎麼說呢，或許是我的見識有限，我覺得很難用幾句話說清這件事情。
上網搜尋「如何成為架構師」，大部分人都說得靠經驗、得積累等等。去買架構的書看（比如《軟體架構實踐》），讀了幾個月發現除了一堆「需求場景、軟體切面、架構評價公式」等學術性的東西，對如何用自己的雙手敲出乙個架構還是知之甚少。和認識的架構師聊，發現大家談的要麼是泛泛的東西，要麼就是和他所設計的軟體細節息息相關，沒有通用性。
所以我們很難找到乙個所謂的「架構書」或者「架構課程」，更加沒有所謂的「萬能架構公式」。架構本身就是和應用場景緊密相關的東西，乙個這軟體裡非常棒的架構，放在另乙個場景可能沒法滿足哪怕最基本的要求。
但我們就沒有一條學架構的「路」了嗎？
不通過實戰說不定還真沒有，起碼我說不出來。但每個架構師多少還是有一些心得，包括我這樣的「小」架構師。所以我打算把我做架構的幾年經驗從頭到尾分享出來，形成乙個簡單的系列，希望對我，對大家都有裨益。
先說架構的前置條件：程式設計相關知識、語言及工具的熟悉、邏輯思維等程式設計相關能力、功能實現的能力、模組實現的能力、網路資料庫等工具的理解、業務場景的熟悉、小架構的能力、然後是真正的架構能力。
程式設計相關知識：包括資料結構、演算法，也可以包括計算機體系結構、作業系統、計算機網路、計算機圖形學等。這些知識在一些學校計算機相關課程裡都會有教。有些同志可能會說，我不喜歡學術，喜歡工程，喜歡實實在在敲**的感覺；再說，我的工作看起來也用不到什麼複雜的圖遍歷啊、時空複雜度的計算啊等等，更用不到cpu構成、任務排程和路由演算法；再退一步說，等到我需要這些知識，我去學就好了。
我本人是北京大學的本科和碩士，還差一點讀了博士，但我曾經有點為了學而學，沒有學出什麼成績。在我任部門經理前，我的想法和上述一樣，並不覺得書讀得多有好處，甚至比較贊同上面「知識用不到」的說法，也曾為自己沒有抓緊時間做實際工程而在學校裡「虛度時光」而後悔。
但隨著工作的深入，隨著自己從程式設計師成長為「程式設計師」，到架構師，到軟體部經理。隨著我和我的同學、前輩、同事、後輩交流的增多，從乙個被指導的角色成長為乙個指導的角色。我慢慢發現，在邏輯思維能力、溝通能力、努力程度等情況相當的時候，大部分在學校好好學了「學術」方面書的同學在技術潛力上確實比只關注工程的同學強。這種強更多的體現在一種架構師方向的發展瓶頸上。簡單點說，一名經驗豐富的同事我可能認為再成長幾年也難以在架構方向上獨當一面，但一名工作較短的研究生卻能讓我看到短中期培養成型的可能。
但這並不意味著擅長學術的人發展得一定更好。發展通常有兩個方向，乙個是縱向，乙個是橫向。部分經驗豐富、溝通、努力、動手能力都較強，但學歷比較低或者不關注學術的同事，我將他往橫向的方向培養，成為專案管理人員、駐場專案經理或者大區的技術負責人，甚至還以銷售、大專案經理為目標；我們公司是做指揮室、會議室、展覽館等情況下的視音訊軟硬體整合的，因此從公司和行業的角度，這些橫向發展的人其價值甚至比單純的架構師更大（因為短期來說，我們這個非網際網路公司用不到複雜架構）。
那縱向發展為什麼需要「多讀書」呢。可能的理由有：1、書讀得多，對軟體工程的理解就深。這不是單純敲**能敲出來的。2、很多書裡面，其實有很多好的架構知識，甚至架構的雛形，比如作業系統的任務排程就是一種架構思想；路由演算法、tcpip協議棧的思想也是。3、架構師，需要在網路、資料庫、效能等各方面都具備知識，也就是要有思想和知識上的廣度。
再說架構的第二個前置條件：語言及工具的熟悉，不用多說相信大部分都理解，並且具備能力。但從一些由運維、需求和測試人員轉程式設計的情況看（我會提供三個月的內部嘗試機會），語言和工具零基礎的同志轉程式設計還是有相當障礙的。也就是說比起大學四年多多少少敲過**的人來說，他們要在實際工作中敲好**會難上乙個層次。其中最缺乏的並不是不認識語法，而是缺少一種「程式設計素養」。比如沒法很好的理解為什麼要寫個函式，為什麼要寫個類來完成任務，而不是用**從頭到尾把功能實現完。而這些是真正的程式設計師們認為自然而然的事，我要教起來都有點不知從何說起。
程式設計相關能力：在有了學術和一點工程基礎之後（基本大學裡好好學的同學都會有），接下來最為重要的就是如下能力了，包括抽象能力、邏輯思維能力和大局觀。做好架構師，這三方面都很重要。抽象能力，是把乙個龐大的「任務」劃分成乙個個可理解可接受模組的基礎，邏輯思維能力，是啃下任務中核心演算法的基礎，而大局觀，是把架構優化好的基礎。
模組實現的能力：功能做好了之後怕的就是一直帶著「功能」的思想，給任何任務都從功能的角度一路往下做。功能做得比較熟之後就要想著從碼農轉變為「設計師」了，這時候起碼得有「做好乙個模組」的意識。這階段，學會寫偽**，學會抽象很重要。
網路資料庫等工具的理解：「設計師」做了一陣，需要的就是熟悉軟體工程裡面的一些重要工具了。包括網路、資料庫、json、協議等。有了這些才有未來做架構的工具基礎。
業務場景：想做架構，你要對軟體的業務場景特別熟悉。很多同志認為技術是技術，業務是業務。站在架構師的角度其實不完全是對的。技術的目的是實現業務，如果你都不知道你要實現什麼，那你用的技術可能是有問題的。
有了以上的諸多準備，你才能晉級為乙個菜鳥架構師，做一些介於模組和架構之間的「小系統」。
最後，在小系統上積累足夠多思考，你就能開啟架構之路了。
第一小節，也就是架構系列的前言就說到這兒吧。以後我會抽空根據我遇到的實際問題，把如何成為架構師盡量具體的描述出來。
小白聊架構師 怎麼成為架構師
還有人說 我早就掌握了物件導向設計，也看了 企業應用架構模式 架構之美 大型 技術架構 等等架構的書，為啥還當不了架構師？是啊，這高階，大氣，上檔次的架構師是怎麼煉成的？這裡講乙個小王的故事吧。又到了畢業季，一批應屆生進了乙個軟體公司，小王也在其中。新人進入公司，基本上都是從最底層做起，做那些最髒最...
架構師速成1 前言
從事it工作10餘年，痛並快樂著。忠告以下人員遠離it 不能吃苦 耐不住寂寞 想賺大錢 如果你不是上面的人，而且非常想成為架構師話，請繼續看下去。需要3年時間 需要超強自制力 需要極強計畫能力 需要吃苦 如果你能滿足以上4條，那肯定就可以速成。可能有人會說 3年也算速成，這也太龜速了 我回答你，如果...
如何成為真正的資料架構師
下面是內容概要 1 為什麼需要構建資料結構？1 資料標準不一致 2 資料模型管理混亂 3 深入的效能的問題無法解決 4 sql語句編寫水平不高導致出現嚴重效能問題 5 開發人員對執行計畫收悉 6 上線前缺乏審計 7 相對複雜的資料處理能力欠缺 8 資料質量差需要執行資料質量管理 2 資料管理組織角色...