一樣都是開發，爲何你不如別人？

時間 2020-05-30

標籤一樣都是開發爲何不如別人简体版

原文原文鏈接

2020年因爲疫情的影響，大批量的公司破產倒閉，即便能堅持下來的，也是推出了不少財務削減和人員裁減計劃（也有美名爲人員優化），這致使了大量人員的失業，當讓也包括了咱們這些作開發的程序猿。java

疫情時間，爲了能快速找到工做，不少人又開始四處尋找面試材料複習開始備戰面試，但就在複習的過程當中有些人可能會發現，原來本身工做了這麼多年，水平可能都不及一個擁有三年開發經驗的新人。git

那麼問題來了，一樣是開發，爲何你不如別人？如何才能讓本身變得更加優秀？下面我將從三個方面闡述個人思考。github

1.作事的藝術

在工做中，咱們可能會碰到各類各樣的問題，如何優雅地處理這些事情，很是考驗一我的的能力。面試

嚴謹和一絲不苟的態度

有人常常這樣向我抱怨：面試造火箭大炮，工做擰螺絲。我想即使你是擰螺絲的工做，也務必要保持一絲不苟的態度把這擰螺絲的工做作好，不然你的這步沒能擰好，頗有可能致使造出來的整個火箭還沒飛上天就爆炸了。segmentfault

我以爲幹我們研發這一行，嚴謹和一絲不苟的態度是必須具有的基本職業素養。由於可能就是你的一點小疏忽或者狀況考慮不周，可能給別人帶來多大的麻煩和後果。設計模式

可能1、兩次地這樣坑別人，別人還能原諒你，幫你填坑。但若是因爲你的不嚴謹和不認真的態度，致使三番五次地坑別人，時間長了即使你人再好，別人也不會再相信你，這樣你在團隊中就舉步維艱了。微信

把握問題的本質

在工做的時候，咱們常常會遇到各類各樣的奇怪的bug。面對這些bug，不一樣的人處理的方式也是不盡相同。有的人是恨得咬牙切齒，巴不得和提bug的人幹一架；有的人則是很是淡定，一邊詢問bug的詳細狀況，一邊靜靜地坐着打斷點、打日誌分析問題。二者處理的方式不一樣，帶來的結果也不盡相同。架構

那麼當咱們在開發過程當中遇到問題時，咱們該如何解決呢？我想核心的解決方法就是把握問題的本質。工具

如何把握問題的本質，如下是我經常使用的方法論供你們參考：性能

1.瞭解問題的詳細狀況，收集問題出現的條件和現象：只有瞭解問題才能解決問題。
2.模擬問題出現的場景，對問題進行場景復現。
3.將偶現問題轉化爲必現問題，從中尋找規律。
4.善用排除法，篩除干擾項。
5.斷點+日誌相結合進行問題跟蹤，深刻源碼探尋問題的本質。

一旦把握了問題的本質以後，一切便會迎刃而解。後面你須要作的就是找到方法，並解決它。你能夠本身想辦法；搜索網上有沒有人和你遇到一樣的問題；請教這方面熟悉的人...

事前永遠比過後更重要

事前埋下的坑，也許須要過後付出數倍的努力才能把坑填完。不少時候咱們常常會忽視事前計劃、設計的重要性，每每是走一步看一步，等功能實現到一半的時候才忽然發現這條路越走越崎嶇或者根本行不通，這個時候你是很是難受的：繼續走下去，可能前面的坑會愈來愈多；不繼續走，從新想方案，項目延期，進度趕不上，要被問責。

所以在作任何事前以前，必定要本身要作的事情想清楚了再去作，避免南轅北轍的尷尬。

如下是我給出的幾點建議：

1.在作一些較爲複雜的功能前，儘可能作好設計。這裏的設計主要包括：
- 流程圖：把全部可能出現的狀況都考慮進去，越詳細越好。
- 設計類圖：包括UML圖和時序圖等。好的設計望望事半功倍，這裏我推薦你們多學學設計模式
- 性能設計和可拓展設計。
2.養成良好的編碼規範，在關鍵的、難懂的地方多加些註釋，這樣能夠避免長時間後的遺忘，致使代碼晦澀難懂，大大增長維護難道和bug產生的概率。
3.提升代碼的質量，在實現功能的同時，注重代碼的性能，對於一些常見的性能問題要爛熟於心。
4.在問題出現任何端倪以前就立馬進行解決，即便不能徹底解決也要預先想出替代方案。不然時間長了或者上線了以後，你可能須要付出數倍的精力才能解決，並有可能帶來很是很差的影響。

