來至通達人的回響
我在一個多月前, 寫了一篇帶新人的感想 ,
很感動, 也讓我想了許多自己學習程式設計的過程, 認識我的朋友都大概知道我的背景是機械, 而不是資訊科學, 也不是資訊工程, 也就是說, 我並沒有受過完整的軟體設計, 與軟體工程等教育訓練, 我開始回想, 我是從那時候開始注重我的程式設計風格? 我最遠可以追溯到我念高二開始學習Basic那段日子, 從高二開始, 學校安排一個學期的Basic課程, 每週大約兩個小時, 老師先講解Basic程式設計語言的原理, 然後開始出一些簡單的作業讓大家回去練習, 當時的作業其實很簡單, 大部分都是邏輯訓練, 例如如何利用迴圈列印出像保齡球排列的圖型, 或是做一些檔案的I/O處理, Input/Output , 看似很簡單, 其實卻殿定我往後的基礎, 當年要教作業可是很有成就感, 因為能正確將老師的題目做出來的沒幾個, 但是我可是每道題目都是自己寫, 並上機將結果列印出來, 就在有一天要交作業的前一天, 我看到一位同學(楊松岳)也將作業列印出來, 並很認真在看老師還沒教的Basic章節, 我跟他哈啦一下, 並交流一下心得, 他告訴我, 他已經將整本的Basic K完了, 我當時很驚訝, 他說Basic實在很好玩, 所以他一口氣就將Basic的教科書 K完了, 我問了他幾個問題, 他總能很快回答我, 他告訴我他新的發現--DOS, 他發現Basic只是Basic, 最好玩還要了解DOS的原理, 我當時頗為震撼, 班上還有這一號人物, 而且他的成績並不是很出色, 但是玩電腦確相當有一套, 我們開始分享自己寫的code並互相討論是否還有更好的程式寫法, 他看了我的code總能指出這樣寫太沒效率了, 為什麼回圈一定要從0開始, 有些狀況從Maximum開始也不錯, 我想那應該是我最早的Code被Review的經驗, 所以我從那時候開始寫code就有被檢視的心理準備, 就像畫家畫一幅畫要接受大眾評論一樣.
當我踏入職場, 礙於所學非資訊, 礙於三餐要顧, 所以又在機械業裡待了將近4年, 從念高職到專科, 加上這四年, 等於在機械領域打滾了快10年, 那四年我做過Technical Support , 工廠的生技, 生產線的黑手, 機器手臂治具設計, 我現在還會做惡夢, 生怕自己在操作車床的時候, 手會被高速旋轉的車床給捲進去, 也許你不相信, 為了一次的生產線試機, 我還學會開堆高機, 可以很精準的利用堆高機上下料, 那一段日子, 也是被review相當重的日子, 因為我要畫許多設計圖, 這些設計圖在發包給機械製造商之前, 也是有所謂的design review, 如果design review被挑了許多問題, 辛辛苦苦畫了許多天的電腦圖檔, 也許又要重來. 這些年的經驗在我踏入軟體業, 讓我很快的發現軟體在做design review時的困難度比起機械要難上很多, 機械要review有機械設計圖稿, 有機械背景的人都知道, 在學校要學機械製圖, 三視圖, 透視圖, 等知識, 所以看圖等於在看source code , 但是機械有所謂的設計標準, 加工符號, 標準零件,尺寸標註 , 這些標準早已被列入CNS, c或是JIS等國家標準, 都是馬虎不得, 有一個小地方標錯了, 你所設計的東西就組裝不起來或是定位有問題, 組裝不起來, 做出來的零件不是報廢, 就是要花很多時間做修改, 並且挨一頓罵, 但是反觀軟體呢? source code的標準在那裡? 軟體是工程還是藝術? 在很長的一段軟體業界工作期間, 我寫的code是沒有人要看的, 東西做出來, 可以work就好, 一直到我換了部門, 主管有一天把我叫去說要看我寫的code, 並要我解釋我寫那段code的意思, 所以剛開始我以為軟體業是沒有code review的 :-) , 一直到現在, 我看業界還是普遍存在一種觀念, 做專案都來不及了, 那有時間做code review.
過了沒多久, 又過了一段"自由發揮"的日子, 我接了許多Mac的driver , application案子, 那時候讓我體認, code如果寫的不好, 要re-use就變得很困難, 如果您曾經想靠接案為生, 我想您做到最後會越希望自己寫的code re-use率越高, re-use率低, 每次案子等於要重來一次, 那麼寫軟體等於在做"苦力", 一點利潤都沒有, 所以當時雖然沒有人來盯我的code, 但是為了讓自己輕鬆好過一些, 不知不覺, 就更重視自己的coding style , 與Architecture .
所以這些經驗是否能透過學校教育來傳承, 我不知道是否可行, 但是我的經驗是從同儕間, 主管要求, 與自覺而來, 但是這對一位軟體工程師的養成是否代價太高了些? 目前有CMMI來檢視軟體公司的水準, 但是軟體工程師的檢驗標準在那裡?
有沒有什麼方法, 可以快速訓練出具有高水準, 可以寫出Hight quality的軟體工程師? 我想這是開軟體公司所要面臨嚴峻的挑戰, 我現在的解決方法只有透過資深軟體工程師同儕間的code review與團隊間彼此經驗分享, 但是這對於資源有限的軟體公司, 成本是很高的, 而且等工程師訓練的差不多, 又有人員離職的問題, 前一陣子遇到一位朋友, 我們提到同樣的問題, 他有一個想法, 透過專業的組織訓練出高水平的軟體工程師, 企業可透過此組織來尋求馬上可上線的工程師, 很不錯的想法, 真的希望他的想法可以成真.
讓程式碼像閱讀故事一樣容易
今天收到同達人的回響, 他針對我的論點, 衍伸許多深入的想法與精闢的論點很感動, 也讓我想了許多自己學習程式設計的過程, 認識我的朋友都大概知道我的背景是機械, 而不是資訊科學, 也不是資訊工程, 也就是說, 我並沒有受過完整的軟體設計, 與軟體工程等教育訓練, 我開始回想, 我是從那時候開始注重我的程式設計風格? 我最遠可以追溯到我念高二開始學習Basic那段日子, 從高二開始, 學校安排一個學期的Basic課程, 每週大約兩個小時, 老師先講解Basic程式設計語言的原理, 然後開始出一些簡單的作業讓大家回去練習, 當時的作業其實很簡單, 大部分都是邏輯訓練, 例如如何利用迴圈列印出像保齡球排列的圖型, 或是做一些檔案的I/O處理, Input/Output , 看似很簡單, 其實卻殿定我往後的基礎, 當年要教作業可是很有成就感, 因為能正確將老師的題目做出來的沒幾個, 但是我可是每道題目都是自己寫, 並上機將結果列印出來, 就在有一天要交作業的前一天, 我看到一位同學(楊松岳)也將作業列印出來, 並很認真在看老師還沒教的Basic章節, 我跟他哈啦一下, 並交流一下心得, 他告訴我, 他已經將整本的Basic K完了, 我當時很驚訝, 他說Basic實在很好玩, 所以他一口氣就將Basic的教科書 K完了, 我問了他幾個問題, 他總能很快回答我, 他告訴我他新的發現--DOS, 他發現Basic只是Basic, 最好玩還要了解DOS的原理, 我當時頗為震撼, 班上還有這一號人物, 而且他的成績並不是很出色, 但是玩電腦確相當有一套, 我們開始分享自己寫的code並互相討論是否還有更好的程式寫法, 他看了我的code總能指出這樣寫太沒效率了, 為什麼回圈一定要從0開始, 有些狀況從Maximum開始也不錯, 我想那應該是我最早的Code被Review的經驗, 所以我從那時候開始寫code就有被檢視的心理準備, 就像畫家畫一幅畫要接受大眾評論一樣.
當我踏入職場, 礙於所學非資訊, 礙於三餐要顧, 所以又在機械業裡待了將近4年, 從念高職到專科, 加上這四年, 等於在機械領域打滾了快10年, 那四年我做過Technical Support , 工廠的生技, 生產線的黑手, 機器手臂治具設計, 我現在還會做惡夢, 生怕自己在操作車床的時候, 手會被高速旋轉的車床給捲進去, 也許你不相信, 為了一次的生產線試機, 我還學會開堆高機, 可以很精準的利用堆高機上下料, 那一段日子, 也是被review相當重的日子, 因為我要畫許多設計圖, 這些設計圖在發包給機械製造商之前, 也是有所謂的design review, 如果design review被挑了許多問題, 辛辛苦苦畫了許多天的電腦圖檔, 也許又要重來. 這些年的經驗在我踏入軟體業, 讓我很快的發現軟體在做design review時的困難度比起機械要難上很多, 機械要review有機械設計圖稿, 有機械背景的人都知道, 在學校要學機械製圖, 三視圖, 透視圖, 等知識, 所以看圖等於在看source code , 但是機械有所謂的設計標準, 加工符號, 標準零件,尺寸標註 , 這些標準早已被列入CNS, c或是JIS等國家標準, 都是馬虎不得, 有一個小地方標錯了, 你所設計的東西就組裝不起來或是定位有問題, 組裝不起來, 做出來的零件不是報廢, 就是要花很多時間做修改, 並且挨一頓罵, 但是反觀軟體呢? source code的標準在那裡? 軟體是工程還是藝術? 在很長的一段軟體業界工作期間, 我寫的code是沒有人要看的, 東西做出來, 可以work就好, 一直到我換了部門, 主管有一天把我叫去說要看我寫的code, 並要我解釋我寫那段code的意思, 所以剛開始我以為軟體業是沒有code review的 :-) , 一直到現在, 我看業界還是普遍存在一種觀念, 做專案都來不及了, 那有時間做code review.
過了沒多久, 又過了一段"自由發揮"的日子, 我接了許多Mac的driver , application案子, 那時候讓我體認, code如果寫的不好, 要re-use就變得很困難, 如果您曾經想靠接案為生, 我想您做到最後會越希望自己寫的code re-use率越高, re-use率低, 每次案子等於要重來一次, 那麼寫軟體等於在做"苦力", 一點利潤都沒有, 所以當時雖然沒有人來盯我的code, 但是為了讓自己輕鬆好過一些, 不知不覺, 就更重視自己的coding style , 與Architecture .
所以這些經驗是否能透過學校教育來傳承, 我不知道是否可行, 但是我的經驗是從同儕間, 主管要求, 與自覺而來, 但是這對一位軟體工程師的養成是否代價太高了些? 目前有CMMI來檢視軟體公司的水準, 但是軟體工程師的檢驗標準在那裡?
有沒有什麼方法, 可以快速訓練出具有高水準, 可以寫出Hight quality的軟體工程師? 我想這是開軟體公司所要面臨嚴峻的挑戰, 我現在的解決方法只有透過資深軟體工程師同儕間的code review與團隊間彼此經驗分享, 但是這對於資源有限的軟體公司, 成本是很高的, 而且等工程師訓練的差不多, 又有人員離職的問題, 前一陣子遇到一位朋友, 我們提到同樣的問題, 他有一個想法, 透過專業的組織訓練出高水平的軟體工程師, 企業可透過此組織來尋求馬上可上線的工程師, 很不錯的想法, 真的希望他的想法可以成真.
留言