回覆列表
  • 1 # IT人劉俊明

    對於程式設計師來說,架構師是未來一個重要的發展方向,不少程式設計師都希望透過自己的努力最終走向架構師崗位。架構師是軟體團隊中不可或缺的重要崗位,架構師不僅有豐富的技術經驗,同時要具備一定的技術攻關能力和方案設計能力,能時刻根據技術的發展趨勢對專案整體方案進行不斷的升級,以應對應用環境的變化。

    對於普通程式設計師來說,如果想成長為架構師,需要做好以下幾件事:

    第一:具備較強的研發能力。對於從程式設計師出身的架構師來說,往往都需要經歷初級程式設計師、助理程式設計師和主力程式設計師等幾個重要的階段,這個階段是積累研發能力的重要階段,一定要不斷透過能力的提升來完成崗位的升級。按照歷史經驗來看,往往能夠主動承擔更多開發任務的程式設計師會有一個較快的成長速度。

    第二:具備較強的學習能力。架構師的成長一方面是透過崗位升級來完成的,更重要的是能透過自主學習來掌握更多的設計知識。我在早期進行Java開發的時候,發現Java的模組化設計是一個比較麻煩的事情,然後透過自主學習掌握了OSGI的應用,這也為我的第一個研究方向奠定了基礎,我的第一個研究方向是動態軟體體系結構。

    第三:具備一定的前瞻性。軟體架構設計一方面要滿足當前的專案需要,另一方面也要具備一定的擴充套件能力,能夠在一定的時期內保證軟體可以不斷進行動態擴充套件,這就要求架構師在方案設計方面有所考慮。當前處在大資料、雲計算時代,軟體的整體設計思想一定要考慮到未來大資料發展所帶來的改變。

    總之,要想從一名普通程式設計師成長為架構師,一定要積累足夠多的研發經驗,同時要具備較強的學習能力和交流能力。另外,架構師還要具備一定的方案設計能力。

  • 2 # 小紅櫻桃

    1.首先要知道,不是每個人都能成為架構師,能成為CTO,也不是每個人都適合去做架構師,要弄清楚架構師的職責,結合自身興趣愛好和目前的優勢,去補齊制約你成為一名出色架構師的短板。

    2.從增刪改查進階到架構師,需要積累更多的只是技能,除了語言本身,架構設計這些是相通的,不管你是什麼語言,需要搭建CDN,需要使用快取,需要用到搜素引擎,需要用到更重關係型資料庫或非關係型資料庫,分庫分表技術,訊息佇列,分散式,微服務等等

    3.技術很重要,但是成為架構師,悟性思維,情商智商更重要,要擴大自己的視野,不斷去了解技術之外的事情,很多事情都是想通的,閱歷到了,你也自然具備成為架構師的能力了。

    4.實踐是檢驗真理的唯一標準。你想盡快提高自己的架構設計的能力,只有一個辦法,那就是高強度的實戰,最好是能有一個能快速發展的專案,從實戰中拿去經驗,這個辦法是最好的。如果有手把手帶著你設計一套分散式系統這樣的場景,從linux搭建再到系統設計,再到程式碼規範,再到程式碼review等等,你多參與這樣的系統設計,你的成長是最快的。跟著專案從0使用者發展到千萬級甚至億級使用者,頭疼的各種問題會逼著你不得不想出各種辦法保證服務的穩定,這樣的成長才是最快的。

    5.堅持!!!,一定要堅持

  • 3 # 架構思維

    我個人認為成為架構師的幾個必要條件:

    紮實的基礎

    寫了幾年程式碼了,但是技術夠紮實嗎?是隻會寫寫CRUD,還是涉及的技術都清楚原理?就以Java的IO體系來說,你是會使用Java的IO API來讀寫資料?還是能清楚的知道什麼是BIO?什麼是NIO?使用NIO要注意哪些問題?Java裡的NIO設計有哪些問題?BIO的適用場景在哪裡?NIO的適用場景又在哪裡?什麼是同步IO?什麼是非同步IO?什麼是同步阻塞IO?什麼是同步非阻塞IO?什麼是非同步阻塞IO?什麼又是非同步非阻塞IO?什麼是Reactor模型?什麼是Select?什麼是poll?什麼是epoll?......

    雖然架構設計是上層設計,但是考慮的問題點很多都和底層相關。比如效能的一個關注點就是IO,是使用BIO還是NIO?你就需要對BIO,NIO有所瞭解,不能看別人說NIO效能高就選NIO。可能你的應用場景並不適用NIO。比如業務複雜,資料量大,但是呼叫並不頻繁,這種情況可能BIO就更合適。

    思維方式的轉變

    之前流行一句話「小孩子才爭對錯,成年人只論高下」!在軟體裡,可以說「程式設計才爭對錯,架構只論高下」!你寫程式碼,主要確保的是語法和業務的正確性。程式碼的結構化、效能的最佳化方案也基本都是確定的。

    而架構是選擇,是決策。終點(目標)都能到達,單哪條路(架構方案)是最優路徑呢?之前回答了一個問題「當資料庫扼住系統性能,直接分庫分表能解決嗎」?這個問題就是程式設計思維,針對一個問題想找到一個確定的方案。實際上缺少了對場景的考慮!具體這個效能是哪裡出問題了?是sql問題?應用程式碼問題?業務問題?還是訪問量問題?等等等等,不同的問題有不同的解決方案。

    廣泛的技術面

    上面說了,架構是選擇、是決策!而技術面確保了可選項的多少。如果技術面較窄,就相當於只有一個可選項,實際就是沒有選擇!你的架構可能就不是最優的。假設你只知道分層架構,那麼你的架構都只能使用分層架構。對於需要高效能的IO通訊的系統,分層架構就沒有EDA架構合適!

  • 中秋節和大豐收的關聯?
  • 為什麼CBA小動作會犯規,而且NBA動作更大,卻不會犯規?