低調作人高調作事

Talk is cheap. Show me the code.這句話可謂是IT圈裏最朗朗上口的一句話。

我們幹研發這一行的不一樣於其餘職業，並不須要極力向外推銷本身來獲取更高的業績。咱們絕大多數的研發人員都是務實派，靠的是一行一行碼出來的代碼去實現本身的價值，少說話多敲幾行代碼會更有價值得多。

因此，那些整天誇誇其談，開口就是講上一堆技術架構，閉口寫起代碼又是一團亂麻的人，是比較不受歡迎的。

咱們作技術的不要整天拿着技術出來顯擺。要知道人外有人天外有天，比你技術牛逼的大有人在，不必成天要在技術上比個高低貴賤的，也不須要刻意讓別人知道本身有多麼厲害，由於你寫的代碼就能證實你的技術水平，時間一長你們天然心知肚明。

幫助別人的藝術

在幫助別人的同時，還能讓本身對這塊的技術掌握得更加透徹，何樂而不爲呢？

幫助別人，而不是施捨，這一點尤其重要。咱們要樂於助人，可是也要注重方法。幫助他人是創建在相互尊重的基礎上的，不然你的好心幫助會被別人理解爲同情施捨或者多管閒事。

所以咱們在幫助別人的時候要注意如下幾點：

不要有幫助人的企圖，只有在別人須要幫助的時候纔去伸出援助之手。
給予被幫助人最起碼的的尊重。
不要藉着幫助他人的名義去幹預被幫助人的成長，最好的幫助就是點到即止，剩下的順其天然。

2.學習的藝術

從事開發工做，不管你是在產品線上寫業務代碼，仍是在技術平臺進行技術研究，咱們都不能放棄學習，放棄對新技術的嘗試。放棄學習就比如戰士上戰場弄丟了本身的槍，很快你將會被一浪又一浪的技術浪潮所淘汰。

學習和汲取他人的長處

對於大多數的人來講，發現別人的缺點很容易，可是發現別人的優勢卻很難，這也是不少人不能快速成長的緣由所在。

優秀的人老是善於發現別人的優勢並加以學習。學習、模仿並最終超越是他們望風披靡的祕訣。他們並不在於你身上有多少缺點，他們只在意能從你身上學到多少東西。

他們不只會向身邊的人學習，還會向如下幾個方面進行學習：

優秀的源碼。這裏包括系統源碼和優秀的開源項目源碼。
優秀的技術書籍、文章。
優秀的理念和思想。

把握學習的廣度和深度

漫無目的地學習必然致使效率的極其低下，咱們在學習以前必定要給本身設定一個目標：究竟是想學習不一樣領域額的技能，成爲一名全才；仍是想就某一領域深刻研究，成爲一名專才，這就涉及到學習的廣度和深度的選擇了。

由於你不一樣的選擇可能致使不一樣的人生軌跡，就目前而言，大廠更偏向於某一領域的專才，而小廠更偏向於擁有更多技能的全才，固然這也不是那麼絕對。就選擇而言，大廠當然很好，可是又有多少人能進入大廠呢；小廠雖然說待遇各方面都不敵大廠，可是小廠的機遇多啊，說不定哪天公司發展得不錯，你就能爬上領導的位置了呢。

因此不管你是選擇學習的廣度仍是學習的深度，其實都是沒有錯的，惟一錯的就是你壓根就沒有思考過這事。

固然這裏的選擇也不是絕對的，每一個人在不一樣的階段可能選擇的方向並不相同。當你初涉社會剛開始工做，你可能追求的是學習的廣度，但慢慢的當你對某一領域感興趣或者表現出異於常人的天賦時，你可能又會轉而追求學習的深度。

每一個人的技術都有可能在某一刻達到瓶頸。若是如今的你翻開一年前你提交的代碼，卻發現和你如今提交的代碼並沒有差異時，這個時候你就要當心了，極可能你已經達到你的技術瓶頸了，這個時候考慮換一個學習的緯度多是不錯的選擇。

