--- title: "從學生的角度給學生學習程式的建議" date: 2013-12-18T00:00:00+08:00 publishDate: 2013-12-18T23:52:00+08:00 lastmod: 2024-10-29T17:28:27+08:00 tags: ["Rails","PHP","經驗","程式"] permalink: "https://blog.aotoki.me/posts/2013/12/18/from-the-students-perspective-to-the-students-program-of-study-recommendations/" language: "zh-tw" --- 雖然自己不是什麼高手，也沒什麼有建設性的建議，但是最近老爸公司來了實習生，我在跟實習生的互動過程中，發現了一些學生在學習程式上的一些要注意的部分，所以想來分享一下。 （先不討論我怎麼會在老爸公司寫扣，還有實習生怎麼出現的這些神秘問題了 XD） --- 其實已經有很多前輩已經分享過非常多有用的技巧與方法，這邊就單純以我個人的經驗，還有與實習生接觸後，我在教導實習生使用 Rails 和融入老爸公司開發流程的過程。（雖然以前只有我自己寫扣拉，哭哭） 其實實習生的訓練有點花時間，畢竟只有接觸過 PHP 沒有任何 Framework 使用經驗，對物件導向和基本程式開發有概念，不過經驗還不夠，最近終於到了讓他自己做一個小專案練習，然後我做 Code Review 跟協作輔助的任務，也因為這樣，我發現了不少 **我以為開始參與社群的學生應該已經習慣、理解的東西** ，但實際上還是有人不習慣和理解。 #### 練習寫文件 這是我個人的親身體驗，在學校修「圖像使用者介面」的時候，老師大部份作業都會讓我們準備企劃書（都一一個個小 Project 在做）到目前，應該是最後的作業，老師說明了不少「企劃書」的要素，當我仔細思考與反思之後，我發現像是架構圖、功能說明等，對開發軟體來說其實很重要，所以必須要寫。 但是格式如何沒有關係，但是要讓自己習慣寫，他會變成往後開發的依據和審視問題的關鍵。 這次練習專案，大概是這樣寫的（但是有圖更好，而且能完整描述出功能其實是最理想的狀況，目的是消除團隊成員的理解差異） ![螢幕快照 2013-12-19 上午9.07.54.png](https://user-image.logdown.io/user/52/blog/52/post/167871/NP9WEIfcRcqZuipe9ewI_%E8%9E%A2%E5%B9%95%E5%BF%AB%E7%85%A7%202013-12-19%20%E4%B8%8A%E5%8D%889.07.54.png) ![螢幕快照 2013-12-19 上午9.08.16.png](https://user-image.logdown.io/user/52/blog/52/post/167871/lOdyYgSsGNXLaU1gPIfQ_%E8%9E%A2%E5%B9%95%E5%BF%AB%E7%85%A7%202013-12-19%20%E4%B8%8A%E5%8D%889.08.16.png) #### 沒有標準答案 在開始的前幾天，我會收到訊息問我說「這個該這樣做嗎？」「我應該這樣做嗎？」 但是，寫程式其實沒有什麼「標準答案」有的頂多是「目前最好的做法」即使你用了不好的做法也沒有關係，學到更好的方法用上就對了，程式並不是不能修改的。 #### 練習看文件 接下來的幾天，我又收到一些訊息問我「這個做法可以這樣做嗎？」並且我在 Code Review 的時候發現，有一些地方有著「奇特」的撰寫方式。 下圖是最開始的程式碼，但是我們已經使用 Devise 套件。 （如果有看 [README](https://Github.com/plataformatec/devise#controller-filters-and-helpers) 的話，其實會發現有 `before_filter` 可以用，幫助你檢查使用者是否登入。） ![螢幕快照 2013-12-19 上午9.12.56.png](https://user-image.logdown.io/user/52/blog/52/post/167871/6DV9qjsQ2Suxm5CoDTXc_%E8%9E%A2%E5%B9%95%E5%BF%AB%E7%85%A7%202013-12-19%20%E4%B8%8A%E5%8D%889.12.56.png) 也因此，要習慣去看文件，裡面通常會註明大部分「你會用到」的功能或者技巧，當然也有些比較冷門的技巧需要用其他方式取得。 #### 加強自己的搜尋技巧 昨晚又再次被提問，不過這個問題其實我也「不清楚」因此我先給了我知道的做法，然後再去搜尋。 不過其實對方也是有先查過資料的，雖然提問的方式不太正確（我會偏好把自己的理解和搜集到的資料一並給對方，這樣對方比較好掌握你目前理解狀況）但是卻沒有抓到想要的資料。 對我來說，搜尋的關鍵字，通常會是一組「名詞」大概就會是類似這樣 `Rails model has_many` 如果我正在尋找某個「框架」的技術，那我會先用 `rails` 把搜尋範圍縮小，接著輸入這個框架內想知道的東西 `model` 最後是想知道的使用方法 `has_many` 感覺就有點類似在下 WHERE 查詢一樣，一個一個條件加入。 #### 了解自己使用的工具 就像 Rails 的 ORM 是叫做「ActiveRecord」這個概念該怎麼來，其實透過搜尋 `Rails model` 或者 `rails orm` 亦或是 `rails database query` 等，都能夠拿到這個關鍵字，之後再需要深入研究 ActiveRecord 的時候，就會用到。 當然，也能夠透過文章或者其他管道取得，但是很重要的是要知道「搜集關鍵字」畢竟你不知道你什麼時候會用到這個關鍵字。 （像是我知道有 ActiveResource 這個東西，但是直到我使用它已經是兩年後的事情了～） 總而言之，最基本的還是要知道自己正在用的這個東西有什麼「可以運用」像是 Migration, Rake 的 Task 功能等，畢竟我真的看過用著 Framework 卻沒有用 Migration 手動用 PHPMyAdmin 建資料表的情況，雖然沒有錯，但是如果花一點時間使用「建議的做法」效率是會快上不少的。 #### 找個人跟你一起練習，做 Code Review 其實實習生比我還細心，我當初沒有考慮到使用者權限問題，在我做 Code Review 的時候有考慮進去。不過他卻沒有注意到有套件像是 Cancan 可以使用，在我們都「少考慮一部份」的情況下，兩個人互相輔助，那就可以改進整體的品質。 當然，可以的話最好用 Git 或者其他版本管理，而且能像 GitLab 對某行程式碼註解會更棒，可以針對有「想法上差異」的地方，做留言和建議。 ![螢幕快照 2013-12-19 上午9.33.11.png](https://user-image.logdown.io/user/52/blog/52/post/167871/FDt3ejsuRRCBLL4LBleu_%E8%9E%A2%E5%B9%95%E5%BF%AB%E7%85%A7%202013-12-19%20%E4%B8%8A%E5%8D%889.33.11.png) 上面這個問題，我猜是新手不知道有 `scope` 的用法，所以用比較單純的 `desc` 不過要照時間排序其實是可以這樣做的。 > 我們家實習說他有用，我去確認真的有用但是他設了 `scope :desc, order('created_at DESC')` 蓋到預設的 desc 了 XD #### 用 VCS, CI 和寫測試 VCS 這類，現在最熱門的就是 Git 而 CI 可以自動化跑測試，會在某些微妙的地方有「幫助」 像是這個情況就超有用的（改 Class Name 但是 Helper 跟對應的 Test Case 都沒改到） ![螢幕快照 2013-12-19 上午9.37.02.png](https://user-image.logdown.io/user/52/blog/52/post/167871/MvlQcCP6T1a3Y91C1FLt_%E8%9E%A2%E5%B9%95%E5%BF%AB%E7%85%A7%202013-12-19%20%E4%B8%8A%E5%8D%889.37.02.png) ![螢幕快照 2013-12-19 上午9.37.18.png](https://user-image.logdown.io/user/52/blog/52/post/167871/gAC5qxC8QhmqCkZdoJAj_%E8%9E%A2%E5%B9%95%E5%BF%AB%E7%85%A7%202013-12-19%20%E4%B8%8A%E5%8D%889.37.18.png) 雖然寫 Test 很累，但是寫一下真的會幫助你改善程式的穩定性。即使還不會寫，也建議開著你的 CI 跟建構好基本的 Test Case 至少像是這種「忘記」的情況，還有機會幫你找出來 XD #### 多看文章、追蹤前輩 其實我認為，不論設計師還是工程師，大家都該用 RSS 訂閱那些對你有益的網誌、網站。每天睡醒，吃早餐的時候就順便看一下，很有興趣的就讀完，有興趣沒時間的先用 Pocket 或者 Evernote 存著，剩下的掃過標題讓自己知道有這件事情或這個工具。 我目前每天大該看 100 ~ 150 篇文章，裡面其實有 90 篇是設計作品（就一張圖，我每天掃過，保持自己對設計感、美感的感覺）至於程式部分其實不多，大約 30 篇左右，大多數時間我都只看過標題，然後把一些新工具存起來，剩下幾篇跟自己有關的就把它讀完。 除此之外還有像是 HTML Weekly, Ruby Weekly 的電子報，建議訂閱，一周大概十到二十篇的文章，但是都是精心挑選的非常有用。 最後是前輩，前輩永遠會分享一些「很有用的知識」一方面是前輩經驗比你多，另一方面是非常多東西雖然簡單、很小巧，但是這些是前輩判定過不錯的東西，更重要的是大部份這些工具你都有辦法使用。 不過，前輩的經驗分享真的要「長期追蹤」才能一直得到，這算是除了參加 Conference 之外，一個很大宗的知識來源。 （運氣好雙向追蹤時，當你分享你的問題時，前輩也都會很熱心幫你解答。） #### 練習提問的技巧 前面有簡單敘述過這個問題，但是還是有幾個要點。 * 要讓對方知道你的程度和理解情況 * 要把你所知道的東西整理後給對方 * 把想知道的理由與看法告訴對方 當對方清楚你的程度時，也比較好用你知道的範圍內的「知識」給你解釋。而你把你搜集到的資料統整後給對方，也比較好理解你的資訊源，有時甚至可以替對方省掉搜集資料給你的時間。最後是有點類似於誠意的東西，為什麼想知道，你對這個問題的看法是怎麼樣的，這樣也有助於對方引導你到正確的方向。 其實這也算是一種互動的技巧吧，雖然我也不太擅長。但是至少在提問的時候，要讓對方知道你對這個問題掌握的程度，單純地提出問題是很難讓人抓到回答的尺度（到底要很簡單，還是用術語說明一下就能解釋） 註：問人應該只會在新手跟高手的階段出現，新手問人是要找到方向。高手問人是一種交流，在中間的問題現在的搜尋引擎都能找到，所以不要太過依賴其他人解答，等待的時間已經夠你找到答案了！ #### 搞清楚自己現在的定位 這部分也是我的親身經歷，系上一位教授對我的期中報告給出一個建議「學數媒的不須要做這樣複雜的程式，而是該去思考怎麼善用這些套件做出你要的東西」 之後我思考了蠻久，其實學技術久的人，常常會過度依賴技術，我自己也是這樣。雖然這不能治療，但是還是可以靠意志力去控制 XD 假設你現在的任務是做一個網誌系統，那你就專心想用什麼 Framework 和工具可以做出安全、又好維護的網誌，而不是去思考怎麼做一個網誌的建構系統（像是 WordPress 之類的） 一定要搞清楚現在的任務核心要點是什麼，技術的實踐真的非常有趣，但是如果你現在正在工作或者有要務在身，那先放下身為技術者追求技術的精神，選擇最適當的工具、套件去完成任務，絕對會比凡事都用技術力解決還好。 #### 不要排斥任何東西 其實我一直不懂對某種程式語言的擁護是什麼感覺，對我來說好玩的語言就去學，沒有關係。 但是重要的是要學會思考「這個語言的特性能用在其他語言嗎？」「這個框架的特質能在其他語言實作的框架實踐嗎？」 把學習語言的經驗善用在各種地方，你會發現學習某種「語言」並不一定要全力的學習某種語言才能達到效果。 不過，要注意不要太過「分散心力」如果只是各學一點並沒有用，同時也要分清楚主要和次要的差別。 （就像主菜根點心一樣，攝取的量是不同的。） #### 定期確認學習狀況 以我來說，我每年過年放假期間，會把這一整年學到的東西都用在一個小專案上，然後看看自己到底會了多少、進步了多少，比過去更加熟練的多少。我覺得這會是一個很不錯的方法，很簡單可以去看出自己學習的情況、不足的地方。 目前我是已「三天完成論壇基本功能」的方式去做，其實可以看到，第一年我基本上是有完成大部份的基本功能從而使網站可以運作，而第二年則是加入了 Backbone 的部分，雖然後端沒有被加強，但是架構上仍是有所改進，而前端則是多了新的技巧與運用。一方面可以看出自己整合的能力，也可以確認自己在「專案進度」管理上的能力。 當持續一段時間後，還可以對自己過往的專案比較，來看出成長，不過最重要的是要知道自己的弱點在哪，然後加以改進。 #### 其他 其實我想還是有很多技巧與經驗可以學習，不過我已經花了一個早上在準備這篇文章。 而且該想的也都想了，剩下沒想到的就在大家的討論中被討論出來吧 XD 如果有前輩要指點也非常歡迎，畢竟我的經驗仍遠遠不足啊！