劉屹珺

什麼事情都是一步一步來的 焦慮是解決不了問題

在說架構師也是從業務代碼開始的 對底層 業務懂的多更好 在看看自己對於架構師要掌握的技術 能力 業務有沒有達到 沒有不要急 努力提升自己就好了 在一個看公司的體系 有沒有進階為架構師 總之啥時候都要努力提升自己 什麼東西都在進步的 你不進步就容易淘汰了 加油吧

TeHeart

作為一個程序員，當你天天面對代碼很焦慮的時候，可能會是你需要做一定改變的時候，而原因主要在於：

1.你的年齡比較大了，可能面對還是基礎的編碼工作已經有很多不適應了，即所謂的大齡程序員。這個時候也確實該考慮考慮後面的路了，當然，能成為架構師也是不錯的選擇。

2.你的知識技術已經跟不上社會的發展了，即時面對同樣的代碼，你可能沒有其他人更能夠遊刃有餘，所以你感到焦慮。但這個時候你再去學習新的技術，新的知識，可能起步都比較晚了，是考慮轉型或者改變的時候了。

那麼，怎麼樣才能成為架構師？要想成為一個架構師，其實還是需要有很多方面的基礎和能力的，需要專業的技術能力，瞭解行業知識，相關經驗和實踐以及較強的整體設計規劃能力。而這些也不是一蹴而就，學學就可以的。換句話說：不是每個程序員都能成為架構師。

當前這種處境，其實可以考慮更多的方向進行嘗試：

1.項目經理，你如果是長期在一個行業做編碼工作，那對於行業產品相關功能應該是輕車熟路，如果你有比較好的溝通協調能力，那完全可以勝任一個項目經理的角色。而且有技術背景的你作為一個項目經理，在整理項目的把握，包括項目需求設計方面的溝通，確認等都有很大的優勢。

2.產品經理：如果有多年的代碼開發經驗，那可以考慮嘗試轉型做產品經理，一是你對這個行業比較熟悉，對產品也有很深的瞭解，對產品的內部設計更是很深入，只要稍稍學習下關於產品設計方面的內容，就能把一個產品的方方面面的來龍去脈都搞的很清楚，這樣你可以引領一個公司產品的不斷更新迭代。

3.市場銷售：記得有一句話“懂技術的銷售人員是最厲害的銷售人員”，如果你還善於溝通交流，善於表達，那其實可以嘗試轉型做軟件產品銷售，要知道，你比其他普通銷售人員多了一項技能就是可以用技術上的優勢取說服客戶，讓他買單。

濤哥講事

寫業務代碼，本質是用開發工具與運行環境，編寫別人制定的“遊戲”。架構師的工作是設計（照抄、搬來）一套“舞臺背景環境”給寫業務代碼的程序員，使他們按照“約定”行事，做好自己的工作。不滿足於總寫業務代碼，想做架構師，你的焦慮是什麼？不懂業務遊戲規則？不會設計“架構”？沒有機會？還是……？

井151276607

不要著急， 先把增刪改查做好做精，然後再考慮下一步。

需求

先從需求層面想想， 自己是不是把這個需求給弄清楚了？ 無論一個需求有多小，都有主幹分支，次要分支，異常條件等等， 自己是不是都考慮到了？對這個需求有什麼疑問？

界面上都有哪些輸入？什麼數據是合法的，什麼是不合法的？不合法的應該給出什麼提示？

如果是Web系統，還需要考慮安全， 會不會產生XSS，CSRF，SQL 注入等攻擊? 如果框架已經幫著實現了， 正好可以研究一下人家是怎麼做的。

代碼層面，審視一下自己的代碼是不是簡潔、易懂？ 變量的命名是不是很容易理解？ 代碼的自解釋性如何, 沒有註釋能不能看懂？ 代碼的格式是不是符合公司要求的規範？

由於代碼被閱讀的時間要遠遠多於代碼被寫出的時間， 心裡要時刻想著：我寫的代碼在維護時是要被別人看的，可讀性一定要好，否則會被別人罵死。

到了開發者測試的時候， 自己一定要做充分的測試， 爭取在交付給測試組以後基本上測不出什麼重要Bug。

測試

此外，公司是不是要求寫自動化的單元測試和功能測試？公司用了哪些框架來做自動化都是應該學習的東西。

雖然這是一個增刪改查的小模塊，但是麻雀雖小、五臟俱全，你把需求、開發、測試真的搞好了， 交付了“清爽”的、基本沒有Bug的代碼， 就會給大家尤其是領導帶來深刻的印象： 這個小夥子不錯！有前途！

於是更多重要的工作就逐漸地交給你了。

在這個階段，有些人會發現自己真的不適合編程， 不喜歡和計算機打交道， 坐不住， 沒辦法靜下心來寫代碼， 但是比較擅長和人溝通和交流， 這時候不妨考慮換個發展方向，也許做銷售、產品經理，項目經理，業務分析等方向更適合你， 編碼只是軟件開發的一部分， 不一定非要在編碼這一棵樹上吊死， 還是找一個你更加喜歡的工作方向， 投入進去，會有更大的發展。

把自己的一畝三分地搞好以後還不夠， 要想辦法看到全局，看到整個系統是怎麼運轉的， 現在很多面試在問面試者項目經驗的時候，經常會先讓他講一講項目的業務背景， 然後從大的架構講講整體的技術， 最後才會進入自己真正負責編碼實現的小模塊， 很多人都會卡在第一步。

所以光關注自己這一塊是不行的， 眼界得開闊， 一有空就要去了解其他模塊的業務和技術， 閱讀項目的代碼， 慢慢的形成一個整體概念。

代碼

不要害怕/討厭看別人的代碼， 這是一個無法邁過的階段， 我們工作中大部分時間都是在讀別人的代碼（再次強調， 寫出可讀性代碼非常重要）， 然後在其中改那麼幾行， 很少有系統是讓你從頭開始敲出來的，如果你碰到了，那就太幸運了。

從本質上來說，這其實是個態度問題， 或者說是上進心的問題， 你完全可以幹完自己的活以後優哉遊哉， 也可以費勁心力的去了解業務， 把那些“變態”的代碼看明白， 但是兩者之間的差距很快就會體現出來， 那些主動的人就能在團隊的討論中發出自己的聲音和見解， 被動人的只能在那裡傾聽。

業務

說到業務，搞技術的人切不可忽視，尤其是在一些行業軟件中(如金融，保險，電力等)， 基本上是業務導向， 畢竟軟件只是支撐系統， 人家還是靠業務來賺錢的。 如果你既精通技術， 又精通業務， 就構築了自己的核心競爭了， 那會非常吃香，公司一定會牢牢的抓住你， 不讓你走的。

總而言之， 如果長期陷入到增刪改查的包圍中，人就會廢掉， 我們要做的就是提升眼界、轉變態度、立刻行動， 這些是最終決定你能否迅速突圍的關鍵。

回答完畢，希望對你有幫助，喜歡可以關注點贊。

做工程師不做碼農

有意思的問題。我認為算法和架構本就來源於業務，是對既有業務的提煉。如果只見業務不見架構，說明沒有認真思考過技術，沒提煉出重用的部分與不足之處。如果只見架構不見業務，說明對業務沒有足夠的認識，不理解業務的來龍去脈與發展方向，不知道哪裡是用戶需要與公司盈利點。

如果真的寫業務寫到焦慮，抬頭看看路，多和你的領導交流交流，視野變高了就不會焦慮了。

關鍵字: 架構師 職場 進階