持續不斷地學習

技術在突飛猛進地不斷變化和發展着，前幾年還比較流行的技術，可能沒過幾年就被人們所拋棄。當革命性的突破技術取代舊的技術時，這是歷史巨輪不斷向前發展、不可阻擋的趨勢。

不要覺得你如今掌握的技術就可以養活你一生，咱們須要對技術的發展保持着極大的敏銳觸覺。一旦你所掌握的技術逐漸被新技術所替代時，你就要當心了，可能留給你學習的時間很少了。

利用好學習的工具

利用好學習的工具，可以極大地提升咱們的學習效率。

這裏我主要介紹關於自學一門技術能夠利用的工具：

專業性的入門書籍。對於新手和小白而言，我仍是建議你們先找幾本專業性和權威性最強的書籍做爲本身的入門指南。由於書本講解得更詳細也更成體系，對於入門而言仍是至關不錯的。
專業領域較強的技術論壇和博客。在這裏咱們能夠學到不少書本上所沒有的一些前沿技術的資訊和技術交流心得。這裏推薦掘金和思否。
開源代碼託管平臺。在上面擁有海量開源的項目，其中也不乏許多優秀的開源項目能夠供咱們學習和參考。學習和借鑑別人優秀的代碼和設計思想，能讓咱們快速提升自個人coding能力。這裏我主要推薦Github和Gitee。關於如何使用開源代碼託管平臺，能夠參考我以前寫的一篇文章：《你真的會使用github嗎？》。

3.提問的藝術

咱們每一個人都不是萬能的，都會遇到不少咱們不懂的問題，須要向別人進行求助。可是並非每一個人的問題都可以獲得別人的答覆，這徹底取決於提問者提問的水平。

這裏我先模擬一個場景：當你在github上使用了某人開源的輪子時，遇到了問題須要向做者提問或者提issue，你會怎樣進行提問？

提問者A：大佬幫幫忙，我在使用xxx的使用遇到問題了，請問怎麼解決啊？
提問者B：老哥，我說xxx小白，在使用你的xxxx搞了一天了都沒有運行得起來，能不能幫幫忙，我實在沒辦法了。
提問者C：您好，大佬。我在使用xxxx時，頻繁xxxx，致使xxxx,可是xxxx, 又會xxxxx, 可是呢...(如下省略500字)。可能我形容地不是很清楚，你能夠試一下就知道了。
提問者D：請問怎麼解決，......（如下省略數百行的日誌）
提問者E：你這xxx根本不能用，......（如下省略約一百字的抱怨的話）
提問者F：您好，我在使用xxx的xxx版本的時候，遇到了xxx問題。下面是我出現問題時的現象（....)以及日誌(....)。我是這樣xxx,而後xxx,最後致使xxxx。我出現問題的設備型號是xxxx，在xxxx上沒有出現問題，是否是xxxxx致使的？

上面6我的提問的方式是徹底不一樣，我想可能只有提問者F纔可以最終獲得別人的答覆並順利解決問題，下面我將幫你逐一分析緣由：

提問者A是不少人常常犯的錯誤，那就是隻拋出了問題，並無給出問題出現的現象和依據，這會讓被提問者無從下手，沒有絲毫回覆的慾望。畢竟你是求別人幫你解決問題，而不是領導發號施令。
提問者B是不少初學者（學生）常犯的毛病，沒有明確的問題，沒有明確的解決預期，有的就是祈求式的求助，甚至連要幫什麼忙都沒有表述清楚。對於這種提問，絕大多數人是不予理睬的，由於他們並不想把時間浪費在一個什麼都不明白的菜鳥身上，畢竟他們不是你的老師，沒有義務教你基礎知識。
提問者C的問題就是說得太多，沒能精確描述問題是什麼。這樣表述不清的提問只會讓被提問者滿臉的問號，而後直接回復：？？？。
提問者D也是不少人常常犯的錯誤。出現問題以後的第一反應不是先去進行一番思考嘗試本身解決，而是無腦地將一堆無用的錯誤日誌貼出來，請求別人給出解決方案。對於這樣的問題，可能絕大多數人的第一反應就是：能百度解決問題的，請不要來煩我，謝謝！
提問者E就不用多說了，這種提問明顯不是衝着解決問題的目的來的。對於這種不友善，懷有敵意的提問，我想大部分人的反應不是去幫忙解決問題，而是在想：這人不會是傻*吧？

