代碼寫多了，感覺自己只是API搬運工，怎麼辦？

12-30

在大學呆了快3年了，還沒進大學就開始自己做感興趣的項目。從大學前的vb做桌面應用，以及用actionscript做flash遊戲，後來學習java，很快迷上了給自己手機做一些實用的android應用。我獨自完成過數個上千行代碼的項目，相信代碼量可以應付搬磚式的工作了。
可能我天生喜歡動手實踐，學習計算機的動力多數來源於可以通過代碼做自己喜歡的東西。然而，代碼寫多了，我逐漸陷入了「看API——寫代碼——看API——寫代碼」的怪圈，也感覺自己做的東西沒有任何技術含量，去培訓機構培訓幾個月出來就能完成，何況我在一本院校呆了三年啊。
我只想知道，如果在大型互聯網或軟體企業做技術要求高的工作，什麼才是最重要的呢？演算法、數據結構、操作系統這些是不是一定要學得很深入？

沒事，你這個階段我以前也遇到過，解決辦法如下：

1、確實多看演算法書，多練習

2、數據結構、操作系統，能多讀幾遍就幾遍，這些基礎以後會讓你面試大有墨水

3、繼續多寫代碼，寫寫寫，多思考，很多人連API都不會

在大學呆了快3年了，還沒進大學就開始自己做感興趣的項目。從大學前的vb做桌面應用，以及用actionscript做flash遊戲，後來學習java，很快迷上了給自己手機做一些實用的android應用。我獨自完成過數個上千行代碼的項目，相信代碼量可以應付搬磚式的工作了。

你的愛好很廣泛，我讀書的時候也跟你差不多。但是從代碼量上來說你的量還不夠大。

你做的就是一個工具或者一個小應用層級的代碼。

可能我天生喜歡動手實踐，學習計算機的動力多數來源於可以通過代碼做自己喜歡的東西。然而，代碼寫多了，我逐漸陷入了「看API——寫代碼——看API——寫代碼」的怪圈，也感覺自己做的東西沒有任何技術含量，去培訓機構培訓幾個月出來就能完成，何況我在一本院校呆了三年啊。

怪圈是因為你沒有深入一個技術體系去做，只是單純的在不同的平台上重複同樣的勞動。

打個比方就是你學了畫一朵花，你就反覆不斷的用鉛筆，鋼筆，圓珠筆，毛筆去畫同樣的一幅畫。

也許有了一定的各種不同筆的觸感差別體驗，沒有去真正去提高畫畫質量。

演算法、數據結構、操作系統這些是不是一定要學得很深入？

大多數普通碼農其實不需要很深入，但是水平好的人數據結構、操作系統一定是要深入的。

因為碼農是實現細節的職業，如果沒有這些知識，最後遇到坑的時候沒能力爬上來。

我只想知道，如果在大型互聯網或軟體企業做技術要求高的工作，什麼才是最重要的呢？

代碼組織能力

這個能力非常重要也很容易學習，幾乎人人都能獲得的能力，不需要天分。

只要寫過足夠複雜的代碼，再看看設計和模式相關的書籍就能獲得。

如何命名，如何設計介面，如何封裝API，如何分層，如何合理的使用設計模式

（其實不是故意使用而是代碼演變自然發生的）等。

體系結構知識

很多複雜的軟體使用到的技術是混搭的，每個技術如何選擇成功的搭配需要有體系性的概念。

這個的話同一個體系的技術體系做大了後，基本上都能接觸到。

比如微軟係為了滿足企業應用提供的一系列技術：

操作系統WIN32，桌面技術，WEB，資料庫，分散式事務，事件匯流排等等這是什麼技術。

各個層的技術細節

這方面就需要基本功，也就是演算法、數據結構了。

很多大型的應用基本核心可能就是圍繞一個核心演算法和數據結構。

但是為了做到高性能高可用或者易用性等，就需要寫很多外圍代碼來保證。

我們常用的框架或者類庫都是基本功的集合。

上千行的項目寫膩了？那就寫幾個上萬行的項目唄。

其實你感覺挺對的，很多碼農工作就是挖坑填坑式的重複性工作，技術含量說有也有說沒有也沒有。計算機還是個很年輕的行業，寫代碼大部分仍然是手工勞動，並且效率非常低下。

演算法和數據結構其實常用的就那麼幾種。其他的沒有特定的問題一般也用不上。知道總是好的，至少面試常會考。具體有多少用不一定。看需求。

3000行以下的項目基本談不上系統架構。所以，寫點大一點的項目吧，那種想想讓自己都怕的項目（比如自己從頭寫個編譯器？寫個操作系統？寫個pdf渲染器？寫個html渲染器？）。從頭寫，別用別人的庫。一開始肯定寫不完，多半會半途而廢的，但是結果其實不重要。重要的是嘗試之後就會看到寫比較大規模的項目時具體有什麼困境，會遇到什麼技術問題。這方面看書用處不大的，軟體工程的研究現狀和中醫差不多，很多說法都是經驗之談而非常不靠譜，完全沒科學驗證過。牛人要麼是誤打誤撞自學成才要麼是其他牛人手把手帶的徒弟。

