前面已經討論了起步的心態跟起步的方法兩個問題，好不容易開始寫程式了，卻發現⋯⋯
照著教學做，但是沒有教學就完全不會
不管是去上更多的課，還是看更多的教學，怎麼樣都無法擺脫這個問題。這到底是什麼原因呢？
學會使用
在剛入門的階段，或者我在教人的時候，最初的階段我會希望「即使有問題也先不要問」我們先專注在一個事情上，那就是「熟練」
熟練什麼？以 Ruby 和 Rails 來舉例子，就是先要做到 Ruby 大部分的語法都可以不用查資料或者問題之類的，還有就是像 Rails 的一些基本的操作都能夠使用。
這樣一來，你在後續提問或者去找答案的時候才會有一種感覺。
這個東西我知道，原來是因為這樣！
舉例來說，如果一個寫 Ruby 的工程師連下面這段程式都還不太清楚會發生什麼事情，那麼去思考原理就還太早了。
1[1, 2, 3].each do |num|
2 puts num
3end
上述的程式即使你不清楚
[]eachdo ... end是做什麼用的，至少也要有能力執行它發現會顯示出數字，或者根據過去操作的經驗推測他可能出現一些數字。
當然，上面的舉例其實很基本，大部分的人在學到的時候應該都已經隱約了解一些原理了。
其實一個課程或者教材的好或者不好，就看他是不是都只局限在這個階段，如果都給你一些反覆操作就能做出來的東西，那麼你就會覺得「卡住」跟「好像還是什麼都不會」
解析
既然我們已經對一些基本的程式有一些概念，接下來去探討原理或者「理由」之類的問題就會比較好理解跟上手。
我有時候會思考，我理解的「藍色」跟其他人的「藍色」是不是一樣的。不過因為沒辦法讀取別人的想法，所以我只能簡單的假設，因為看到的「藍色」是相同的東西，所以我們對藍色的理解應該是接近的。
其實這是一個很有趣的問題，那麼當色盲遇到同樣的顏色分不出來，我們的理解還是相同的嗎？
同樣的道理可以證明，為什麼在「初學」的階段先不要對各種「新事物」想要有太多的解答，因為這些知識就有點類似遊戲的關卡解鎖一樣，需要到某個程度的理解，才能夠繼續。
如果現在不懂，去學點其他的東西，再回來看一遍
從上面的程式來說，裡面用到了叫像是「陣列」「迴圈」「迭代器」這些概念，如果前面兩個無法瞭解的話，就很難對「迭代器」有概念，就會對 each 的原理有困難，而 each 的真正運作，又會跟 Ruby 語言特性的 Block （區塊）也就是 do ... end 有關係。
所以在第一次接觸新的寫法（即使是複雜的寫法）我都會打開電腦，然後試著寫出來看看，去檢測他的運作邏輯是怎樣的，在嘗試去理解背後的原理。
像是在 C 語言裡面關於陣列的儲存其實又跟「指標」是有關係的，如果理解了指標的概念，就會對陣列有更深入的了解，近一步的對迭代器的運作又會有新的認識。
透過這樣不斷的「擴充」知識，我們就能夠逐漸的對一個程式語言越來越了解，並且能夠組織更加複雜的專案。
關於這個階段，其實我猜我在教人的時候有時候可能會覺得我很兇是因為我常常會拿著程式碼然後問「你覺得這是怎樣的？」「這是什麼意思？」
其實我是在確認一個問題，就是對方是否「把知識連接起來」如果問了完全回答不出來，那麼就表示說要再往回退，找到一個適合的點把概念串接起來，才能夠順利繼續。
所以有些工程師討論東西像在吵架⋯⋯
另外一個有趣的地方是我以前常常會「塞」很多東西給新手，大概可以介紹個一兩小時這樣。然後就會被對方回答說「我回去再看看⋯⋯」然後就沒下文了，大概是被嚇到吧，或是消化需要花很多時間。
其實不管哪個領域都是這樣，我們很多時候都覺得自己（應該）很專業但是實際上如果發現自己連「舉例」都舉不出來，真的就不要有幻覺了⋯⋯
上週五才跟同事討論 3D 建模的問題，因為他在讀碩班老師讓他選。我就簡單介紹了我在大學讀多媒體的知識，其實光是我這樣「皮毛」的東西，仔細想想可能就要花上一兩年練習了，所以我是建議不要選這塊比較不熟的。 3D 建模除了要會軟體外，其實還要有繪畫（材質）跟攝影（光影）的基礎，才能做出好看的靜態模型，動起來就更困難了⋯⋯
以一化千，化繁為簡
這個小標題感覺超中二的 XD
有些人可能知道我從蠻小的時候就開始學寫程式，不過真正有明顯進步的其實也才五六年。在這之前，我其實花了大概五六年做一件事情——留言板。
當時能做出來的東西其實很少，也很簡單。做過最多次的東西就是留言板，而且我常常跟人這樣講。
當你會做留言板，你就能做出大部分的網站
以最簡單的留言板功能來看，其實就是一個 CRUD 的表現。
假設我們現在想將留言板進化，只需要這樣。
- 留言功能
- 留言功能（複製） -> 改名叫做分類
- 原本的留言功能增加設定分類
當一個留言有了分類之後，就進化到了叫做「討論版」的等級。
所以，我們在更近一步的去改良一下。
- 留言功能
- 留言功能（複製）-> 改名叫做回覆
- 在回覆功能上增加設定目標留言
現在討論板又進化成叫做「論壇」的東西。
所以，依照這個邏輯繼續做下去，理論上來說所有類型的網站都要可以實現。
但是沒有想像的這麼簡單啊！
如果我們要產生會員功能，還要檢查留言的權限才行，其實只是在加入了「判斷」的功能。
- 留言功能
- 留言功能（複製）-> 改名叫做會員，增加一些相關欄位（帳號密碼）
- 留言功能增加設定發表的會員
然後再到編輯，原本是沒有限制的，這次只是增加上限制。
- 編輯
- （新增）檢查現在的會員是不是發表的會員
- 可以編輯
所以，照這樣繼續發展下去，有更多的判斷跟資料檢查，就會慢慢構成一個完整的網站。
這就是「以一化千」也就是在理論上，我們應該能只用一種技巧做完所有事情。
大致上來說就是邏輯判斷，還有迴圈的使用。
如果把這些東西反過來看，當我們學習了各種五花八門的技巧，要怎麼樣用「最少的動作」做到「最多的事情」那就是「化繁為簡」的領域。
不過要接觸到這個世界，至少要很熟練才會漸漸的有感覺，我自己是在這一兩年才比較有一種「原來是這樣」的感覺。
突破貧頸其實有時候就是練習量到了，就會有一種「好像懂了！」然後也能解釋的狀態。不過越到後面其實越痛苦，以前可能幾個月就能感覺到，現在一年可能只有一兩次 XD
化繁為簡的入門就是「重構」的技巧，也就是我們怎麼從鬆散的程式碼變成一堆「函式」然後隨著函式的增加我們在繼續轉換成「物件」而大量的物件成變成一個「套件」（Ex. Ruby Gem）然後透過這些累積的套件在組成一個完整的「專案」
雖然在工作上我們都是從「專案」開始慢慢的重構出小段落，但是「變複雜」然後再「變簡單」就是作為一個專業工程師「專業表現」的一種。
專業表現還有很多面向都會讓人覺得你很專業，不過這種能夠隨心所欲的重組程式的技巧，算是很基本也很容易看出程度的一種類型。越厲害的工程師在初始階段就能夠做到越好的拆分跟規劃，以整個系統等級的規劃來說，個人認為就是架構師（而且可能含包含了網路跟硬體層級等等的規劃）
小結
雖然每次結尾都覺得好像離題，不過我想大致上還是有在主題上（心虛）
其實「瓶頸」主要是因為「知識不足以支持繼續」的情況所造成的，通常我們學語言的時候會覺得自己要「深入」但是到了某個階段後就會發現無法繼續深入。
因為我們還缺少不少「電腦科學」的知識，這時候資訊相關科系的人真的是比較吃香。在這種情況，就可以考慮以「廣泛學習」的心態，去接觸不同的語言。
像是 Ruby / JavaScript 這類型的語言其實都沒有型別，那麼就去試試看有形別的語言。然後看看像是指標之類的東西，再回到 Ruby / JavaScript 上面思考，就會發現一些原本只寫一種語言看不到的東西。
另一方面就像是我們大多數都在學做「網站」都使用 Rails 來開發，但是有沒有試過用 Rack 直接架構網站伺服器？這些都會幫助對 Rails 的理解，因為有很多零碎的概念已經在很多高手的重構中一層一層的被隱藏起來。
所以，如果卡住的時候先不要緊張或者焦慮。先看看「還有什麼能做的？」然後去把那些「可以做沒做過」的事情做看看，也許再回到原本的問題，就會被解決了。
所以，那些厲害的高手或者身邊進步很快的朋友是不是都有一個類似的特點？
常常做東西出來看看
因為我們練習還不夠，所以卡住了，如果想進步快一點多花時間在「不一樣」的嘗試會更有效果。
上一篇文章寫完被實習生問「努力不一定有效果」後來我想想，努力還是有效果，只是可能會有個人差異。另外還有一種可能，那就是練習的方式錯了，練習再多「會的東西」除了做出來比較快幾乎沒有幫助。