分析了上面人的提問方式後，咱們能夠總結出以下幾個問題時的技巧：

首先明確問題是什麼。
優先自我思考解決，解決不了再向別人尋求幫助。
清晰地描述問題。
問題解決及時反饋並表達謝意。

明確問題是什麼

在提問以前，首要任務是要搞明白本身到底要問什麼，訴求是什麼，這是對被提問者最起碼的尊重。

什麼都沒搞明白就稀裏糊塗地跑去問別人，這會讓別人以爲你很唐突無知，給人留下很是很差的印象，這也會直接致使別人不肯意幫助你解決問題。

爲何這麼說？由於別人要想幫你解決問題，還得先搞明白你的問題究竟是什麼，你的訴求是什麼，而後還須要幫你分析問題出現的緣由，最後才能幫你想出解決的辦法，這花費的精力和代價實在是太大了。要知道這不是在學校或者醫院，沒人會願意這麼大廢周折地幫你。

因此，要想本身的問題可以獲得別人的答覆和幫助，你必須想明白你要問的問題究竟是什麼！

優先自我思考解決

你可能也會遇到這樣的狀況，常常有人會在論壇上、qq羣裏、博客評論區裏，動不動就貼出數百行的報錯日誌，而後不加一點說明，開口就問：這是什麼問題，能幫我解決嗎？

像這樣不經大腦思考就草率的發問只能獲得草率的回答，或者根本得不到任何答案便會石沉大海。其實我特別不建議你們在QQ羣或者微信羣裏向別人問問題，由於懂的人可能不屑於回答（以爲這樣的問題太low了，即便回答對了也體現不出本身的厲害），不懂的人即使回覆你了也沒有任何價值，反而有可能會把你帶偏了。如今這社會，你們的時間都很寶貴，沒有哪一個真正厲害的技術大牛是在QQ羣和微信羣裏活躍的，大牛的時間都很寶貴。那些整天在QQ羣或者微信羣裏活躍的人，八成是閒的沒事幹的人。

所以要想獲得別人高質量的答覆，必須擁有與之相匹配的高質量的問題才行，這樣別人纔會願意幫你解決。因此並非什麼問題都是值得向別人提問的。

咱們在提問以前，必定要有本身的思考，優先嚐試本身解決問題。下面是我提供的幾個自我解決問題的途徑：

斷點+日誌相結合進行問題跟蹤，深刻源碼探尋問題的本質並予以解決。
仔細通讀做者編寫的使用手冊，不要拉下沒一個細節（切忌想固然），試着本身找答案。
在FAQ裏找答案。若是有開源地址的話，建議優先在Issue中查找是否有相關的問題，並借鑑其中的解決方法。
在網上搜索相關問題（條件容許的話，優先使用google，百度太坑，搜到的大多千篇一概）
向你身邊精於此道的朋友諮詢。

若是通過以上5種方法你都沒能解決問題，這個時候你再向別人進行提問，我相信你必定可以把問題解決。由於帶着思考向別人提問題，才更可以獲得別人高質量的答覆。若是能夠的話，你能夠直接把本身想的幾個解決方法闡述出來，這樣別人可能會更願意幫你解決，畢竟你們都喜歡作選擇題，而不是論述題。

清晰地描述問題

有這樣一部分人，每次遇到問題須要向別人求助的時候，常常表現的是舉足無措，慌張地描述了一大堆看上去和問題有關又或者無關的話，口若懸河滔滔不絕，問得被提問者一臉懵逼。

面對這樣的問題不免會讓別人頭大。講了一大堆卻分不出主次和主要矛盾，就連問題是什麼都沒有搞得很明白，別人怎麼幫你解決？

所以咱們在闡述問題的時候，須要注意如下幾點：

問題描述要言簡意賅，儘可能控制在50字之內。
問題描述要條理清晰，把握主要矛盾。與問題無關或者相關性較低的話就不要說了。
建議問題中包括以下幾部分的內容：
- 問題描述
- 使用版本
- 如何重現
- 指望的效果
- 出錯現象（截圖或者視頻）
- 設備信息（環境）
- 附加信息（能夠是日誌或者源碼連接等）