在「Google在手，答案都有的」情況下，軟體行業研發人員的技術和經驗價值體現在什麼地方？

01-01

大部分的普通軟體開發和測試碰到問題的時候一般都能通過Google, stackoverflow的工具查找到相關的解決方案, 那麼這時候資深員工的技術和經驗優勢體現在什麼地方?

資深的工程師更知道該用什麼關鍵詞去搜索，更知道哪個搜索結果是有幫助的。

1，菜鳥可能所有問題都要查，大牛並不是。所以大牛效率更高。

2，遇到問題大牛知道該怎麼查，關鍵詞什麼的，而菜鳥不一定知道。你看看知乎上有多少問題是百度/Google就能直接解決的~

3，同樣的信息，大牛的理解速度和篩選能力比菜鳥強。你真以為把example給一個菜鳥他就能照本宣科的做嗎？

4，具體的問題可以通過Google搜索，但是宏觀的問題呢？比如我想開發一個程序，應該怎麼設計架構？這時候就需要經驗了。

總之，大牛+Google=神；菜鳥+Google=菜鳥。對於菜鳥而已，知乎的實用性遠大於Google。

首先你要問正確的問題，即正確的搜索關鍵字。愛因斯坦不是說提出一個有價值的問題比解決它更重要麼。

你去隨便找個語言的板塊，然後看看有哪些問題，就會明白，有些問題你把原理方案都告訴別人，還是有人不理解；而有的人查都不用查就知道怎麼解決並且知道原因和有效方案途徑以及如何避免。

這就是差別，卡住個新手幾天甚至幾個月的問題對於精通的人而言哪怕是第一次遇到都能想明白。就算想不明白，人家google的速度也比較快……

資深員工的優勢在於搜到後能看得懂。不信你去看Linux源代碼～

一個普通程序員跟著一個資深程序員，兩年後，公司有了兩個資深程序員。

兩個普通程序員在一起，兩年後，還是兩個普通程序員。

優秀的人不止自己優秀，還應該能帶動身邊的人一起往前走:)

有問題總能搜到答案，可是你要是連問題在哪兒都不知道呢？
就是前面回答說的，問題真的都有答案？我所在的公司在某一公用框架上搭建起了非常複雜的應用程序，在多年的使用中對框架做了大量的拓展和修補，可以說我們的應用水平遠超絕大部分在線論壇或問答網站的討論。所以如果我們現在遇到框架性的問題，基本上都只能靠內部的資深人員去想辦法解決，放狗能找到的概率是很低的。
然後，相反的情況，同一個問題有多個解答，涉及到比較複雜的背景知識，缺乏經驗的新手只能挨個兒試。
除了通用知識之外，每個公司又都有自己特有的業務流程和內部框架。
此外，還有一些是方法論上的東西，大到如何管理時間，如何制定優先順序，如何與同事相處，如何獲取所需要的資源，小到如何快速定位Bug，如何保證提交質量，這些你可能可以在網上找到一些建議，但最終如何應用還得靠自己慢慢摸索。

當然是數學水平

大部分的普通軟體開發和測試碰到問題的時候一般都能通過Google, stackoverflow的工具查找到相關的解決方案

問題就出在這句話上。

Debugging遇到的各種情況，不穩定重現，多線程問題，性能問題，編碼問題，等等等等，都不是簡簡單單一搜索就有答案的。很多問題都是獨一無二的，網上基本不可能有一樣的問題和答案。
即使網上有答案，你也要知道用什麼關鍵字能迅速找到它們。
看到答案之後，得有能力把它正確和快速地應用到自己的問題上。

那麼這時候資深員工的技術和經驗優勢體現在什麼地方?

以上3點。

那是不是有本康熙大辭典，就能寫文章寫的花團錦簇了？

同樣是複製粘貼前人的代碼，為何有的人能找到高重合的可用代碼改改就好，有的人卻找不到？？

同樣是使用框架，庫，為何有的人知道用某個庫更能解決問題，有的人卻選了一個很差的方案？

開卷考試考試簡單吧，知識點單一，解題模式固定，那也不是人人都能考一百分的，一道綜合題就能拉開高手和菜鳥的差距。

應試考試都尚且如此，更何況實踐性、系統性、開放性、複雜性更強的軟體開發，你都不知道該翻哪本書，該提什麼問題！

資深開發者面臨的問題在於解決方案太多而不是去哪找解決方案。順便群嘲一下，樓上那波人自信過頭了吧，這題是外行和學生能答的？

題主你知道嗎，給足夠的時間和一台打字機，猴子也可以寫出莎士比亞全集的。

可是有什麼用呢？

傻孩子，世界上所有知識都是前人創造了，看你是不是知道，怎麼使用而已。

軟體開發也一樣，你能知道更多知識，閱讀更多文章，你就懂得該怎麼解決問題，使用什麼技術來實現。

資深的搜索收斂很快，普通的收斂慢，甚至搜索詞都要問人尋求幫助～至於那些不能勝任的，基本搜索不能收斂，是發散的，最後自己放棄。

資深和普通的區別就在於能夠分清什麼叫做相關，有多相關。就跟有些人連父母和老婆誰關係更近都分不清～

之前老闆讓我帶本科生科研，然而我這個人很懶，也不喜歡指導別人，於是看完小朋友的設想之後給他畫了個結構，然後給他列了一個表告訴他看完這些演算法，找到實現or自己實現，最後就可以裝成他的本研的第一步了。

小朋友開心地去做完了這些東西，在和別的少年吃飯的時候表露出來我並沒有幫助他寫任何代碼，他一個人完全可以搞定。

然後該少年轉述給我，而我這個人又比較小心眼，之後我表示科研不是這麼做的，理論上你首先應該自己調研相關演算法，然後設計出我之前告訴你的那樣的結構。小朋友在調研上至少花了1個月。

之前在實習的時候每天工作就是mentor叫我寫個腳本，實現一個功能，然後我就開心地寫完，甚至我一周做的單比老員工還多，功能也不見得比他們的單要簡單。然而我知道這不是因為我牛逼，而是有個年薪小一百萬的senior在幫我把一個大的項目劃分成各個小模塊，我只要擰螺絲就好了。

拋去架構能力不論，各位經驗尚淺的程序員可以回憶一下，有哪幾次你們能正確估算一個小項目的完成時間的？每每想到這個我覺得才是讓我覺得自己真是鳥都不會啊。

當然如果刨除這些，單論寫個快排腳本這種事的話，那我只能說擰螺絲要毛的經驗和積累。

google上很難搜到一個完美並符合你需求的模塊，所以你只能修改，而修改就可能破壞好的設計。雖然好的設計標準就在那裡，但普通程序員跟資深做出來的絕對是兩種東西。資深是趟了無數坑，重構過無數次才理解的那些標準。

網上泡女攻略那麼多，然而我並沒有女朋友_(:3」∠)_

1.高票答案里說的，問題關鍵詞提取的準確度，會直接影響到搜索的準確度；

2.同類問題的再次遇到，如果上一次只是依葫蘆畫瓢壓根沒懂出錯原理，第二次仍然只能再看人家教程，遇到n次也是如此，永遠都像是新問題；

3.遇到有一點小差異的問題無法把人家的教程改進成自己需要的解決方案；

4.遇到完全沒有發生過的問題...就只能祝好了。

ps：debug我覺得最靠譜的方法是看出錯提示定位錯誤位置和分析出錯原因，只有你真的看不懂出錯提示（即你對出錯提示的那部分知識真的很匱乏）的情況下搜前人的解決方案，這樣結合才比較高效。