Re: [討論] 寫程式的經驗如何培養?
※ 引述《moonshade (一隻歐拉貓)》之銘言：
: 寫這篇主要是抱怨，每個人就業的成長過程各有不一，
: 最近帶新人的時候感覺非常挫折，很多我覺得是直覺的
: 東西，要新人接受的時候，往往受到挑戰，在不想浪費
: 唇舌的情況下乾脆懶得教了，但是這種新人我也不敢讓他
: 碰核心原件。
這個議題我也想過很多次，一直還沒有很好的結論，
就先回個目前大概感想就好。
這篇比較算是偏心得跟推論了，講過的課跟教過得人都不多，
比較難去一概論之，所以看看就好。
這個問題我想本身也很難有標準答案，所以是開放式的議題。
--------------------------------
前提我先講明了，後面我就要講個人看法了。
--------------------------------
這個圈子少有標準答案，一個問題的標準答案，
可能放到不同領域就變成不一樣的。
像寫一個能讓使用者下載資料跟紀錄的程式，
一樣的邏輯 ，可能在手機會因為手機空間不夠大，
而需要做很多資源管理的工作，像是限制能下載的數量，
網路不夠穩定所以還需要續傳。
在 web 會因為沒得存或 localStorage 空間太小而不實用，
變成下載歷程什麼資料都得往 server 塞。
但在 windows app 或 NAS 上，講沒有空間就變成很蠢的事情。
解決同一個問題，在不同情境底下的 best practice 不同，
其中還有語言本身背景的影響。
導致其實我們很習慣去挑戰既有論點，我們會認為東西會動就好，
反正是不是所謂 best practice 跟節省大家時間的作法，其實沒多少人在乎。
當然節省這些時間長期來看就是節省自己時間。
（請原諒我先把某些狂接小案只拼結案根本不打算維護的 SI 領域現象扣掉，
那個圈子我只能說個人造業個人擔。）
--------------------------------------------------------
說穿了就是這行多是不見棺材不掉淚，
一方面是自己沒踩過的雷印象不會深刻，
他會覺得我之前怎樣怎樣就沒問題，很難意識到環境不一樣、條件不一樣。
另一方面我們很多人想做的是垂直交流，也就是老手教給新手的作法，
但因為領域差異跟經驗落差太大，我們教出去的東西，
難免都會集中在某些特定領域，而且會跳過許多我們曾經碰到的問題。
上禮拜我去跟某公司聊教育訓練的事情，我們在談開發上的 best practice ，
我憑著記憶跟經驗重新列舉一些基礎模式跟基礎訓練。
然後我思考的壞習慣又來了，這些模式跟訓練並不困難，
那為什麼新人沒有辦法靠自己推論學會？
因為這之中包含著數以百計踩過的雷碰過得問題，
在教育跟傳承我們不可能把所有碰到過得問題寫下，
因為我們用了一兩年以上得時間碰到這些問題、思考這些問題，
解決這些問題，而這個結構是我們最後剩下的結晶。
我們可能根本都忘記了當初要解決什麼問題，但我們記得這個結構。
但這種說法是很難讓新人或一般的開發者買單的。
這是領域的天性，也是件好事，
這讓我們不斷挑戰自己的認知，不斷的往前深研，
昨天的好作法或許就是明天的問題。
（如以前我們習慣 web 用 table design ，現在幾乎已經完全絕跡。）
個人一般在專案上的作法就是先讓他自由發揮，
幫他往前規劃往前想，然後點出他的設計路線上，
可能會有的問題，然後讓他知道每個決定背後的問題。
當然會用簡單點的專案去試，然後先 warning 他可能會有的問題，
等到他真的碰到問題時，再來討論這個問題的 solution 。
這就是經驗的傳承。
但這樣的效率很慢，以前在某公司時，
讓一個新人完全踢完新人該踢的雷，正常狀況下一年就過去了。
-------------------------------------------------
我理想中的知識傳承場景，不是垂直交流，而是水平交流：
讓一群同樣程度或接近的人，能常常聚在一起彼此討論自己碰到的問題，
同層級的人會碰到的問題通常都很像，而且很清楚知道大家程度不會差太多，
而且當碰到問題時他們發現不同人採取不同 solution 時，
會知道其實有很多種不同 solution ，他們會彼此辯論不同 solution 的優劣。
而且這不是上對下的辯論，所以每個人可以有自己的看法，自己的判斷，
不像是專案裡面因為你最後還是要決定一個作法所以一定會有輸贏。
必要時資深顧問可以再加入，用過去的經驗去討論其中一些可能的盲點。
根據這兩年的社群實驗跟討論成果來看，這種作法效果非常好，
說實話我覺得這就是現在產業技術核心在進步的主要動力。
上面是比較偏向於一些「抉擇性」有兩種以上替代選擇，
無法明確決定哪一個比較好或不好且各有優劣的情況下。
---------------------------------------------------
底下討論的是團隊默契、慣例、習慣，也就是其實沒有什麼絕對的好或不好，
只是大家已經訂出一個規則，所以希望大家尊守的狀況下。
至於所謂的 coding style ，我能理解有一致 coding style 看 code 比較快，
但請大家在堅持 coding style 的同時要對新手有點同理心。
能使用能簡單產出適合 coding style 的工具就使用，
或是如果能自動檢查 coding style 就使用。
規則能簡單就簡單。
要知道要新手遵守無數對他來講非常陌生的規範，
在新手的想法裡面那只是為了讓老手寫 coding 變快，
因為對新手來講，他還沒建立起那個模型之前，
對他來講並不具有任何優勢，只會顯然的發現自己產量下降。
命名規則也有一樣的問題，團隊資深成員是花了很多時間在建立共識，
新手進入共識本來就需要一點時間，不應該太心急。
當然新手要加入團隊 following 共識不造成大家困擾應該是基本原則。
這個部份應該是定期挑出一些比較常見的命名（如 count/index ..etc ），
來作交流跟討論，針對一些覺得比較不太能理解的，大家一起來討論。
如果真的想解決這個問題的話。
--
Life's a struggle but beautiful.
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 61.230.20.186
→
10/29 11:39, , 1F
10/29 11:39, 1F
→
10/29 11:40, , 2F
10/29 11:40, 2F
※ 編輯: TonyQ 來自: 61.230.20.186 (10/29 11:43)
推
10/29 11:55, , 3F
10/29 11:55, 3F
推
10/29 12:00, , 4F
10/29 12:00, 4F
討論串 (同標題文章)