實習總結

歡迎掘金的小夥伴們訪問個人我的博客 ，原文連接：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的默認縮距設置，這樣就不會存在這種問題啦！

接觸和學習新知識

正所謂術業有專攻，每一個人都有本身擅長的方面，可是知識是不斷更新的，而且也不多人可以作到對整個知識體系的每一塊都瞭然於胸，因此若是到了新的團隊，接手新的業務，而開發內容是你不熟悉的，那也沒有必要慌張，這個時候你得儘快的熟悉這方面的知識，經過許多的手段去讓本身融入團隊，這個纔是新手的最佳技能。

尾聲

以上就是這段實習經歷中我學到的一些經驗，寫出來與你們一塊兒分享，也當作是這段實習經歷的總結，對之後的工做或許會有幫助。但願你們會喜歡！