歡迎訪問我的個人博客 ，原文鏈接：http://wensibo.top/2017/08/31/trainee/ ，未經(jīng)允許不得轉載！

距離上篇文章已經(jīng)過去一個多月了，這段時間之所以沒有更新文章不是因為偷懶，而是因為在實習。7月份的時候來到了目前的這家公司實習，當初筆試的時候自己做的不是很好，后來面試時也有些地方變現(xiàn)地也不盡如人意，不過最后還是很感激我老大給我來公司實習的機會。在實習的一個多月時間內(nèi)自己也學到了很多，今天這篇文章就記錄一下我的學習過程。

學校&公司的區(qū)別

來到公司實習，其實自己已然不是一個學生了，別人也不會當你是學生，所以很多事情上需要自己去跟上團隊的節(jié)奏。學校里學到的東西不能說沒用，但是與實際的公司其實是有許多不匹配的，我們更需要將自己學到的知識運用在實踐中，而不是單純地紙上談兵；從另外一個角度上來講這也是為什么企業(yè)招員工時很喜歡招那些有一定的項目經(jīng)驗的學生。很幸運的是自己之前有過一定的項目經(jīng)驗，雖然談不上是多大的項目，但是這些經(jīng)歷足以培養(yǎng)一個人獨立完成工作、獨立解決問題的能力，這點也恰恰是在課本上很難學到，但是在實踐中卻又很有必要積累的。
上面的道理大家都懂，但是沒什么卵用，我舉個例子向大家說明一下這個問題。
我有一個工作內(nèi)容是閱讀之前的一個eclipse工程，并將這個工程移植到Android Studio平臺上
大家或許覺得這個工作內(nèi)容很簡單啊，Android Studio本身就很強大，完全可以解決這個問題。實不相瞞，我一開始也是這樣想的，但是當我閱讀這個舊的工程的時候，我覺得自己回到了"遠古時代"，之所以會有這樣的感嘆，不是因為代碼寫的不好，而是整個工程缺乏一定的架構思想，導致一個Activity文件動不動就600~700行，有的甚至到了1000行，盡管邏輯不復雜，但是性能肯定是大打折扣的，并且如果工程日后是別人接手，或者日后需要擴展功能，那么將會徹底地違背了開閉原則（對擴展開放，對修改關閉）。也是基于這樣的理由，我就打算將整個項目進行重構，而重構使用的方法則是我經(jīng)常在項目中使用的MVP設計架構，盡管這種架構仍然有他詬病的地方（代碼量不少反增，邏輯也會更加的復雜），但是這仍然不失為一個較好的選擇。確定了目標，我也就開始干了，也正因為有了之前項目的積累，所以重構起來也才得心應手。

需要慢慢培養(yǎng)的技能和規(guī)范

技能

做程序開發(fā)，經(jīng)驗是需要慢慢積累的，而技能也不是一下子就爐火純青的，需要經(jīng)歷項目的考驗才能慢慢成為巨人，在這里我列舉一下個人覺得比較重要的開發(fā)技能。

文檔閱讀能力

許多大公司都有維護文檔的習慣，并且文檔的數(shù)量和質量也都是頂呱呱的，作為進入團隊的新人，對于業(yè)務不熟悉的時候，第一時間并不是問老大問同事，而應該自己閱讀文檔，當然不得不承認的一點就是我一開始是比較笨的，遇到問題就問我老大問我同事，到了后來我才悟到這點，也算是積累吧！

前面講的是要有閱讀文檔的習慣，接下來講講要怎么去閱讀文檔。想必大家或多或少都會看Android官方的文檔吧，但是應該不是每個人都看得下的，這里我也承認其實我對官方文檔還是有些許排斥的，不僅僅是有的時候都是英文，增加了閱讀的難度，當然對于本科生而言，英語閱讀不應該成為開發(fā)的阻礙，再者就是盡管將英文翻譯成了中文，讀起來還是有些許的晦澀拗口（也許是我個人的感受），但是。。。不得不承認的就是官方文檔是最權威的，并且它的很多內(nèi)容是很有幫助的，畢竟文檔是由項目的開發(fā)者編寫的，沒有人比開發(fā)者還懂項目了吧！另外文檔中有的時候還會記錄一些開發(fā)者遇到的坑，作為項目的接手者，如何避免跳入這些坑，看這些文檔就對了。我個人的建議就是：

