我得養成一種定期整理程式碼的習慣

作者: qrtt1 (null) 看板: Soft_Job
標題: Re: [閒聊] 你認識幾歲還親自coding的？
時間: Thu Sep 15 01:33:18 2011

※ 引述《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)