@首先當然基礎知識要紮實，一些經典的專業書籍一定要看。比如，設計模式，演算法，資料結構，所在領域的程式語言的專業書籍等.關於不同的能力階段，需要讀取什麼型別的書籍，請參考ThoughtWorks(中國)程式設計師讀書雷達,每年都有更新。

程式猿細分成很多種型別，要先搞明白你要要發展的領域，還是多個領域，那麼其次就是先把理論知識搞定，再就是多實踐參與開發專案。

謝邀。這個問題不太好回答，因為要回答這個問題，或者有資格回答這個問題。回答者起碼已經成為專家了。而我只是個畢業五年，一直從事著計算機相關工作的普通程式設計師，自認為天花板還遠遠沒到。既然被邀請了，就厚著臉皮回答一下。可能會班門弄斧，請勿見笑。

我認為要成長，學習是一個不可避免的過程。計算機是一個快速迭代的行業，可能現在用的是當下正流行的技術，過幾年就會過時。只有不斷學習新的東西才能與時俱進，學的東西多了才能融會貫通。

學習是總方針，堅持是具體的方法論。計算機是一個浩瀚的世界，可能窮其一生才研究了一點皮毛。太多的選擇擺在眼前可能就容易迷失。要記住，不忘初心，方得始終

找好一個你要發展的方向。不要東搖西擺，找到一個定位，朝著那個方向深入研究，然後其他的東西適當瞭解一下。計算機基礎多去學習一下，瞭解透徹一點。多思考，多研究，而不是隻是單純關注在程式碼層面了。

程式設計師很多，能夠成為行業裡面的“大牛”程式設計師的卻比較少，但是透過自己的努力成為一名優秀的程式設計師還是有不少人做到了，相信大家也都知道，優秀的程式設計師可以編寫出特別的功能、網站、應用程式等等，那麼優秀的程式設計師們都有哪些共同特點呢？

基礎知識是每位程式設計師都掌握了的，但是優秀的程式設計師不僅將這些基礎的知識瞭如指掌，還將這些知識的原理了然於胸，在這個基礎上，他們在發揮自己想象力和創造力，提出突破性的想法。

任何行業都像是金字塔一樣，有一個很大的底部，但是越往上越小，程式設計行業也是如此，程式設計知識也是如此，也就是說，不管是向成為技術大牛，還是想要突破目前自己的技術水平，都是從底部開始的。

想要成為一名優秀的程式設計師，就不能“只知其然而不知其所以然”。因此學習計算科學，並有一定的瞭解和認知，學會了這些，就可以別其他人站在更高的位置上去看待問題，知道計算機為什麼這樣執行，可以幫助你增強上下文知識，成為一名更有見識的程式設計師，在編寫程式碼時也能夠考慮到更多的問題，從而使自己所編寫的程式碼更加的優質。

大部分的時候，當我們的技術進入瓶頸期或者是已經進步比較緩慢的時候，大家了能會更加傾向於選擇透過比較“有趣”的方式來幫助自己進步，這其實也是一個誤區。這個時候如果從基礎開始查缺補漏，會讓自己的進步變得更快，真正掌握了基礎知識的程式設計師才能對自己編寫的程式充滿信心，因為他們知道選擇這麼寫的“方式”和“原因”，這可以改進他們的工作並提升在周圍人中的信服力。

還有就是，紮實的基礎知識可以讓自己在學習新的語言和技術時變得更加容易，因為花時間真正理解一種語言的核心概念，如迭代、遞迴和抽象，將有助於學習另一種語言。因此掌握了基本知識，就會有很多收穫，幾乎沒有什麼損失。

掌握好了基礎知識之後，在需要提升的就是自己解決問題的能力了，程式設計其實就是解決問題，能夠高效的解決問題，才是被大家需要的人才。

