日本人寫的代碼，套用我們經常說的一句玩笑話，那就是：“這是要被吊起來打一頓的！”，很多接觸過日本程序員寫的程序的人可能都有這么一種感受，那就是他們編寫的程序非常穩，很少出現問題。關于日本人寫的程序穩這個問題，我同事是這么跟我說的：“日本人寫的東西什么都是標準化的，是經過長時間迭代的，所以它穩！”，可事實是這樣嗎？我同事很快就被“打臉”了！

事情是這樣的，我們公司接到一個項目，需要對一個日本公司生產的設備進行改造，其中就涉及到了軟件部分，日本原廠軟件代碼在設備上位機上是有的，但是客戶特別要求，不允許我們直接修改原廠代碼，怕出問題，所以我們公司軟件只能以中間件的形式存在，即在日本原廠程序和設備之間做一個中間層。

既然是做中間層，軟件與設備之間的通訊協議我們就必須得搞明白了，于是，我們就研究起了日本原廠的代碼。

日本原廠的代碼是使用VB6寫的，據說已經有將近20年的歷史了，代碼量非常大，光跟PLC通訊的地址就有一萬多個！其中，我們需要了解的，就有一千多個，當然，也不是直接在這一千個PLC地址里面做讀寫操作，還是開辟一千多個新地址出來，做轉發。

整個改造過程涉及到一系列復雜的流程，這里不細說，也不重要，總之，看日本人寫的代碼，我是看得昏天黑地的。

接下來，就到了本文的核心部分，我在瀏覽一段比較重要的算法部分的代碼的時候，發現了一個有意思的地方，那就是這段代碼里面有很長一段if-else結構，那么它們是干嘛的呢？

原來，這個日本的設備廠商在我國很多地方都有業務，但是，他們的甲方也會有一些個性化需求，上述if-else結構，其實就是為了滿足不同甲方的需求而寫的！

說到這里，很多程序員小伙伴可能就恍然大悟了吧？

其實說白了，因為每個甲方的需求都不一樣，但是，可能僅僅是細微的改動，如果單獨把整個項目直接復制一份出來，后期維護又困難，可能（我猜的）日本廠商在寫這個設備的代碼的時候，插件式開發還沒怎么普及，所以，他們干脆就直接把甲方給枚舉了，通過if-else結構來判斷當前運行的程序屬于哪個甲方，再決定用什么算法！

好，接下來就應該根據國內程序員的脾氣，開始興師問罪了！

首先，就是日本程序員在寫這段代碼的時候使用的是if-else而不是switch-case結構（VB6里面是select-case）！

關于if-else還是switch-case，其實在國內程序員之間的爭論也不少，很多程序員認為switch-case不管是語法優雅程度還是性能都是要優于if-else的，因此，遇到本文中提到的這種情況，就應該使用switch-case。

但我覺得，這程序跑了將近二十年了，如果因為這個原因導致性能有損失，人家日本程序員估計早就改了，不會等到現在還放在那，恰恰因為它還在那，說明人家這么寫，并沒有對程序產生任何影響。

所以，這點我們不糾結！

那么，開頭說的“應該被吊起來打”的原因是什么呢？

很簡單，因為泄露機密了！

首先，既然是使用同樣的代碼，所以，不管行業是否一樣，說明這個日本廠商的甲方的生產工藝應該都是差不多的，因此，在代碼里面直接使用if-else來判斷甲方是誰，問題點就在：如果甲方技術人員看得懂代碼，那么可以直接通過代碼的算法，摸清楚代碼里面其他家的工藝。

這就要命了，要知道，使用同樣設備的不同工廠，大概率都是競爭對手，競爭對手之間能夠互相摸清楚對方生產過程中的某些細節，那么是不是代表著他們之間可以通過這些細節來改進自己或者給競爭對手制造障礙呢？

這些東西由不得我們去細想，如果我是這個日本廠商的甲方，我肯定肺都氣炸了！

我不知道這個屬于不屬于失誤，如果不能使用插件式開發，我覺得至少也要做到在交付代碼的時候，把一些其他甲方的特殊需求的代碼給他刪掉，避免給其他甲方帶來麻煩！

像我看到的這個日本廠商提供的代碼，至少在我們公司如果出現這樣的狀況，相關負責人至少都是要去被拉去坐冷板凳的，尤其是核心算法如果外泄，報警都是有可能的！

結語

后來，我跟我同事在討論這個問題，我同事呵呵一笑，跟我說：“你知道，現在國內很多工廠的設備都是日本人做的，一旦日本人宣布不再提供新設備或者突然宣布停止維護這些設備，你知道意味著什么嗎？”

不用說，我都知道意味著什么，雖然說現在這些設備國內并不是沒有人能做出來，但短時間內如果設備出問題，那就是意味著工廠停擺！

所謂的“卡脖子”不是一下子給你勒死了，而是讓你短時間內喘不過氣來！

同事還跟我說了這么一件事情，說國內某大廠的經理級別的人物有一次跟日本某廠商鬧得有點不愉快，最后的結果是這個經理向廠商道歉而結束！

這種事情放在國內廠商這里，你敢想象？跟甲方鬧了別扭，最后甲方跟你道歉？怎么可能！

所以，工廠設備的國產化，勢在必行，而且必須得先發制人！