從學生的角度給學生學習程式的建議

雖然自己不是什麼高手,也沒什麼有建設性的建議,但是最近老爸公司來了實習生,我在跟實習生的互動過程中,發現了一些學生在學習程式上的一些要注意的部分,所以想來分享一下。

(先不討論我怎麼會在老爸公司寫扣,還有實習生怎麼出現的這些神秘問題了 XD)


其實已經有很多前輩已經分享過非常多有用的技巧與方法,這邊就單純以我個人的經驗,還有與實習生接觸後,我在教導實習生使用 Rails 和融入老爸公司開發流程的過程。(雖然以前只有我自己寫扣拉,哭哭)

其實實習生的訓練有點花時間,畢竟只有接觸過 PHP 沒有任何 Framework 使用經驗,對物件導向和基本程式開發有概念,不過經驗還不夠,最近終於到了讓他自己做一個小專案練習,然後我做 Code Review 跟協作輔助的任務,也因為這樣,我發現了不少 我以為開始參與社群的學生應該已經習慣、理解的東西 ,但實際上還是有人不習慣和理解。

練習寫文件

這是我個人的親身體驗,在學校修「圖像使用者介面」的時候,老師大部份作業都會讓我們準備企劃書(都一一個個小 Project 在做)到目前,應該是最後的作業,老師說明了不少「企劃書」的要素,當我仔細思考與反思之後,我發現像是架構圖、功能說明等,對開發軟體來說其實很重要,所以必須要寫。

但是格式如何沒有關係,但是要讓自己習慣寫,他會變成往後開發的依據和審視問題的關鍵。

這次練習專案,大概是這樣寫的(但是有圖更好,而且能完整描述出功能其實是最理想的狀況,目的是消除團隊成員的理解差異)

螢幕快照 2013-12-19 上午9.07.54.png

螢幕快照 2013-12-19 上午9.08.16.png

沒有標準答案

在開始的前幾天,我會收到訊息問我說「這個該這樣做嗎?」「我應該這樣做嗎?」

但是,寫程式其實沒有什麼「標準答案」有的頂多是「目前最好的做法」即使你用了不好的做法也沒有關係,學到更好的方法用上就對了,程式並不是不能修改的。

練習看文件

接下來的幾天,我又收到一些訊息問我「這個做法可以這樣做嗎?」並且我在 Code Review 的時候發現,有一些地方有著「奇特」的撰寫方式。

下圖是最開始的程式碼,但是我們已經使用 Devise 套件。
(如果有看 README 的話,其實會發現有 before_filter 可以用,幫助你檢查使用者是否登入。)
螢幕快照 2013-12-19 上午9.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

上面這個問題,我猜是新手不知道有 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

螢幕快照 2013-12-19 上午9.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

如果有前輩要指點也非常歡迎,畢竟我的經驗仍遠遠不足啊!

留言