推 tomap41017:重構與單元測試的進入門檻比較高，但版本控制.. 09/15 20:45
→ tomap41017:git超基本的四個指令記住，你就會愛上他了.. 09/15 20:45
→ qrtt1:所以，先由門檻低的項目入手吧。拿座高牆嚇自己也不是好事:) 09/15 20:49
推 landlord:跟我擅長和喜歡的三個東西一樣 :P 09/15 22:35
※ 引述《midtail (全新的)》之銘言：
: 由於常常有人跟我說，我們這個年紀不適合寫code了
: 問他們為什麼？他們總是說太累，拼不過年輕人
: 沒有辦法像年輕人一樣熬夜？
: 心中有幾個疑問想問鄉民們？
: coding一定會熬夜嗎？
這能算在抽樣誤差嗎？
如果跟你說的人，是工作起來不得法的人，
我想他們只好花更多時間在重複修正自己的錯誤了。
事實上，沒有人能寫出 100% 沒問題的程式。
但是因每個人選擇的應對策略不同，後續的結局也就可能不同。
單純就是否有善用版本控制工具來說，
今天我試著要修個 bug，改了幾個檔案。
倒數第二次修改的部分，總覺得使得結果更糟了。
想要回復到那一次修改前的狀態，而保留那一次後的狀態。
在 IDE 的檔案列表間，點來點去，一下決定用 Ctrl Z 回復，
一下又決定將不要的部分 comment 起來。
最後，改出一個『印象』中，
似乎是去掉倒數第二次修改，但保留之後修改的內容的狀態。
改定後、compile、run-and-pray，程式還是杯具地 crash 了。
如果採用版本控制工具，你能『優雅』地處理它。
: 資深、寫久了、能寫比較快，是否能改善工時長的問題？
: 另外，coding累，是因為總是有更多更新的語言得學，所以累嗎？
: 還是，不管寫多快，總是有寫不完的code
學習是好事，但不要盲目追逐流行。
新語言之所以又快又好，除了豐富彈性的語意與方便的開發工具之外，
『個人覺得』那是因為還沒有足夠多的寫醜的舊產品要維護
語言優美是一回事，但不見得人人有能力將這份優美延續到實務上。
純粹以工作來說，
應該選擇學習有助於自己工作效率的新工具，
無論是觀念、開發環境、程式語言。
最開頭的例子，一個好用的版本控制工具，
就能帶領我們脫離 Ctrl Z 與手工回復上一動的苦海。
『資深、寫久了、能寫比較快，是否能改善工時長的問題？』
這個提問合理的回答是什麼？
首先得反問，對一名軟體工作者來說，是什麼使工時變長？
而使工時變長的哪些因素是跟自己作為較相關的？
這答案對每個人都不一樣，
但如果你的答案裡，有太多跟自己無關，
先捫心自問，在不是自我感覺良好的情況之下，
是不是目前的工作環境太糟糕了？
這裡我舉個比較普遍跟自身相關的因素：『製造Bug』。
心理明白的很，沒有人不寫Bug的。
但是，我們仍是能找到一些值得採納的建議來試著：
『減少Bug』或是『讓Bug很容易被發現』至少我們希望
『Bug，我不想當最後一個知道的人』
值得一提的老梗『重構』與『單元測試』
但心態上，不用過去版友討論 Code Review 那般嚴肅。
我知道重構的書本裡介紹得詳細，
也許你讀過那些 bad smell index，跟有哪些重構技巧。
以及重構跟 debug 不會同時進行的原則，
甚至你可能注意到書上有說，
重構是透過單元測試保障其正確性的。
但現實上，許多公司裡並沒有規定必需有單元測試。
所以，你也不必把它視為那麼嚴肅的話題。
只要這樣想：『我得養成一種定期整理程式碼的習慣』
就像房間久沒整理，可能地板都被淹沒了。
而養成這個習慣，你能先試著練習：
1. 避免重複的程式碼
2. 保持程式邏輯簡單
如果你的程式，在初期運用了許多 copy & paste 手工技巧，
必定會產生許多重複的程式碼。重複程式碼的問題不在於『重複』！
而在於『難以維持一致性』。
像是發現某一個地方不心有 typo，像是 if 內多按了個 !，
就得去找那些已經實施 copy & paste 技能的地點一一改正。
光是一個人對同一個地方的程式碼 copy & paste 都難以改到完整了。
更不用說多人的情況，這邏輯的『一致性』到底該如何維持。
如果程式看起來不太易懂，就表示那段的邏輯稍嫌複雜。
但複雜的程式，問題不在於『難懂』，而在於其他維護者對它的『誤解』
難懂，至少時間花下去，應該還是能明白的。
但在沒有時間的情況下，只能用『好像懂了』的心情『誤解』它。
這種情況，後續的維護者會寫出『真誠』的 Bug。
儘可能在不影響 Big O 的情況下，把它寫到清楚明白。
撇開了整理成冊的『重構』，單純先由這二個方向入手。
已經能更有效率地面對 Bug 這件事情。
另外，單元測試。也是同樣的。
如果你什麼都還沒開始：
忘掉 code coverage、不要理會 mock test 跟複雜的、
流程相依的、真實物件隔離的、過於技巧性的測試技術。
單純測你寫出來能獨立執行的函式，
在合理的、不合理的 input/output 之下，
是不是產生了期望的結果。
其它還沒學會的流程轉移間的測試，或相依物件的測試。
就先用人腦來代勞吧。
總之，coding 是不是要花很長的時間，
我們應該用 performance profiling 的精神來看待問題
先找出最關鍵因素，並選出應對之策實際嘗試。
當然，我的意圖擺明就是來推銷。
推銷我覺得能節省軟體工作者虛耗工時的方法：
『版本控制』、『重構』與『單元測試』
大家都是進入社會的『職人』，
我們工作不管是為了什麼目標，這倒底是個『經濟』活動。
我們得用『經濟實惠』的工作方法來處理。
而非土法煉鋼，卻妄想超英趕美。
: 如果coding不能做一輩子，coding是跳板，能跳到什麼工作呢？
: 總是有些人不愛面對人群的，寫一輩子code，缺點是薪水不可能太高嗎？
: 你們認識還在coding年紀最大的是幾歲？
未來的事我不知道，但是我知道，就算是大師還是也在寫 code 的。
我覺得若是對管理真的很有一套的人，轉職去管理那是件好事。
這個工作不是只需要 Programmer，
對於 Programmer 工作內涵有相當理解的人。
希望你們面對管理不是當作一個已經寫不下去了，轉管理唄的心態。
而是站在自己曾是 Programmer 的角度，
當時希望怎麼被『服務』，而選擇管理的職位。
不然只是讓 Programmer 在不良 PM 名單中添上一筆罷了。
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 61.231.49.52
※ 編輯: qrtt1 來自: 61.231.49.52 (09/15 01:34)
※ 編輯: qrtt1 來自: 61.231.49.52 (09/15 01:40)