下面逐一分析這三點:html
遇事追蹤溯源,不懼怕改已有的代碼程序員
新人一般會重新加一個類似的功能或者修bug開始逐步熟悉原有的系統,這時不管原有的代碼寫的怎麼樣,都應仔細的思考每段相關代碼的做用和對應的需求,努力作到追蹤溯源,掌握它們的前因後果,這時再作task就會遊刃有餘,在作類似功能時,你知道哪些地方已經實現能夠複用,哪些地方由於新加的代碼應該作些重構。面試
修bug時,你能夠從根本緣由出發,解決問題,而不是在出現問題的地方修修補補;更重要的是你不會打怵修改原有的代碼而躡手躡腳。固然一旦發現要修改大段的原有代碼或者設計,仍是要主動和老員工先確認下思路是否可行,是否有遺漏的地方再開始。但不出意外,你會一會兒就給別人留下一個好的第一印象,由於你沒有在機械的完成任務,而是先作了深刻思考。工具
寫到這裏不由想起,本身剛工做時改了一個bug,當時的作法是在建立一個文件的代碼以後3行再把這個文件刪了,只加了一行代碼就修好了,發給老員工review時還在竊喜本身只改一行代碼就解決問題了,結果老員工一句話就把我問傻了,前面的那個文件爲何要建立呀?我固然不知道了,由於當時我想原有的代碼我不熟悉就最好不動。因而,那一刻我獲得了工做生涯第一個重要的建議,應該找到根本緣由(root cause)後再修改代碼。這時你不只能夠作好手中的任務,還能進一步思考問題是否是代碼設計不合理形成的,同時不會怕改已有的代碼。單元測試
在保證編碼正確的前提下,要足夠快學習
新人在作第一個任務時都想留下好印象的,首先要作的就是必定要保證修改是正確的,這裏不只侷限於正常狀況下功能正確,還應考慮邊界條件,錯誤處理狀況等等,最後再提交代碼時要最終確認一下單元測試過不過,提交代碼後再注意下Jenkins bulid過不過。這一切都是爲了防止出現如下狀況:測試
別覺得這些都些小事,它直接關乎別人對你的評價。不犯低級錯誤,創建起嚴謹的印象,是很是有助於你在新環境下脫穎而出的。網站
試想一下,你持續超出別人的預期,並保質保量的完成了task,哪一個領導和同事會不喜歡你呢?千萬不要狹隘的以爲本身作的快了要多作事,何苦呀。也許短時間內你多作了一些本來沒分配給你的任務,但你在別人心中逐步創建起嚴謹高效的印象,從長期來看將給你帶來更多的機遇(本人就是所以受益)。ui
主動承接他人不肯意作的或者沒作的事編碼
逆向思考下,人家爲何招你進來?相信絕大多數狀況是事情多作不過來,缺人了。事情多了必定有老員工不肯意作,或者由於各類緣由沒作的事。做爲新人,作了別人不肯意作的事能夠緩和他人的壓力;作了別人沒作的事,將爲團隊增長產出,若是這件事仍是一個技術難題,那不是正好可讓別人眼前一亮,證實本身的實力嗎?
其實關於這一點,在作的時候要進一步深刻思考。別人爲何不肯意作或者沒作某些事?是由於缺少相關知識而沒有作?仍是由於沒有自動化每次手動操做既耗時又容易出錯?是由於優先級不高?仍是由於投入產出比不高?是由於代碼結構不合理致使沒法快速加上?仍是由於需求不明確?是否是團隊裏的人由於思惟定式錯誤估計了問題?是否是能夠從其餘的角度解決這個問題?要深刻思考後,才能從根源入手,從而正確的解決問題。切記不要機械的完成任務,要努力讓你的加入使團隊變的更好。
本身在第二份工做的開始階段,就發現團隊尚未使用持續集成的工具在統一的環境下交付測試,測試還在經過訪問開發機器上的網站驗證功能,結果開發之間互相break狀況常常發生,項目質量也沒法保證。詢問後才知道,你們也很但願改進現狀,只是由於一些緣由無法獲得系統組的支持,組內也沒人來搭建持續集成的環境。
因而我利用一開始相對輕鬆的時間,使用teamcity搭建出持續集成的環境,一時間你們都紛紛叫好,加上本身又接連解決了項目中一些棘手同時沒人作的問題,一會兒就樹立了可靠的形象和在團隊裏技術主力的地位,慢慢的即便是公司中其餘組沒合做的過的人也對我評價很高。我本身琢磨出的緣由是團隊裏缺能幹活的人,但更缺能讓團隊變好的人。
其實巧的是,如何使用teamcity搭建持續集成環境是我在第一份工做離職交接時主動作的最後一個task,由於當時有個小項目是我獨立負責的,我想在交接時讓項目更正規些,就主動提出這個想法,雖然在離職的前天晚上還在加班調試,當天上午還在和同事討論一些細節,但就是這主動多作學會的技能成了我在第二份工做裏出色開端的重要一環。
以上內容是一位老司機結合本身的實際狀況和貼身經歷,爲你們給出的適用性較強三點建議,做爲程序新人的你,不妨試試看,固然實踐並不像說得這麼輕巧,可是脫穎而出原本就是少部分優秀的人才能作到的事情。
相關閱讀
本文轉自:軟件開發學習資訊