有出色的問題解決能力的程式設計師會將問題的本質提煉出來，以便確定他們的總體目標，並有目的地開始解決一個問題。然後，他們將每個問題分解成小的、可控制的部分，並依次將每個部分做同樣的處理，有時還可以透過繪製導圖使其實現視覺化。

簡單的來說，想要成為一名優秀的程式設計師，就必須能夠將基礎知識“吃透”，並並確切地知道自己所寫的程式碼中發生了什麼以及為什麼會發生，還需要培養出高效地解決問題的能力。

原文連結：https://www.toutiao.com/i6730399650437677582/

作者 | 悟尋 阿里巴巴前端技術專家

前言

我將我經歷過的或者正在經歷的狀態，分成三個階段進行總結：求生存，謀發展，修體系。

階段一：埋頭苦幹求生存

作為一個服務一線業務的前端同學，支撐好業務佔據我們 50%-60% 左右的 KPI，縱觀行業前端本身很容易成為整個業務的資源瓶頸，而身為業務的前端我相信一定經歷過疲於奔命，經常線上救火的事情。

我入職後的前一年主要做進口業務：天貓國際，一個包含平臺和自營的業務。當時的進口業務還處於野蠻生長，競爭激烈的階段。經常面臨一年兩大改，日常需求不斷，期間還要應付一年的 5 個 S 級的大促和一些小促，我記得最忙的時候是 17 年雙十一，面臨著自營和平臺兩塊業務的大迭代，同時還需要面臨雙十一大促各種需求，每天除了做業務幾乎沒有什麼思考和總結的過程。而經過那次之後我也深刻體會到對於需求管理和時間管理 & 如何避免線上起火的重要性。這裡我結合自身和團隊的經驗梳理瞭如何打破這種狀態的方法，也歡迎各位補充。

需求管理

首先需求是做不完的，所以要有取捨，集中人力和精力做核心的業務需求，才能發揮最大的價值，如果你所在團隊目前處於各種零散的需求紛至而來導致無法應節的情況，則有必要進行相應的需求管理措施：

1.需求雙週排期會

比如拉上老闆，PD 和業務方 & 開發一起，每兩週(時間可自定義)坐到一起對焦這兩週的專案進展和接下來所有需求，並且確定好優先順序，哪些是應該安排資源進行開發，哪些應該進行取捨，讓更多的精力和人力 focus 在業務的重要事情上。

當然比如業務方靠譜或者有大的規劃，則一般會對財年的目標進行戰役級別的拆解，並且梳理出業務今年必須要要拿下的幾場戰役，那麼技術同學就可以根據戰役來排兵佈陣了，業務和技術同學也有明確的統一的戰線和目標，比如我們目前就是以各種戰役為主，日常需求穿插為輔。

2.如何拒絕一句話需求

在需求雙週排期會中基本能搞定 80% 的核心需求和優先順序，但在平時還是會存在一些業務方/PD 會找你提一些沒有經過梳理和思考的一兩句話的需求，比如：這個商品坑我想從一排一換成一排二的，或者想這個地方的 icon 或者營銷標我覺得字型不好看想修改下等等這樣的訴求。那面對這樣的訴求，在左耳朵耗子的極客專欄中 & 小鬍子哥的部落格都有提到如何拒絕一句話需求的方法，結合我自己的經驗覺得有如下三個遞進的方法來解決：

1. 多問幾個為什麼：這比如你這個需求背後的目的和價值是什麼？做了之後有什麼預期的收益，為什麼這麼做就可以達到這個收益，你可以不直接問業務方，但是你也需要問自己，業務方的這個目標和做這個需求的路徑是否可以匹配得上，如果實現路徑存在邏輯漏洞或者不是最佳的則這個需求也就沒有做的必要性；2. 給出替代方案：經過上面的步驟，其實你會發現你已經過濾了一批無效的一句話需求，而有些需求可能是有一定的存在價值，但是可能業務方提到的點並不是有效的方案或者說成本太大的方案，這時你就需要思考替代方案，儘量透過現有方案或者小成本的方式來滿足業務方，間接的達到“拒絕”的效果；3. 不能直接說不，但可以有條件的說是：當你確定這個需求是 ok 的，但你確實暫時抽不出時間來搞定這個事情的時候，這時關鍵在於我們不能直接拒絕業務方，長此以往會影響到後續的合作關係，這種情況你可以說：這個需求我接受，但是我可能需要較長一些的緩衝時間或者砍一些需求(部分滿足)。又或者必須要按時上的話，不能保證專案的上線後的效果、質量等，讓業務方來做部分的取捨。

