也不會，只是向上的通道會少些。

不過，軟體設計行業很細粉，你要是專注鑽研業務程式碼（含熟悉業務需求），高效優質完成，也會得到肯定。

網際網路程式設計師都有個35歲的坎，如果你不懂原始碼、設計架構，你基本就很難上升到管理層，到時面對年輕人的競爭，你的劣勢就很明顯了。

首先，你跟年輕人比起來，接受新技術的能力就比較差，網際網路技術發展那麼迅速，想Go、python、js現在都基本成主流語言了，早兩年可能很多技術都看不上這些指令碼語言吧。

其次，年齡大了，家庭壓力就大，精力也不夠了。你怎麼可能還跟年輕人一樣加班加點的。

所以，有空多接觸些管理方面的吧，儘可能往上爬才是王道。

如果你只會寫增刪改查，卻仍堅持走技術路線，隨著年齡增長，被淘汰是必然。

我年輕的時候也曾對此焦慮過，當時我們一幫小菜鳥也上下求索，希望有條明路，卻無人指點。自己悟出一點道理，現在看來很幼稚，今天說說，也供參考吧。

當時覺得自己有兩條路，一條往下走，即技術路線，做技術大拿；一條往上走，即管理路線，當領導。

我選擇了“往上走”，開始學習專案管理知識，後來還考了軟考的“專案管理師”的證。我並不是為了要當領導才選擇“往上走”，是當時的眼界限定了自己，並不知道有哪些技術發展路線。當時公司也支援我，讓我帶專案嘗試。大約在三十歲左右時，已經基本不寫程式碼了。但我沒有丟掉技術，因為在一個技術團隊中，技術能力是能直接帶來威望的。

大約在我三十五歲左右時，想創業，畢竟專案經理這個位子太虛了，有太多不想寫程式碼的程式設計師想往這上面擠。公司也想給他們機會，即便給我一個專案部經理的位子（就是管理專案經理的）也很沒意義。創業後很快發現管理能力在創業初期沒有太大用，我要寫軟體，招人成本太高，自己寫能省人工成本。又開始了選擇“往下走”的道路，通過幾年的專案管理，思路更加開闊，以前看不懂的軟體架構，現在拿來看竟然都能看懂，能清楚理解人家框架為什麼這樣設計，針對業務模組的設計也更容易。我很慶幸自己，脫離了簡單重複的業務程式碼編寫，又沒有捨棄技術。脫離業務程式碼的編寫，讓我有精力去學習更多的技術，提升了視野；沒有捨棄技術，得以我仍然有能力獨立開發。

---

最後，說些我的心得。

隨著年齡增長，不要再拼強度，一定要拼高度。

如果只是長年寫業務程式碼，技術不精深，三十歲左右會大機率被淘汰；如果感覺技術上進步不大，就往管理崗位上走，可以混到三十五歲或四十歲；

再往後，還要在此行業發展，技術一定要過硬，程式設計思想、架構設計、產品設計、專案管控等等，各方面能力都要有，混到六十七十歲也是沒有問題的。

不會被淘汰，只是你為什麼不多學點其他方面的東西呢？

而且，只會寫業務程式碼，難道不會寫膩嗎？學點新鮮的東西，才會充滿動力。

只會寫業務層程式碼，公司不會淘汰你，因為你畢竟還是有一技之長的。但是我擔心，有一天你會把自己淘汰掉！看到那些後進公司的人懂得的技術都比你多，你受得了嗎？除非你就是一個無所求的人。

既然幹了技術這行，就好好學吧！下面這張圖與你共勉：

無論從事什麼職業都有個循序漸進的過程，就拿程式設計師這個職業來講，無論多厲害的大師也是從小白一點一滴走過來的，這本身是一件很平常的事情，絕大部分的程式設計師做的工作就是為了完成業務程式碼，也就是單元模組，真正去做架構設計的比例少的可憐，如果有機會參與到架構設計裡面那是一種幸運，絕大部分程式設計師一輩子都參與不了架構的設計，很多架構師在工作過程中由於基礎積累的還不錯，並且在公司中深得信任，於是公司決定讓他試一試，如果抓住這種機會出來的了，那就頂上去了，大部分的架構師開始不認為自己能勝任這個角色，挺過來也就過去了。