再就是怎麼與人交流，怎麼把一個問題說清楚，怎麼指出其他人負責的問題而不冒犯別人，怎麼組織朋友一起做一個上萬行的項目。非常有技術含量的本事。計算機業凡是掙錢掙得比你多幾倍的，除了運氣之外，恐怕最大的技術差距就在這兒了。而且可悲的是，欲提高此技術，同樣看書用處不大，研究現狀和中醫差不多，很多說法都是經驗之談而非常不靠譜，完全沒科學驗證過。牛人要麼是誤打誤撞自學成才要麼是其他牛人手把手帶的徒弟。

總之，找三五個朋友，哪怕用業餘時間一起嘗試做一個至少一萬行的項目，各種問題就全暴露了。希望到時候您還沒有氣餒，還能到知乎上來，並問一些更具體的問題。

多想多學多做啊，多去想些上下游的東西，多學些相關的東西，包括表結構，流程，業務邏輯，外圍對接，介面規範啥的，總之自己這一碗吃膩了，就到別的碗里鍋里多撈撈，不然有一天：

你就真的只能做搬運工了……

負責任的說，學校把數據結構/演算法基礎紮實了，就算贏家了(怎麼樣算紮實？Google筆試能得90分以上）。。架構方面要接觸實際系統才有感，不可貪多

你有這種感覺極其正常。編程早期，善於思索和觀察的，稍微用腦筋思考一下自己的工作，很容易得出這個結論的：因為其實的確如此。我也經歷過，而且到現在還一直在和這種狀態做鬥爭，以下為本人實際經歷的一些階段：

1 這個demo似乎沒能實現xxx功能（如換膚，動畫效果等），我能不能實現了讓它更完美看上去更高大上呢，怎麼實現呢？——給自己找課題，開放學習（其實還在學API，不過沒這麼枯燥了）。

2 API不僅要會搬，還要廣搬。桌面，web（前端，後端），移動端都搬過啦？其他的第三方有沒有搬過，他們之間相有何優缺點？——API是用來解決問題的，懂（還不是精）得越多，解決問題的時候思路就會越多。能幫老闆解決問題的人，就是好程序員——哪怕你寫的只是一個簡單的Excel插件。

3 如何保證自己「搬」來的代碼多了，以後出問題了調試或者二次開發，會不會不把人累半死呢，為什麼高手們要這樣設計類設計介面，有什麼講究呢——這涉及到一般代碼風格或者結構問題，由此引導自己學習設計模式或架構方面的。結合新的理念重構之前的東東時，你會重新理解繼承，抽象，介面，重載，封裝，強類型弱類型，配置文件等，從心底認可他們的科學性甚至藝術性。

4 搬API很簡單？遠遠不簡單！如何短時間內找到並評估一個沒用過的框架是不是能用於自己的情況，如何短時間內領悟他的精髓，如何保證3-5年前搬過的API現在還整齊的碼在自己的內存里，搬的過程中你有猜過他們怎麼實現對自己有什麼啟示么？

5 萬一哪天沒有現成API可以搬，怎麼辦（一些企業對於使用第三方限制極其嚴格），你能自己寫嗎？——來，自己用vb寫一個計算器算一下（4+2-3*5）/8看看，spring怎麼實現IOC的，我可不可以自己識別圖片上的文字呢，自己能寫類似vs的圖形編輯界面么，搶票軟體什麼個原理？

6 API並不是解決問題提高生產力的唯一途徑。xxx插件用得咋樣，會自己搭xxx環境不，自己寫過的代碼或者包怎麼積澱，如果讓代碼生成工具幫你生成大部分有規律的重複代碼，資料庫，硬體。。。

7 對於xxx行業，或xxx類型的問題，我有一套成熟的解決方案或框架了么，我能利用之前的積澱在短時間做出一個穩健的系統么？

--------------------------------------------------------------------------------------------------------

世界各行業都要處理問題，都使用工具。API和IDE就是我們的工具，我們必須用好，用熟。看得出你是一個對自己有要求的人：耐心點，慢慢來吧，讓編程變得更有創造性和藝術感，成就感。

誰都在造輪子，每個人負責自己的輪子。別人何嘗不是搬運你的API呢。

取決於你的目的是學習技術還是在大公司里謀個好工作。即使是一線公司，除了個別職位外，大部分碼農都是API搬運工，只不過有些API設計的比較操蛋難用而已。

所以，知道招聘單位為何回在招聘要求上寫「一個完整的項目開發經驗」了吧？

會用Api是寫一個軟體的開始，但是還遠遠不到寫完一個軟體。

lz加油，都會經歷這麼個階段的。