提升開發效率 & 質量

當然作為技術人員，需求管理只是一方面，還需要從自身的角度出發，提升開發效率和質量，這個我相信大家都深有體會，儘量不要做低質量的重複事情。

比如透過統一開發技術體系和封裝相應的可複用的元件和提效工具等來釋放自己和團隊同學的生產力，千萬不要因為太忙而放棄思考和做這些事情，這樣只會欠下更多的技術債。當然這裡也有個誤區，並不是鼓勵大家造輪子，身為業務團隊的同學，儘量把眼光能放到行業或者集團內藉助現有的技術方案快速的定製來滿足自己的業務訴求，比如之前我們藉助舒文團隊的魔系列產品定製了海外自己的魔石模組來滿足海外營銷場景的需求開發，現在基本上大促類似坑位模組都得到了比較好的解決。

再者就是質量問題，需要抽空對線上經常出現問題的產品和程式碼進行梳理和方案的重新設計，在做國際時我一般是利用週末的時間來做這種事情，進行部分的重構來達到這種問題的徹底解決，避免三更半夜出現“連環奪命 call”。剩下的方式和手段就是增加開發環節質量保證和必要線上監控了。

關注上線效果 & 及時總結

有的時候我們認為專案提測上線後就完成了，這是一個不好的習慣，長此以往自己也就在合作方當中淪落為一個專案資源的角色，處於被動的狀態。其實仔細分析下上線之後的業務資料和效果 & 分析總結，有如下好處：

提高自己對業務的理解能力，你在關注業務資料的同時，也就會更多地從業務的角度來看到這個功能所帶來的價值是否符合預期，當出現不符合預期的時候，可以和業務方一起進行資料漏斗的分析從而找到問題所在，避免我們的勞動成果成為一次性的工作；總結的同時可以幫助自己梳理這個專案中自己哪些地方做的不足，或者相關推進中存在什麼問題，以及後面怎麼改進，提高了下次專案中的迭代效率和質量。比如這個專案是否存在需求理解不到位存在返工，或者溝通 & 聯調低效，環境不穩定，自己設計的方案是否合理等問題，後續要怎麼解決；也可以從資料和總結中判斷出什麼樣的需求是靠譜的 & 什麼的樣業務方是靠譜的，頻繁爭取資源上線效果又不好的業務方，下次再有需求過來則需要多增加一個心眼和思考的過程。

小結

以上就是我在應對業務需求井噴所總結的一些經驗，總體來說就是雖然業務佔據我們大部分的 KPI，但不能在業務中迷失了自己，需要給自己安排總結和反思的時間，做到主動掌握節奏的支撐業務。

階段二：四顧茫然謀發展

當然做到主動掌握節奏支撐業務還是不夠的，如何讓自己在做業務的同時能獲得更好的沉澱和成長呢？下面說說我經歷的第二個階段，我把它稱為四顧茫然謀發展。這個階段你會發現你雖然能較好地支撐了業務和有一定的時間來思考了，但是作為業務前端有個困境就是似乎不知道往哪些方向來發力來提升自己，特別是在每次制定規劃和寫 KPI 時，總會出現除了業務不知道該做啥的困境。在我看來身處在業務團隊的前端可以試著從兩個角度去探索和思考。

業務賦能角度