很多程式設計師在入行之初躊躇滿志，結果在遭遇一系列現實的打擊之後就會覺得能做個合格的程式設計師就不錯了，因為程式設計師的技能高低完全靠一點一滴的積累，積累到什麼程度技能就達到什麼程度，沒有所謂的訣竅，只不過有些人理解能力強一些，有些人屬於厚積薄發型別的，最終技術崗位靠的就是技術能力的積累，水到渠成順其自然。

題目中的NDK，架構設計完全不同的兩種概念，NDK屬於安卓下面能夠使用C/C++完成應用介面的一套工具集而已，和架構設計完全的兩碼事，因為很多應用有特殊的功能呼叫，就透過NDK的方式把C/C++和java之間用橋樑串聯起來，這種在應用級開發裡面還是很常見。而且這種程式碼的實現基本上上也屬於業務程式碼，很多人覺得寫業務程式碼的人水平都一般，如果能把普通的業務程式碼寫的高質量一樣能成為架構師，如果連普通的業務程式碼都玩不轉怎麼可能成為架構師。

架構師這個崗位需要經驗和能力雙重提升，不是技術能力強就能成為架構師，需要很深邃的程式設計思想支撐，能一針見血的指出常見問題的所在，同時不停的最佳化解決問題的思路，優秀的程式設計師從來都會覺得自己能寫出更棒的程式碼來，有一種程式設計師喜歡折騰，折騰實現方式，質疑架構思想等等，很多開源社群裡面優質的社群文化之一，就是重構不停的重構，從安卓和chrome程式碼實現上就可以看出端倪，這是一幫有著極強想法的程式設計師設計的模組程式碼，有時候還不容易下了原始碼看懂了一個模組實現，結果過了幾天再去更新程式碼發現之前看明白的程式碼已經被新的實現方式代替了，這就是程式碼的重構，優秀的程式設計師總是喜歡折騰。

業務程式碼是基礎，一切程式碼都是為了業務服務的。

工作的研究原始碼也是為了解決業務問題，架構設計也是為了提高業務程式碼開發效率，提高業務程式碼品質。

業務程式碼寫的時候認真點，可以從細微處抓住更實際問題。

普通的專案其實沒啥技術難度，架構失敗也看不出來。

有些很艱難的專案，就沒那麼簡單了。我2011年遇到一個專案，是個日本發來的活，規模很大，架構特別新，全套新技術，glashfish，官方版j2ee。日本找的設計師做的架構太理想。

這個專案真實施，發展生產效率太低，變成不可完成任務。技術上沒有人懂，所以沒辦法，只能硬磕，大量的業務開發實際是試錯，積累了大量的經驗，總結反推就找到正確的架構方案了。

專案也就活了。

看你在什麼型別的公司了。如果你在製造型公司，業務程式碼是對你業務能力最好的體現。如果你的業務能做到非常精通。熟悉整個公司業務，有能力梳理最佳化業務。做到顧問，你的工資也不會少，而且你的職業生涯很長。很多公司需要這樣的人。職業生涯比網際網路公司要更長。我們公司顧問在50w以上。做到退休了還被返聘了！部門是ERP！

做安卓的吧

你要是普通開發不需要用到，如果要開發影象處理，人臉識別等app，還是脫不掉的。至於架構，安卓裡面的架構相比java後端範圍小了很多。原始碼當然要看看，能學到很多設計思想和底層實現原理。學了會更有競爭力，不學的話也能開發，但是年紀一大就完蛋了。

關鍵是你做了多久了。

1年時間，你說你只會做業務程式碼沒啥。

10年了，連個架構設計都不會不淘汰你淘汰誰啊！

程式碼寫的好業務不一定處理的正確，對於使用者只要求速度快、美觀、易用、業務處理正確，其他的什麼語音什麼架構都不懂，所以只要能做到這幾點新老鳥只是開發效率的區別