歡迎掘金的小夥伴們訪問我的個人部落格 ，原文連結：wensibo.top/2017/08/31/…

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

學校&公司的區別

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

需要慢慢培養的技能和規範

技能

做程式開發，經驗是需要慢慢積累的，而技能也不是一下子就爐火純青的，需要經歷專案的考驗才能慢慢成為巨人，在這裡我列舉一下個人覺得比較重要的開發技能。

文件閱讀能力

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

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

• 要靜下心來閱讀，並且適當的做一下閱讀的筆記，將冗雜的內容提煉出真正對自己有用的東西，這裡推薦一個Chrome的外掛——簡悅，他能讓你沉浸在閱讀之中，排除掉頁面其他無關元素的干擾
  

  

• 再者就是不要妄想一下子就讀完整個文件，畢竟這是很多開發者花了許久才編寫完成的，我們要做的就是閱讀與你相關的內容，或者你感興趣的內容，這樣的效率才會比較高一點。

獨立解決問題的能力

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

• 善於利用搜尋引擎尤其是Google。搜尋引擎裝的東西肯定是要比人腦多的，並且網際網路為全世界的網民提供了知識分享的平臺，你遇到的這個問題或許別人也遇到過，並且已經有了解決方案。

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

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

規範

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

接觸和學習新知識

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

尾聲

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