• 要靜下心來閱讀，并且適當?shù)淖鲆幌麻喿x的筆記，將冗雜的內(nèi)容提煉出真正對自己有用的東西，這里推薦一個Chrome的插件——簡悅，他能讓你沉浸在閱讀之中，排除掉頁面其他無關元素的干擾
  
  簡悅圖示
• 再者就是不要妄想一下子就讀完整個文檔，畢竟這是很多開發(fā)者花了許久才編寫完成的，我們要做的就是閱讀與你相關的內(nèi)容，或者你感興趣的內(nèi)容，這樣的效率才會比較高一點。

獨立解決問題的能力

文章開頭講到我們在課本上學到的知識很多時候并不會派上用場，但是當真正需要的時候我們卻早已遺忘，如果你在開發(fā)的過程中遇到了一些困難，首先并不應該也不推薦直接向自己的同事詢問解決方式，畢竟別人也有工作要做，這里我非常感謝我的同事和老大，因為剛進公司時初出茅廬，很多事情都不是很懂，向他們請教了好多好多，但是大家都十分的nice，很耐心的為我解答，他們幫助我很快的熟悉了業(yè)務，非常感謝他們。
話說回來如何獨立的解決問題呢？以下列舉一些我積累的方法，不過大家平常都有用到的啦！

• 善于利用搜索引擎尤其是Google。搜索引擎裝的東西肯定是要比人腦多的，并且互聯(lián)網(wǎng)為全世界的網(wǎng)民提供了知識分享的平臺，你遇到的這個問題或許別人也遇到過，并且已經(jīng)有了解決方案。

• 利用好Stack Overflow 。這是一個編程問題問答平臺，很多人遇到問題之后都會來這里提問，如果你對某些問題有了解決方法，那么就慷慨的給出你的答案吧！

• 仔細分析代碼。如果上述兩個方法都不能解決你的問題，那接下來就得靠你自己了，有可能是你寫的代碼存在某些問題，這個需要你耐心地去排查，如果問題解決了，那么你應該在你的文檔或者筆記中記錄下這個問題，為團隊提供解決方案，而對自己而言也是一種積累。

規(guī)范

規(guī)范在企業(yè)中十分地重要，體現(xiàn)在軟件開發(fā)中就是指代碼的編寫規(guī)范、工具的使用規(guī)范、版本控制工具的使用規(guī)范、文檔的編寫規(guī)范等等。這里講講代碼的規(guī)范和版本控制工具的使用規(guī)范。
其實兩者的關系十分的密切，因為很多時候代碼是需要提交到版本控制系統(tǒng)上的，在這里我就指公司使用的比較多的SVN了。舉一個例子，也是我老大跟我們強調的一點，在開發(fā)過程中代碼的每行的縮距雖然并不是特別的重要，很多時候每個人都有每個人不同的縮距方式，但是這在團隊協(xié)同工作的時候就會存在問題，例如我將Android Studio的默認行縮距進行了調整，將代碼提交到了SVN，接下來我的另外一個同事查看我的代碼時，發(fā)現(xiàn)縮距有點奇怪，于是為了閱讀的方便，他將縮距調整為自己能夠接受的程度，當閱讀完代碼之后，SVN提示我的同事已經(jīng)將代碼修改了，但是實際上他并沒有對代碼做一些實質性的修改，只是做了縮距的修改，但這仍然被SVN識別成一次成功的提交，所以這就是問題所在了。解決問題的方法就是團隊約定一個準則，使用IDE的默認縮距設置，這樣就不會存在這種問題啦！

接觸和學習新知識

正所謂術業(yè)有專攻，每個人都有自己擅長的方面，但是知識是不斷更新的，并且也很少人能夠做到對整個知識體系的每一塊都了然于胸，所以如果到了新的團隊，接手新的業(yè)務，而開發(fā)內(nèi)容是你不熟悉的，那也沒有必要慌張，這個時候你得盡快的熟悉這方面的知識，通過許多的手段去讓自己融入團隊，這個才是新手的最佳技能。

尾聲

以上就是這段實習經(jīng)歷中我學到的一些經(jīng)驗，寫出來與大家一起分享，也當做是這段實習經(jīng)歷的總結，對以后的工作或許會有幫助。希望大家會喜歡！