業務賦能其實是需要我們緊貼業務規劃，制定技術規劃和方案。這裡建議從財年開始後就需要陸續和老闆，以及自己對口的業務 PD 去聊，找一些線索和輸入，瞭解業務方今年的 KPI 重點是什麼，預計的拆解和實現路徑是什麼？再結合自己的和團隊情況，想想自己能做哪些事情來幫助業務實現其 KPI，其實這並非是一個簡單的事情，我自己也在慢慢的鍛鍊和訓練的自己，目前有兩點感受可以談下：

1.抓住本質從點及面，通盤考慮

很多時候，我們收到的痛點和業務需求都是單點的，這時我們不能著眼於眼前的單點問題，而需要通盤來考慮，比如 SEO 的頁面對效能非常敏感，經常會收到一些業務方來反饋，說目前我們的 SEO 有這個地方，那個地方需要最佳化下，而單點解決這些問題可能對業務帶來的收益並不大，對自己的技能也沒有什麼成長。這時候如果通盤考慮這個命題，其實會發現做 SEO 頁面的最佳化，其實目的是為了提升 SEO 頁面的收錄和排名。提升 SEO 頁面的收錄和排名不僅有前端效能最佳化這一個路徑，還有一些其他的路徑：比如最佳化關鍵詞&長尾詞，採用 Google 的 AMP 技術改造 SEO 頁面，最佳化爬蟲爬取頁面的耗時，提升爬取率等等。這樣就能把點的問題轉化為面的問題，才能制定更有效和全面的抓手來賦能業務。

2.既要解決眼前痛點，也要長遠謀劃

很多時候我們不能僅滿足於眼前的 KPI，還需要了解業務方長遠的想法和可以預見的規劃。比如我們目前正在做一個集團非常重要的專案，這個專案時間非常緊張（前端需要 300 多個人日, 且只有 48 個工作日，一度成為專案的風險點），業務和技術的第一要務就是按時上線。這時如果按著常理，規劃的目標肯定圍繞著如何按時上線的事情，而可以預見的未來，可能還需要基於這個模式落地到其他的站點，所以這裡在規劃和需要做的事情又增加了：如何做到技術方案的可以複製性？未來能新開站點如何做到縮短前端人力的問題？如何幫助業務做到海外站點快速規模化？這就是第二個維度的事情了，而當我把這個專案中所有可能的、近的問題和遠的問題都挖掘一遍，那我們要做的事情其實就是海外分站前端整體解決方案。 這就需要我們不斷挖掘問題和定義問題，然後再找到對策，才能找到更好的的賦能業務抓手。

技術體驗角度

技術體驗角度相對前端同學來說比較熟悉，而身在業務團隊，前端這塊也可以做比較多的事情，比如研發效能的提升，效能體驗最佳化，新技術試點和落地，與端的融合等等。如果想重點投入在這方向裡面有幾個點我覺得是需要重點關注的：

1.避免重複造輪子

當你需要制定一個產品化的方案或者工具和框架的時候，最好先放眼集團內部和行業，進行一番調研，看看業界和其他同事是怎麼解決這個問題的。儘量站在別人的肩膀上做出創新或者參與共建，避免小團隊內造出重複和質量低的輪子，這裡建議可以多關注集團前端委員會的規劃和動態，多關注集團內外的分享，當發現有感興趣和共同有需要面對的問題和場景時，參與共建和共享。

2.方案的深度和廣度

這個比較好理解，就拿前端的效能最佳化來說，目前我們已經不怎麼談資源壓縮、combo 請求之類常規操作了，而是進入了和客戶端深入結合的深水區進行最佳化(深度)，如之前天貓的 Webbased 方案，而之前我在做海外效能最佳化 Global Lite 方案的時候也是從全鏈路的角度來規劃和思考的(廣度)。所以規劃方案的深度和廣度，決定了這個方案的收益面，而提升深度和廣度的方向或者說技巧我覺得可以是：

