2004-07-09 12:40:49小雄
大陸工程師的通病
大陸工程師的通病(一)
最近正在進行一個跨越兩岸的案子，需要和我們大陸分公司的工程師分工合作，這個案子本來是很急的，在月底就要demo給客戶看，可是這個大陸工程師卻不斷的提出新的架構出來，我實在覺得很納悶，到底他所提出的架構是不是自己都已經實驗過了，還是他只是會說大話。
由於會影響到我已經規劃好的工作計畫，我要求他提供一些範例，還有對他提出了一些問題，希望他可以先回答我，讓我知道他已經做到了，那麼我就可以按照他的架構去設計。沒想到他回信竟告訴我，說他最近忙著要應付Demo，因此那些提出來的架構都沒有時間去做，但是他認為那樣的架構才是效率最好的。
你知道他所說的架構是什麼嗎？就是我一直在實驗的跨平台架構中的virtual machine(虛擬機器)，我是集一身十幾年的軟體設計經驗，並且花了半年多的時間才有了一點點成果，而他從來就沒有在PC上面做過任何實驗，就說得很有把握，好像他已經有了實做的範例，我覺得他這種毛病很令人討厭，同時也發現他這種心態就是大陸人的通病，不管自己懂不懂，都要別人以為他很行。
我後來寫了一封信表達了我的感想，我覺得自己寫得很不錯，提供各界參考一下。
註：底下所談到的Script只是一種指令代碼，架構比較簡單，還不是VM那種架構，目前我正在設計一種Script代碼，可以讓使用者用簡單的語法自行編輯程式。
第一封是他第一次告訴我，說他使用的是VM架構，讓我嚇了一大跳。
『 Dear Mark:
上次mail給您的 script01.txt 和 script02.txt 是要經過編譯成VM（virtual machine）指令存放在外插卡里面的﹐您當然可以根据您的需要設計語法﹐我這兩天因為又要出一個Demo﹐過几天我會跟您討論一下 VM指令 （一套簡單的ASM指令集）的內容 ﹐以后不管您設計成什么樣的語法﹐只要能轉成這套VM ASM﹐我這邊就能解釋執行﹒
Nova 』
聽他這麼說，於是我馬上回信要求開會，想搞清楚他是不是也做了一套VM程式，
『 Dear Nova,
原先不曉得您的做法是用Virtual Machine執行的，還有您的Script是要編譯成Byte Code然後由VM去執行，這種做法如果確定，就應該早一點告訴我們，因為我也在做Script，如果要用您的VM執行，我就不能再用目前的方法設計下去了，到時一定無法運作，一定要使用您的語法才行，這是很重要的問題，請安排時間開會，確定這個問題。
Mark Chen 』
『 Dear Mark:
sorry, 我一直以為您那邊也是用這種方法﹒
這兩天我很趕﹐沒時間開會﹐請見諒﹐周三我這邊應該有時間﹒
Best Regards
Nova 』
既然他很忙，我就先提了幾個問題，想知道到底他是不是真的做過VM，
『 Dear Nova,
那麼我們約在星期三上午10點鐘開會，請確定一下。
另外有關VM的架構我有幾個問題先提出來，請您事先準備一下。
第一：使用VM執行byte code，必須執行一個VM的主迴圈，不斷的讀取byte code指令，這一點您前幾封mail就已經談到過，說這是很浪費CPU時間的，為何您現在又使用這種方式呢？
第二：您現在如果已經使用這種方式設計，就必須先設計兩套工具，第一套是語法編譯器，先把自訂的程式語法編譯成byte code，儲存成script檔，第二套是VM虛擬機器，把byte code中的code及data區段都載入到記憶體，然後才能執行，需要的記憶體是很大的，這不正是您原先所擔憂的問題嗎？
第三：PC端語法編譯器程式即使已經寫好，但是語法方面也是要考慮到使用者是否可以自行撰寫，對於類似C語言這種語法，我認為使用者是很難去撰寫的，不知您的語法是否更簡單，請下次開會一併討論。
第四：假如VM的架構已經是您的選擇方式，而且已經做好了，那麼我就應該使用您的工具來設計相關的Script應用，而不是我再去設計其他的Script架構，這樣才不會疊床架屋，使系統效率更慢。您是否已經可以提供這些工具了呢？例如最基本的語法編譯器，PC端VM測試工具等等，這是很重要的問題。
Mark Chen 』
沒想到他竟是這樣回答，
『 Dear Mark:
詳細情況﹐我們周三再談﹐目前我這里還沒有做VM, 因為一直都在和「XXX」確定方案﹐所以總是要給他們看Demo, 沒有時間作這種設計﹐目前的方式使用的是每個範圍對應一條指令﹒
VM不會將data和code一次性都裝進來﹐而是使用類似于cache的机制﹐VM也不是一直在執行﹐當User點擊了一個區域﹐VM才會啟動﹐去執行相應的script﹐執行完成后VM會休息﹒而不是不斷地調用迴圈﹒因為我覺得只有使用VM這種方式才能將卡的功能做的強大一些﹐而且byte code執行效率會高一些 (總不能讓硬體將ASCII碼讀進來分析吧) .
PC端並不一定要使用C這種高級語言實現﹐可以直接用一種類似於ASM的方式（方便直接翻譯成VM ASM）. 應該可以規劃出一個比較方便的實現方案﹒
關于是否使用VM﹐還是您有更好的方案﹐是否需要確認?
Best Regards
Nova 』
聽他說得好像很瞭解VM的運作方式，原來其實都還沒有實驗過，一切都只是想像的。這時我知道他並沒有那麼厲害了，就比較放心了，但是我還是要罵一罵他，於是寫了底下的mail，
『 Dear Nova,
我有一些觀點想提供給您參考，凡是未經過實驗的技術，就要持保留的態度，因為我們現在要做的案子並不是研發性質的案子，而是需要在很短時間內完成的案子，並且我們也不是要發明一個什麼新的產品，而是要抄襲市面上已經在販賣的產品。
因此第一，在案子還沒進行前，就要先做好技術評估，要使用什麼技術，應該先看看別人在賣的東西是怎麼做的，我們有辦法在短時間做出來嗎？然後再想想我們可以用更好的技術做嗎？會更節省各方面的成本嗎？只有事先考慮清楚，才有可能避免成本的無謂浪費，包括硬體零件的成本及軟體設計的時間。
第二，既然已經到了要Demo的時候了，架構就不應該再做大幅改變，這樣才能保證Demo之後所繼續完成的產品的品質不會相差太大。一個案子是否會成功，案子進行的先後次序是很重要的。
第三，在一個分層負責的專案架構之中，只要把每個人所負責的部分區分清楚，在不影響到彼此架構有關的前提之下，都可以自由發揮，只要方便設計即可。可是如果在中間提出一個完全不同的架構，又會影響到每個不同的部分，這種做法就應該避免。
因此，既然一開始您並沒有使用VM的架構，而且您到目前為止也沒有真正實驗過VM的架構，對其運作方式，執行效率也都只是靠想像，在我們這個急迫的案子上最好不要使用。以後如果有別的案子有時間可以研究，我們再來看看怎麼做VM。
其實有心要挑戰任何技術都是值得讚賞與鼓勵的，只是我認為在緊急的專案上來講，這是不適合的。
另外我認為，您若要做VM的實驗，應該先以PC為實驗平台，等到在PC上有了完整的編譯器及VM虛擬機器的實做版本，才有可能移植到其他CPU的平台。
這個星期我將會提出一個Script版本，到時您可以評估一下我的架構是否適合在E-BOOK上面執行。
Mark Chen 』
很有趣是吧！我不是第一次跟大陸人交手了，但是這次是我第一次寫信告誡他們，收信者包括兩岸的副總經理層級以下，每個參與此案的人都看得到，這真是一件大快人心的事。
大陸工程師的通病(二)
早上11:30開會到12:40，都已經過了吃飯時間，我也不想吃飯了，因為心情真是很不好。
今天的會議是我召開的，本來想要藉這次會議宣佈退出Script設計的工作，讓大陸工程師自己一手包辦，沒想到他說他沒時間，又趕著要Demo，原來還是跟上次一樣，他只是在放炮而已。
由於他所提出的架構跟我的Script大不相同，這等於是要叫我重寫，為了讓其他人知道嚴重性，於是我就先問他幾個問題：
第一，他有沒有先把我的程式測試一下，並且移植到他的硬體上面。結果他說沒有。
第二，他既然提出了自己的理想架構，到底有沒有一個Sample可以給我測試的。結果他說也沒有。
第三，他的Schedule既然這麼趕，就應該盡量減少問題，應該假設我的程式沒有問題，先去移植看看，碰到有問題的地方再修改，這樣才有效率。為何在還沒有測試我的程式之前，就叫我重寫，即使重寫了，我也不知道對不對，他這樣做根本是在製造問題，我當著所有的人這麼說。
然後他就回答說，他是以經驗來判斷我的程式有問題，不需要實際測試，還說他所提出的架構跟我的沒有什麼差異，應該不需要重新設計。
然後他們那邊的經理說要當場讓那個大陸工程師分析給我們看，要指出我的Script架構哪些地方有問題，讓大家可以有所了解。
我馬上回應他的提議，我說，要分析也是可以的，但是我要先表達一下立場，為何不先實際移植之後直接看執行的結果，讓機器來說話，而要讓你們的工程師用想像的方式來指出問題呢？這是很不尊重我的做法，也是很不公平的。但是既然你們要分析，那就分析吧！
於是他就提出了許多問題，都被我一一解決，有些地方他說問題不是很大，只要稍作修改即可，我就說，既然問題不大，為什麼你不直接改掉就好了呢？即使你不願意改寫我的程式，你也要指出我的程式哪裡有問題需要改寫，而不是另外又去制定一套規格，然後卻跟我說架構差異不大，在我看來那是完全不同的。
到後來我就說，現在的問題是你們的工程師不願意動手做測試，只打算用想像的方式來判斷問題，即使我又改好了另外一個版本，他如果也不去測試，到頭來像現在的這種情形還是會再發生的。
會議過程中我們這邊總共四個人，對方有三個人，我們這邊由我當主力，大陸人被我說到最後漸漸理虧了，最後才勉強答應我，他們會做測試，而我這裡暫時不修改我的程式，等到他們先做完測試，要修改哪些地方再告訴我。
這整件事情的進行過程使我覺得很不愉快，有許多進度的問題，規格的問題，上層主管們都做的很差，甚至在問題發生的時候，他們也缺乏判斷是非對錯的能力，只會認為發生問題的人就是一個麻煩。至於像大陸工程師的那種不尊重人的毛病，還有他的那種做事方式，卻很少有人去指責與糾正，若從我的角度去批判那個人，倒有點顯得我是在逃避責任了。
不過好在我的工作是有完成進度的，我的程式已經給了對方，是對方不去做測試，這是很明顯可以看出來的。
真希望早一點完成自己的計劃，去做一些更有成就感的事。
最近正在進行一個跨越兩岸的案子，需要和我們大陸分公司的工程師分工合作，這個案子本來是很急的，在月底就要demo給客戶看，可是這個大陸工程師卻不斷的提出新的架構出來，我實在覺得很納悶，到底他所提出的架構是不是自己都已經實驗過了，還是他只是會說大話。
由於會影響到我已經規劃好的工作計畫，我要求他提供一些範例，還有對他提出了一些問題，希望他可以先回答我，讓我知道他已經做到了，那麼我就可以按照他的架構去設計。沒想到他回信竟告訴我，說他最近忙著要應付Demo，因此那些提出來的架構都沒有時間去做，但是他認為那樣的架構才是效率最好的。
你知道他所說的架構是什麼嗎？就是我一直在實驗的跨平台架構中的virtual machine(虛擬機器)，我是集一身十幾年的軟體設計經驗，並且花了半年多的時間才有了一點點成果，而他從來就沒有在PC上面做過任何實驗，就說得很有把握，好像他已經有了實做的範例，我覺得他這種毛病很令人討厭，同時也發現他這種心態就是大陸人的通病，不管自己懂不懂，都要別人以為他很行。
我後來寫了一封信表達了我的感想，我覺得自己寫得很不錯，提供各界參考一下。
註：底下所談到的Script只是一種指令代碼，架構比較簡單，還不是VM那種架構，目前我正在設計一種Script代碼，可以讓使用者用簡單的語法自行編輯程式。
第一封是他第一次告訴我，說他使用的是VM架構，讓我嚇了一大跳。
『 Dear Mark:
上次mail給您的 script01.txt 和 script02.txt 是要經過編譯成VM（virtual machine）指令存放在外插卡里面的﹐您當然可以根据您的需要設計語法﹐我這兩天因為又要出一個Demo﹐過几天我會跟您討論一下 VM指令 （一套簡單的ASM指令集）的內容 ﹐以后不管您設計成什么樣的語法﹐只要能轉成這套VM ASM﹐我這邊就能解釋執行﹒
Nova 』
聽他這麼說，於是我馬上回信要求開會，想搞清楚他是不是也做了一套VM程式，
『 Dear Nova,
原先不曉得您的做法是用Virtual Machine執行的，還有您的Script是要編譯成Byte Code然後由VM去執行，這種做法如果確定，就應該早一點告訴我們，因為我也在做Script，如果要用您的VM執行，我就不能再用目前的方法設計下去了，到時一定無法運作，一定要使用您的語法才行，這是很重要的問題，請安排時間開會，確定這個問題。
Mark Chen 』
『 Dear Mark:
sorry, 我一直以為您那邊也是用這種方法﹒
這兩天我很趕﹐沒時間開會﹐請見諒﹐周三我這邊應該有時間﹒
Best Regards
Nova 』
既然他很忙，我就先提了幾個問題，想知道到底他是不是真的做過VM，
『 Dear Nova,
那麼我們約在星期三上午10點鐘開會，請確定一下。
另外有關VM的架構我有幾個問題先提出來，請您事先準備一下。
第一：使用VM執行byte code，必須執行一個VM的主迴圈，不斷的讀取byte code指令，這一點您前幾封mail就已經談到過，說這是很浪費CPU時間的，為何您現在又使用這種方式呢？
第二：您現在如果已經使用這種方式設計，就必須先設計兩套工具，第一套是語法編譯器，先把自訂的程式語法編譯成byte code，儲存成script檔，第二套是VM虛擬機器，把byte code中的code及data區段都載入到記憶體，然後才能執行，需要的記憶體是很大的，這不正是您原先所擔憂的問題嗎？
第三：PC端語法編譯器程式即使已經寫好，但是語法方面也是要考慮到使用者是否可以自行撰寫，對於類似C語言這種語法，我認為使用者是很難去撰寫的，不知您的語法是否更簡單，請下次開會一併討論。
第四：假如VM的架構已經是您的選擇方式，而且已經做好了，那麼我就應該使用您的工具來設計相關的Script應用，而不是我再去設計其他的Script架構，這樣才不會疊床架屋，使系統效率更慢。您是否已經可以提供這些工具了呢？例如最基本的語法編譯器，PC端VM測試工具等等，這是很重要的問題。
Mark Chen 』
沒想到他竟是這樣回答，
『 Dear Mark:
詳細情況﹐我們周三再談﹐目前我這里還沒有做VM, 因為一直都在和「XXX」確定方案﹐所以總是要給他們看Demo, 沒有時間作這種設計﹐目前的方式使用的是每個範圍對應一條指令﹒
VM不會將data和code一次性都裝進來﹐而是使用類似于cache的机制﹐VM也不是一直在執行﹐當User點擊了一個區域﹐VM才會啟動﹐去執行相應的script﹐執行完成后VM會休息﹒而不是不斷地調用迴圈﹒因為我覺得只有使用VM這種方式才能將卡的功能做的強大一些﹐而且byte code執行效率會高一些 (總不能讓硬體將ASCII碼讀進來分析吧) .
PC端並不一定要使用C這種高級語言實現﹐可以直接用一種類似於ASM的方式（方便直接翻譯成VM ASM）. 應該可以規劃出一個比較方便的實現方案﹒
關于是否使用VM﹐還是您有更好的方案﹐是否需要確認?
Best Regards
Nova 』
聽他說得好像很瞭解VM的運作方式，原來其實都還沒有實驗過，一切都只是想像的。這時我知道他並沒有那麼厲害了，就比較放心了，但是我還是要罵一罵他，於是寫了底下的mail，
『 Dear Nova,
我有一些觀點想提供給您參考，凡是未經過實驗的技術，就要持保留的態度，因為我們現在要做的案子並不是研發性質的案子，而是需要在很短時間內完成的案子，並且我們也不是要發明一個什麼新的產品，而是要抄襲市面上已經在販賣的產品。
因此第一，在案子還沒進行前，就要先做好技術評估，要使用什麼技術，應該先看看別人在賣的東西是怎麼做的，我們有辦法在短時間做出來嗎？然後再想想我們可以用更好的技術做嗎？會更節省各方面的成本嗎？只有事先考慮清楚，才有可能避免成本的無謂浪費，包括硬體零件的成本及軟體設計的時間。
第二，既然已經到了要Demo的時候了，架構就不應該再做大幅改變，這樣才能保證Demo之後所繼續完成的產品的品質不會相差太大。一個案子是否會成功，案子進行的先後次序是很重要的。
第三，在一個分層負責的專案架構之中，只要把每個人所負責的部分區分清楚，在不影響到彼此架構有關的前提之下，都可以自由發揮，只要方便設計即可。可是如果在中間提出一個完全不同的架構，又會影響到每個不同的部分，這種做法就應該避免。
因此，既然一開始您並沒有使用VM的架構，而且您到目前為止也沒有真正實驗過VM的架構，對其運作方式，執行效率也都只是靠想像，在我們這個急迫的案子上最好不要使用。以後如果有別的案子有時間可以研究，我們再來看看怎麼做VM。
其實有心要挑戰任何技術都是值得讚賞與鼓勵的，只是我認為在緊急的專案上來講，這是不適合的。
另外我認為，您若要做VM的實驗，應該先以PC為實驗平台，等到在PC上有了完整的編譯器及VM虛擬機器的實做版本，才有可能移植到其他CPU的平台。
這個星期我將會提出一個Script版本，到時您可以評估一下我的架構是否適合在E-BOOK上面執行。
Mark Chen 』
很有趣是吧！我不是第一次跟大陸人交手了，但是這次是我第一次寫信告誡他們，收信者包括兩岸的副總經理層級以下，每個參與此案的人都看得到，這真是一件大快人心的事。
大陸工程師的通病(二)
早上11:30開會到12:40，都已經過了吃飯時間，我也不想吃飯了，因為心情真是很不好。
今天的會議是我召開的，本來想要藉這次會議宣佈退出Script設計的工作，讓大陸工程師自己一手包辦，沒想到他說他沒時間，又趕著要Demo，原來還是跟上次一樣，他只是在放炮而已。
由於他所提出的架構跟我的Script大不相同，這等於是要叫我重寫，為了讓其他人知道嚴重性，於是我就先問他幾個問題：
第一，他有沒有先把我的程式測試一下，並且移植到他的硬體上面。結果他說沒有。
第二，他既然提出了自己的理想架構，到底有沒有一個Sample可以給我測試的。結果他說也沒有。
第三，他的Schedule既然這麼趕，就應該盡量減少問題，應該假設我的程式沒有問題，先去移植看看，碰到有問題的地方再修改，這樣才有效率。為何在還沒有測試我的程式之前，就叫我重寫，即使重寫了，我也不知道對不對，他這樣做根本是在製造問題，我當著所有的人這麼說。
然後他就回答說，他是以經驗來判斷我的程式有問題，不需要實際測試，還說他所提出的架構跟我的沒有什麼差異，應該不需要重新設計。
然後他們那邊的經理說要當場讓那個大陸工程師分析給我們看，要指出我的Script架構哪些地方有問題，讓大家可以有所了解。
我馬上回應他的提議，我說，要分析也是可以的，但是我要先表達一下立場，為何不先實際移植之後直接看執行的結果，讓機器來說話，而要讓你們的工程師用想像的方式來指出問題呢？這是很不尊重我的做法，也是很不公平的。但是既然你們要分析，那就分析吧！
於是他就提出了許多問題，都被我一一解決，有些地方他說問題不是很大，只要稍作修改即可，我就說，既然問題不大，為什麼你不直接改掉就好了呢？即使你不願意改寫我的程式，你也要指出我的程式哪裡有問題需要改寫，而不是另外又去制定一套規格，然後卻跟我說架構差異不大，在我看來那是完全不同的。
到後來我就說，現在的問題是你們的工程師不願意動手做測試，只打算用想像的方式來判斷問題，即使我又改好了另外一個版本，他如果也不去測試，到頭來像現在的這種情形還是會再發生的。
會議過程中我們這邊總共四個人，對方有三個人，我們這邊由我當主力，大陸人被我說到最後漸漸理虧了，最後才勉強答應我，他們會做測試，而我這裡暫時不修改我的程式，等到他們先做完測試，要修改哪些地方再告訴我。
這整件事情的進行過程使我覺得很不愉快，有許多進度的問題，規格的問題，上層主管們都做的很差，甚至在問題發生的時候，他們也缺乏判斷是非對錯的能力，只會認為發生問題的人就是一個麻煩。至於像大陸工程師的那種不尊重人的毛病，還有他的那種做事方式，卻很少有人去指責與糾正，若從我的角度去批判那個人，倒有點顯得我是在逃避責任了。
不過好在我的工作是有完成進度的，我的程式已經給了對方，是對方不去做測試，這是很明顯可以看出來的。
真希望早一點完成自己的計劃，去做一些更有成就感的事。