日本程序员竟然这样干，放在国内，这绝对是要“被吊着打”！

日本人写的代码，套用我们经常说的一句玩笑话，那就是：“这是要被吊起来打一顿的！”，很多接触过日本程序员写的程序的人可能都有这么一种感受，那就是他们编写的程序非常稳，很少出现问题。关于日本人写的程序稳这个问题，我同事是这么跟我说的：“日本人写的东西什么都是标准化的，是经过长时间迭代的，所以它稳！”，可事实是这样吗？我同事很快就被“打脸”了！

事情是这样的，我们公司接到一个项目，需要对一个日本公司生产的设备进行改造，其中就涉及到了软件部分，日本原厂软件代码在设备上位机上是有的，但是客户特别要求，不允许我们直接修改原厂代码，怕出问题，所以我们公司软件只能以中间件的形式存在，即在日本原厂程序和设备之间做一个中间层。

既然是做中间层，软件与设备之间的通讯协议我们就必须得搞明白了，于是，我们就研究起了日本原厂的代码。

日本原厂的代码是使用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来判断甲方是谁，问题点就在：如果甲方技术人员看得懂代码，那么可以直接通过代码的算法，摸清楚代码里面其他家的工艺。

这就要命了，要知道，使用同样设备的不同工厂，大概率都是竞争对手，竞争对手之间能够互相摸清楚对方生产过程中的某些细节，那么是不是代表着他们之间可以通过这些细节来改进自己或者给竞争对手制造障碍呢？

这些东西由不得我们去细想，如果我是这个日本厂商的甲方，我肯定肺都气炸了！

我不知道这个属于不属于失误，如果不能使用插件式开发，我觉得至少也要做到在交付代码的时候，把一些其他甲方的特殊需求的代码给他删掉，避免给其他甲方带来麻烦！

像我看到的这个日本厂商提供的代码，至少在我们公司如果出现这样的状况，相关负责人至少都是要去被拉去坐冷板凳的，尤其是核心算法如果外泄，报警都是有可能的！

结语

后来，我跟我同事在讨论这个问题，我同事呵呵一笑，跟我说：“你知道，现在国内很多工厂的设备都是日本人做的，一旦日本人宣布不再提供新设备或者突然宣布停止维护这些设备，你知道意味着什么吗？”

不用说，我都知道意味着什么，虽然说现在这些设备国内并不是没有人能做出来，但短时间内如果设备出问题，那就是意味着工厂停摆！

所谓的“卡脖子”不是一下子给你勒死了，而是让你短时间内喘不过气来！

同事还跟我说了这么一件事情，说国内某大厂的经理级别的人物有一次跟日本某厂商闹得有点不愉快，最后的结果是这个经理向厂商道歉而结束！

这种事情放在国内厂商这里，你敢想象？跟甲方闹了别扭，最后甲方跟你道歉？怎么可能！

所以，工厂设备的国产化，势在必行，而且必须得先发制人！