一是多跨出一步，以上下游和合作方的角色來思考，和其他團隊&角色深度合作，探討可能的方案；二是以終局的思維來思考，比如這個事情最後應該是要做成什麼樣的，然後和現實做 match 考慮落地方案。

3.關注方案的 ROI

這裡其實涉及到你規劃的方案，完整實施下來的成本和收益問題，這個會最終衡量你做這個事情或者方向的價值。那如何衡量成本和收益呢？成本可以考慮從兩個角度來說：一個是平時我們理解的成本, 比如投入了多少人日，花費了多少經費等，還可以從另一個經濟學的機會成本來考慮，即放棄了的最大代價。收益其實比如提高了多少人效，提升了多少業務資料，提升了多少效能等，建議採用對比的方式來凸顯。

4.引進來&走出去

引進來的意思是儘量基於現有的方案和能力來進一步創新或者定製，走出去其實是將成果和方案能反哺出去，比如將方案覆蓋到集團其他行業和 BU，解決類似場景的問題，或者開源，申請專利 & 多參與集團內外的分享交流等等。

小結

關於思考業務賦能和做技術規劃，其實是一個非常值得不斷探討&鍛鍊過程，建議平時多和老闆 & 團隊內高 P 溝通和交流，一般他們會比較有經驗，可以在思考的深度和格局給出非常多的建議，有的時候這種交流會有一種醍醐灌頂的感覺。

階段三：千錘百煉修體系

有的時候當我們找到一個覺得可以深耕的方向 & 機會的時候，腦子裡面也許就已經有了大致的思路和方案，這時候可能會迫不及待的就想要開工，陷入了各種技術方案的細節之中，這樣的壞處在於可能會導致我們做著做著偏離了主航道，導致最後的產出不理想。這裡我們需要有一套理論和方法來保證對問題理解是準確的，完整的 & 足夠高度的。這個塊有沒有方法和套路呢，答案是：有！那就是養成結構化思考和做事方式。

結構化的思維

1.建立核心目標

當我們在面對一個問題和挑戰(挑戰即機會)的時候，需要明確我們做這個事情的核心目標是什麼，建立問題的核心目標。舉個簡單的列子，比如在開發中遇到了專案編譯慢的問題, 目標可以定義為解決專案編譯問題，但是我們也可以昇華一層為提升整個開發流程的效能，這時的核心目標就是對整個開發流程進行提效。進一步昇華的目的是為了提升整個事情的價值和解決問題的覆蓋面。

2.進行目標拆解

這裡可以根據不同的場景選擇不同的邏輯順序(時間/結構/程度)來進行拆解，比如開發提效這個目標我們就可以按開發的時間順序來進行拆解，比如: 本地開發 & 除錯 -> 聯調 -> 預發驗證 -> 釋出上線等。這裡面需要關注的點就是需要做到拆解的完備和獨立，拆解出來的子項能夠做到相互獨立和完整。

時間順序：中心執行的步驟、流程等；結構順序：中心的空間、地理位置、內部外部條件等；程度順序：中心的輕重緩急、重要性等。

3.子項的清理

事業是無限的，人力總是有窮、認知高度總是不夠（from 承風），所以這裡需要做到取捨並不是所有的子項都是值得在現階段做或者需要花費較大成本去做的。需要抓住其中的核心子項，也就是核心抓手。

小結

這裡我建議大家可以直接閱讀下《金字塔原理》一書（我自己也在學習中）和一些職業發展的其他書籍，補充自己除了技術方面之外一些思考和專案管理&人際溝通等方面的知識，當然書和文章都是理論知識，還是需要在工作當中千錘百煉的去修煉這種思考和做事的方式，才能體現出它的價值。這塊我目前也在不斷的在工作中嘗試，等後續如果有較多的體會和經驗再來分享。

最後

以上就是我在這幾年摸爬滾打出的一些經驗，藉此機會也在這裡感謝下我的老闆和幫助過我的朋友，你們一直都是我學習和參考的榜樣。