如果你對電腦技術問題沒興趣，本文就跳過吧！

我的車牌辨識系統建置工程仍在進行之中，整個工程的前端是從各路口(預計30~35個測站)錄影中的監視器畫面取得影像，先簡單篩選辨識「有無」車牌，確定有車牌的影像就由網路後送，集中到警局的伺服端電腦。再由伺服端的辨識程式辨識車牌，辨識結果及圖檔再與資料庫結合，配合ASP.NET網頁顯示與查詢辨識結果。可以看出整個工程還蠻浩大的，我也開始動用學生幫忙建立資料庫與網頁，這是他們上課時我教過的，學生也很興奮(還有錢賺咧)。

但是很氣結的是：不知道是我的上游廠商還是警局的技術人員，一直抱怨我的前端程式跑太慢，堅持要測試使用別的方法擷取監視器畫面，但是他們的建議在我看來都是很荒謬的餿主意，不用試，光用心算就知道會更慢十幾倍！但是任憑我寫多少次Email解釋，老闆傳回來的訊息仍是對方堅持要測試他們建議的方案，我必須配合改程式，而且是越改越越慢。改程式因為不是增加程式功能，反而是刪減，所以不算難，只是做這些必然失敗的事肯定延誤工程，其他真正該關心的事情還很多。最終延誤工程的責任誰來擔呢？是歸咎於我的技術太爛嗎？

各位可以看到系統架構刻意將辨識分為前後端，前端只看「有無」車牌不作完整辨識就是要節省時間，依照我的設計每秒可以抓到約10張原始畫面篩選有無車牌，完整辨識較為耗時就送到後端處理。前端的資料流是持續的，所以必須很快，處理慢了就會有車子漏掉。但是多數畫面並沒有車牌，真正需要後送的照片估計約每兩秒鐘一張。所以後面的伺服器可以一對多，處理很多測站傳回來的照片。

問題出在他們前端的電腦老舊，他們嫌我的程式處理速度不夠快會漏車，於是說某軟體可以直接將AVI影片檔中的影格還原成照片，最高一秒可以切出30張照片，「效能比我的程式好多了！」堅持要用那個軟體抓原始照片，再由我的程式辨識，那就絕對不會漏車了！我的回信有一段分析如下：

我最初的程式機制是：

抓螢幕(顯示卡記憶體)影像→辨識→有車牌的照片用共用磁碟機傳到Server存檔

接下來因為對方不願放寬設定使用共用磁碟，於是改用FTP傳檔案的流程：

抓影像→辨識→有車牌的照片存到前端磁碟→FTP程式讀取這些檔案→傳到Serve再次存檔(多一次存檔，已經變慢約兩三倍)

現在業主要求的是：

由錄製程式錄製為AVI後存檔→由其他程式讀AVI解壓縮後分為影格存檔→我的程式讀取檔案分析有無車牌→無車牌者刪除檔案，有車牌者用FTP後送

這個奇怪的過程多出非常多存取、刪除磁碟檔案、壓縮與解壓縮影片為影格的程序，而且全部程式仍然要由同一台已被認定工作過重跑不夠快的電腦執行！這好像告訴癌末病人「你就是欠缺運動才生病的，以後天天要上健身房，早起跑五千公尺、有機會要參加馬拉松與鐵人三項比賽…」這樣當然不會治好病人，只會讓他提早斃命。

真的很荒謬且誇張！乍看之下建議中好像有一些電腦名詞，仔細一看都是來鬧的！怎麼可能會認為這樣複雜無效率的程序會有可能更快呢？鐵定是沒上過電腦概論，還相信程式裡面有神！某些程式可以超越硬體限制。

之前建議他們使用共用磁碟的方式將前端的檔案後送，就是因為FTP必須傳實體磁碟檔案，前端必須多存一次磁碟。他們堅持不願使用共用磁碟機制，要用FTP，事後證實我說對了，系統速度慢了近三倍！結果他們不是開始尊重我的專業判斷，而是建議其他更荒謬的「解決方案」！還要我繼續配合？OMG，最終只能無奈但是審慎地跟我的直屬老闆說：

有關AVI切圖的事已討論很久，我覺得到了必須審慎應對的時候了。

如果這些堅持來自你的想法，我們應該再開個會詳細討論一下！

如果這個堅持來自對方某位技術人員的想法，應該安排我當面與他討論。

如果只是對方技術能力差，應該可以經過這些技術討論順利解決；

如果是對方別有居心，想凸顯自己的地位或存心搞砸此案，

我們就必須有些自衛的動作，譬如我信中的這些技術分析要公開，表示我們早有正確評估，如果對方堅持做這些傻事，我們也配合之後最終延誤進度，就不必扛這個責任了。