【软件的一致性】
软件本身固有复杂性、一致性、易改变性、不可见性等特点。
本文作者： 常柱
（有改动）
一致性是降低系统复杂性和使其行为更加明显的强大工具。如果一个系统是一致的，这意味着相似的事情以相似的方式完成，而不同的事情以不同的方式完成。 一致性创造了认知杠杆：一旦你学会了在一个地方如何做某件事，你就可以利用这些知识立即理解其他使用相同方法的地方。如果系统没有以一致的方式实现，开发人员必须分别了解每种情况。这需要更多的时间。
一致性可以减少错误。 如果一个系统是不一致的，两种情况可能看起来是相同的，但实际上它们是不同的。开发人员可能会看到一个看起来很熟悉的模式，并根据之前遇到的模式做出错误的假设。另一方面，如果系统是一致的，基于熟悉的情况做出的假设将是安全的。一致性使开发人员工作更快，错误更少。
更大范围的一致性是构件重用技术。
一致性的例子:
一致性可以应用于系统的多个级别。这里有几个例子：命名： 一致的方式使用名称的好处，如微软推荐的匈牙利命名法。
编码风格： 现在开发组织通常有样式指南，它将程序结构限制在编译器强制执行的规则之外。现代风格指南解决了一系列问题，比如缩进、大括号放置、声明顺序、命名、注释和对被认为是危险的语言特性的限制。样式指南使代码更容易阅读，并可以减少某些类型的错误。
接口： 具有多个实现的接口是一致性的另一个例子。一旦您理解了接口的一个实现，任何其他实现都会变得更容易理解，因为您已经知道它必须提供的特性。
设计模式： 设计模式是某些常见问题的普遍接受的解决方案，例如用户界面设计的模型-视图-控制器方法。如果您可以使用现有的设计模式来解决这个问题，那么实现将会进行得更快，更有可能工作，而且您的代码对读者来说也更容易理解。
不变量： 不变量是变量或结构的一个总是为真的属性。例如，存储文本行的数据结构可能强制一个不变式，即每行以换行字符结束。不变量减少了必须在代码中考虑的特殊情况的数量，使对代码的行为进行推理变得更容易。
数据表达、数据库: 采用前后一致的或标准数据格式。
确保一致性:
一致性很难保持，特别是当许多人长时间从事一个项目时。一组人可能不知道另一组人建立的惯例。新来者不知道这些规则，所以他们无意中违反了这些约定，并创建了与现有约定冲突的新约定。以下是一些建立和保持一致性的建议:
文档： 创建一个文档，列出最重要的总体约定，比如编码风格指南。将文档放置在开发人员可能看到的位置，例如项目 Wiki 上的显眼位置。鼓励新加入团队的人阅读文档，并鼓励现有的人每隔一段时间就阅读一次。各种组织的一些风格指南已经在网上发布;考虑从其中之一开始。
对于更本地化的约定(如不变量)，请在代码中找到适当的位置来记录它们。如果你不把这些惯例写下来，其他人就不太可能遵循它们。
强制规约： 即使有很好的文档，开发人员也很难记住所有的约定。执行约定的最佳方法是编写一个检查违规的工具，并确保代码不能提交到存储库，除非它通过了检查器。自动检查器对于低级语法约定特别有效。
我最近的一个项目有行终止字符的问题。一些开发人员在 Unix 上工作，行被换行终止;其他的工作在 Windows 上，行通常由一个 carriage-return 后跟一个换行来结束。如果一个系统上的开发人员对先前在另一个系统上编辑过的文件进行了小的编辑，那么编辑器有时会将所有行终止符替换为适合该系统的行终止符。这给人的感觉是文件的每一行都被修改了，这使得跟踪有意义的更改变得很困难。我们建立了一个约定，即文件应该只包含换行，但是很难确保每个开发人员使用的每个工具都遵循这个约定。每当一个新的开发人员加入这个项目，我们就会经历一连串的线路终止问题，而那个开发人员就会适应这个约定。
我们最终通过编写一个简短的脚本解决了这个问题，这个脚本在将更改提交到源代码存储库之前自动执行。该脚本检查所有已修改的文件，如果其中任何一个包含回车，则将中止提交。该脚本还可以手动运行，以修复损坏的文件，方法是用换行替换载波返回/换行序列。
这立即消除了问题，并帮助培训了新的开发人员。
代码审查为执行约定和对新开发人员进行约定教育提供了另一个机会。 代码评审人员越是吹毛求疵，团队中的每个人就会越快地了解约定，代码就会越干净。
入乡随俗： 最重要的是惯例，每个开发人员都应该遵循这句古老的格言“入乡随俗”。在处理新文件时，请查看现有代码的结构。是否所有的公共变量和方法都在私有变量和方法之前声明？这些方法是按字母顺序排列的吗？变量在 firstServerName 中使用“camel case”还是在 first_server_name 中使用“snake case”？当你看到任何看起来可能是约定的东西时，跟着它走。在做设计决策时，问问自己是否在项目的其他地方也做了类似的决策;如果是，找到一个现有的示例，并在新代码中使用相同的方法。
不要改变现有的惯例 抵制“改进”现有公约的冲动。有一个“更好的主意”并不足以成为产生矛盾的借口。你的新想法可能确实更好，但是一致性对不一致性的价值几乎总是大于一种方法对另一种方法的价值。在引入不一致的行为之前，问自己两个问题。首先，您是否有重要的新信息来证明您的方法是正确的，而这在旧的约定建立时是没有的?第二，新方法是否更好，值得花时间更新所有旧的用法?如果您的组织认为这两个问题的答案都是“是”，那么就继续进行升级;当你完成的时候，应该没有任何旧的惯例的迹象。但是，您仍然面临其他开发人员不知道新约定的风险，因此他们可能在将来重新引入旧的方法。总的来说，重新考虑已建立的约定很少能很好地利用开发人员的时间。
别做过了头:
一致性不仅意味着相似的事情应该以相似的方式去做，还意味着不同的事情应该以不同的方式去做。如果您过于热衷于一致性，并试图强制将不同的东西放在相同的方法中，例如对真正不同的东西使用相同的变量名，或者对不适合该模式的任务使用现有的设计模式，那么您将创建复杂性和混乱。只有当开发人员确信“如果它看起来像 x，那么它实际上就是 x”时，一致性才会带来好处。
结论:
一致性是投资心态的另一个例子。确保一致性需要一些额外的工作：决定约定的工作、创建自动检查器的工作、寻找类似的情况以在新代码中模拟的工作，以及在代码评审中培训团队的工作。 这种投资的回报是您的代码将更加明显。开发人员将能够更快、更准确地理解代码的行为，这将使他们工作得更快，bug 更少。
原文链接
https://t.cn/A6wjnc7i
namo-amitabhaya！ https://t.cn/Rf37NIb
软件本身固有复杂性、一致性、易改变性、不可见性等特点。
本文作者： 常柱
（有改动）
一致性是降低系统复杂性和使其行为更加明显的强大工具。如果一个系统是一致的，这意味着相似的事情以相似的方式完成，而不同的事情以不同的方式完成。 一致性创造了认知杠杆：一旦你学会了在一个地方如何做某件事，你就可以利用这些知识立即理解其他使用相同方法的地方。如果系统没有以一致的方式实现，开发人员必须分别了解每种情况。这需要更多的时间。
一致性可以减少错误。 如果一个系统是不一致的，两种情况可能看起来是相同的，但实际上它们是不同的。开发人员可能会看到一个看起来很熟悉的模式，并根据之前遇到的模式做出错误的假设。另一方面，如果系统是一致的，基于熟悉的情况做出的假设将是安全的。一致性使开发人员工作更快，错误更少。
更大范围的一致性是构件重用技术。
一致性的例子:
一致性可以应用于系统的多个级别。这里有几个例子：命名： 一致的方式使用名称的好处，如微软推荐的匈牙利命名法。
编码风格： 现在开发组织通常有样式指南，它将程序结构限制在编译器强制执行的规则之外。现代风格指南解决了一系列问题，比如缩进、大括号放置、声明顺序、命名、注释和对被认为是危险的语言特性的限制。样式指南使代码更容易阅读，并可以减少某些类型的错误。
接口： 具有多个实现的接口是一致性的另一个例子。一旦您理解了接口的一个实现，任何其他实现都会变得更容易理解，因为您已经知道它必须提供的特性。
设计模式： 设计模式是某些常见问题的普遍接受的解决方案，例如用户界面设计的模型-视图-控制器方法。如果您可以使用现有的设计模式来解决这个问题，那么实现将会进行得更快，更有可能工作，而且您的代码对读者来说也更容易理解。
不变量： 不变量是变量或结构的一个总是为真的属性。例如，存储文本行的数据结构可能强制一个不变式，即每行以换行字符结束。不变量减少了必须在代码中考虑的特殊情况的数量，使对代码的行为进行推理变得更容易。
数据表达、数据库: 采用前后一致的或标准数据格式。
确保一致性:
一致性很难保持，特别是当许多人长时间从事一个项目时。一组人可能不知道另一组人建立的惯例。新来者不知道这些规则，所以他们无意中违反了这些约定，并创建了与现有约定冲突的新约定。以下是一些建立和保持一致性的建议:
文档： 创建一个文档，列出最重要的总体约定，比如编码风格指南。将文档放置在开发人员可能看到的位置，例如项目 Wiki 上的显眼位置。鼓励新加入团队的人阅读文档，并鼓励现有的人每隔一段时间就阅读一次。各种组织的一些风格指南已经在网上发布;考虑从其中之一开始。
对于更本地化的约定(如不变量)，请在代码中找到适当的位置来记录它们。如果你不把这些惯例写下来，其他人就不太可能遵循它们。
强制规约： 即使有很好的文档，开发人员也很难记住所有的约定。执行约定的最佳方法是编写一个检查违规的工具，并确保代码不能提交到存储库，除非它通过了检查器。自动检查器对于低级语法约定特别有效。
我最近的一个项目有行终止字符的问题。一些开发人员在 Unix 上工作，行被换行终止;其他的工作在 Windows 上，行通常由一个 carriage-return 后跟一个换行来结束。如果一个系统上的开发人员对先前在另一个系统上编辑过的文件进行了小的编辑，那么编辑器有时会将所有行终止符替换为适合该系统的行终止符。这给人的感觉是文件的每一行都被修改了，这使得跟踪有意义的更改变得很困难。我们建立了一个约定，即文件应该只包含换行，但是很难确保每个开发人员使用的每个工具都遵循这个约定。每当一个新的开发人员加入这个项目，我们就会经历一连串的线路终止问题，而那个开发人员就会适应这个约定。
我们最终通过编写一个简短的脚本解决了这个问题，这个脚本在将更改提交到源代码存储库之前自动执行。该脚本检查所有已修改的文件，如果其中任何一个包含回车，则将中止提交。该脚本还可以手动运行，以修复损坏的文件，方法是用换行替换载波返回/换行序列。
这立即消除了问题，并帮助培训了新的开发人员。
代码审查为执行约定和对新开发人员进行约定教育提供了另一个机会。 代码评审人员越是吹毛求疵，团队中的每个人就会越快地了解约定，代码就会越干净。
入乡随俗： 最重要的是惯例，每个开发人员都应该遵循这句古老的格言“入乡随俗”。在处理新文件时，请查看现有代码的结构。是否所有的公共变量和方法都在私有变量和方法之前声明？这些方法是按字母顺序排列的吗？变量在 firstServerName 中使用“camel case”还是在 first_server_name 中使用“snake case”？当你看到任何看起来可能是约定的东西时，跟着它走。在做设计决策时，问问自己是否在项目的其他地方也做了类似的决策;如果是，找到一个现有的示例，并在新代码中使用相同的方法。
不要改变现有的惯例 抵制“改进”现有公约的冲动。有一个“更好的主意”并不足以成为产生矛盾的借口。你的新想法可能确实更好，但是一致性对不一致性的价值几乎总是大于一种方法对另一种方法的价值。在引入不一致的行为之前，问自己两个问题。首先，您是否有重要的新信息来证明您的方法是正确的，而这在旧的约定建立时是没有的?第二，新方法是否更好，值得花时间更新所有旧的用法?如果您的组织认为这两个问题的答案都是“是”，那么就继续进行升级;当你完成的时候，应该没有任何旧的惯例的迹象。但是，您仍然面临其他开发人员不知道新约定的风险，因此他们可能在将来重新引入旧的方法。总的来说，重新考虑已建立的约定很少能很好地利用开发人员的时间。
别做过了头:
一致性不仅意味着相似的事情应该以相似的方式去做，还意味着不同的事情应该以不同的方式去做。如果您过于热衷于一致性，并试图强制将不同的东西放在相同的方法中，例如对真正不同的东西使用相同的变量名，或者对不适合该模式的任务使用现有的设计模式，那么您将创建复杂性和混乱。只有当开发人员确信“如果它看起来像 x，那么它实际上就是 x”时，一致性才会带来好处。
结论:
一致性是投资心态的另一个例子。确保一致性需要一些额外的工作：决定约定的工作、创建自动检查器的工作、寻找类似的情况以在新代码中模拟的工作，以及在代码评审中培训团队的工作。 这种投资的回报是您的代码将更加明显。开发人员将能够更快、更准确地理解代码的行为，这将使他们工作得更快，bug 更少。
原文链接
https://t.cn/A6wjnc7i
namo-amitabhaya！ https://t.cn/Rf37NIb
今日阅读培养孩子从绘画开始。不要教小孩形象，孩子在6.7岁才有必要接受专业的培训，而儿童需要到9岁后才会对绘画，音乐有鉴赏能力。一岁的孩子可以通过肘部带动手做反复纸上运动，到了两岁可以画流畅的线条及将圆闭合。她们热衷于语言带给绘画的自信，对于孩子我们要做的就是提供纸笔，然后安静的在旁边看着他们即可。
#令和时代# 【为什么改元“令和”，竟然成了日本程序员的魔咒？】
从5月1日开始，日本就彻底告别了平成时代，步入令和元年。
而且由于天皇更替举国欢庆，日本往年最长只有 5 天的黄金周将被加量到 10 天，也就是说，日本社畜即将迎来梦幻般的十连休！
这也是自1948年日本颁布《假日法》以来的首个十连休，但对于已经到来的令和元年十连休，也不是每个人都欢天喜地。因为伴随着新元号而来的，是一系列烦死人的系统年号变更问题。
作为全球唯一保留了年号和皇历的国家，尽管日本在日常生活中也普遍使用公历，但无论是银行、证券、保险等金融机构还是行政机关，都仍在使用年号纪元。
因此，从2019年5月1日正式改元开始，日本所有的电脑和软件系统都必须在当天同步改用新年号。而在日的国际 IT 公司，更需要将公历与日本皇历切换，将日本使用的软件版本日期更新为新年号纪元。
而且，1989 年开启的长达 30 的年平成时代里，互联网信息技术迅猛发展，比起上次改元时，今日的网络系统对人们生活的影响已不可同日而语。如今电脑、手机、保险券甚至 ATM 机都已经接入了计算机系统，对于日本程序员来说，让所有的计算机都在5月1日同步改元，这还是历史上从未有过的大挑战……
以至于一位 Twitter 网友吐槽到：在改元的祝贺气氛里，IT 从业者看到这幅画面却只想骂人。
身为 IT 业不相关人士、隔壁看戏人员，大家可能无法理解日本程序员“随时都会被拖出去祭天”的恐慌，然而在程序员甚至日本政府看来，改元确实是件关系国计民生的大事。
令和开年有点慌
尽管从小接受西式教育、业余热衷研究虾虎鱼的明仁天皇非常特立独行，2016 年就宣布自己将打破惯例成为第一位生前退位的天皇，然而新年号还是要等到退位前一个月才能揭晓。对于需要做出“技术性调整”的各行业人员来说，真正留给他们的时间只有短短一个月。
于是，新年号甫一公布，全日本上下立刻紧张了起来！
一些选择手动升级的中小企业为了继续利用已经打印出的文件，开始抢刻令和年号橡皮章，橡皮章一时洛阳纸贵。
办公用品制造商 Hanko21 的总经理泷口修表示，自己从4月1日起就开始亲自下场和 20 多名工人加班加点在工厂里赶制令和图章，但是他的努力没有维持多久，因为“年号公布三天后，我们囤积的橡胶原料就全部用完了。”
而为了在一个月内对旗下的八十多个行政单位计算机系统进行快速调整，名古屋市政府拨款四亿八千万日元进行加班加点在5月1日前完成了赋税、社会保障等重要系统的改造，但还有更多“不紧迫”的系统会留在1至7日由程序员加班完成……
当然，最发愁的还是电脑系统老旧过时的私人小企业。因为更新系统耗资巨大，有些日本公司的电脑系统已经二三十年没有更新过了，几乎和平成年代一样古老，根本无法自动升级。
面对改元，山梨县北杜市的一家老字号点心铺可能是少有的能淡然处之的实体之一。这家店的老板在30多年前昭和时代预定账本时，把 50 本订成了 5000 本，整个平成时代过去了账本还没用完。
元号变成令和后，起码老板今后只用改一个字了（昭和改令和）。
中小公司改元乱成一锅粥，而那些自称“我好了！”的公司，也纷纷出现大漏洞。
一个月前微软表示，将通过云端向日本客户推送令和更新包。而5月1日上午，就有还在加班的日本上班族表示 Excel 日期混乱，不仅显示出平成31年5月1日这种不存在的日期，公历年份还变成了 5 位数。
与此同时，北海道银行、北陆银行和横滨银行开始发生大面积 ATM 机混乱事故。所有转账日期都变成了1989年5月7日，至于被转走的钱到底去了哪里利息怎么计算谁也不知道（毕竟在系统里这已经是一笔来自1989年，存了 30 年的钱），不过这三家银行表示他们有信心尽快修复错误。
而这场旷日持久的改元混乱，还要持续到5月7日。
在2019年5月1日内阁会议后的新闻发布会上，日本内阁官房长官菅义伟宣布，尽管5月1日年号就已经更替为令和，但改元工作要到5月7日才会结束。“我们不会影响公众生活。”菅义伟说，但日本民众对此存疑。
菅义伟菅义伟
何事惊慌？
也许有人不理解，“年号不过是一个名字而已，会造成这么大的影响吗？”
事实是，年号与日本的计算机系统和各种证件的计数系统息息相关，一旦出现混乱，轻则证件失效，重则金融交通系统崩溃。
比如著名的“驾照迷思”。平成29年发放的驾照有效期至平成32年（2020年），然而在这个日期来临前日本就已经进入了令和时期，理论上平成32年是不存在的。
人工操作时还比较好加以判断，然而对于六亲不认的计算机来说，所有有效期在平成31年4月30日以后的契约合同证件证券，全部都是无效的。
此时，就需要程序员们上阵迅速修改系统，保证人们的正常生活了。
而在平成12年（即2000年）2月，因为日本程序员忽略了2000年是个大闰年，没有在系统里加入29日，这一天在北海道札幌市拿月票卡通勤的上班族统统被堵死在路上，造成了交通瘫痪和大面积迟到。
虽然犯这种低级错误的真实原因已经不得而知，但总觉得换做用公元纪年的话，应该挺好发现2000年是闰年的。
因为年号和计算机系统实在过于烦人，维基百科专门在日语“元号”条目中加入了“元号与计算机”这一栏，长篇大论元号的种种弊端。
日本程序员受的苦，外人真的没法数。
令和之后会更慌
尽管令和的劫已经快渡完了，但日本程序员的夜明还远远没有来到……
在2019年开年之初，有一位程序员小姐姐在 Twitter 上提醒大家：“比起新元号对应问题，还有更需要担心的事哦～昭和 100 年就快要到了哦～”
她的言论立刻引发大量转发，评论区一片程序员的悲鸣。
日本的昭和时代从1926年开始，1989年结束，历经 64 年，因此昭和年号最多只有 64 年。那么让日本程序员听了就要跪的昭和 100 年又是什么鬼？
这还要归功于前代程序员绵延三十年甩来的巨锅。
1989年，日本经历了昭和到平成的改元，那时的电脑还比较原始，内存只有 64-128KB，每一个 bit 都至关重要，程序员只能想方设法从各种地方抠内存。于是，在记录日期时，年份都只会记录后两位，比如1989年1月1日，就会被记录为 890101。
然而一旦到了2000年，巨大的 bug 就出现了。由于只保留后两位数，银行里面的电脑可能把2000年解释为1900年，从而算错利息甚至直接消除账面记录，而你在1999年12月31日23：59分打了三分钟的电话，电话局的账单却可能出现负数计数而导致系统崩溃（-100年+3分钟）。
这就是大名鼎鼎的千年虫问题。
在全球同行都为千年虫焦虑不已的同时，先代日本程序员们却灵机一动……
如果继续延用昭和年号计数的话，千年虫问题就会被推后 25 年，即昭和 100 年（ 2025 年）才归零！比别人多了 25 年，肯定足够我们解决问题了！
所以如今日本政府和企业的系统里表面上看起来一团和气，实则一直在底层为昭和续命。
然而眼看令和元年都来了，清算的日期还有六年就要到了，新一代日本程序员们面对 COBOL 等上古语言开发的系统却更加迷惑了。
“银行和大企业的基础系统像古董一样脆，怎么也不能更新……！”“30年40年前的代码根本没有说明文档，剩下的部分也没有追加变更记录！”“法律规定的5年追诉期早就过了，因为人事变动，当年的负责人全都找不到了。”
日本程序员大型崩溃，只能祈祷到 2025 年自己已经转行了……
当然看热闹不嫌事大的人也是存在的。
“从平成到令和时代，昭和100年问题即将到来，好像被遗忘的时代的亡灵要来了，这不是很帅吗？”
到那时面对“时代的亡灵”，日本程序员会不会想出新的甩锅办法，那就是另一个故事了。 至于当年甩锅的老程序员则表示，“谁能想到 20 年后你们还在用这一套啊！！”
从5月1日开始，日本就彻底告别了平成时代，步入令和元年。
而且由于天皇更替举国欢庆，日本往年最长只有 5 天的黄金周将被加量到 10 天，也就是说，日本社畜即将迎来梦幻般的十连休！
这也是自1948年日本颁布《假日法》以来的首个十连休，但对于已经到来的令和元年十连休，也不是每个人都欢天喜地。因为伴随着新元号而来的，是一系列烦死人的系统年号变更问题。
作为全球唯一保留了年号和皇历的国家，尽管日本在日常生活中也普遍使用公历，但无论是银行、证券、保险等金融机构还是行政机关，都仍在使用年号纪元。
因此，从2019年5月1日正式改元开始，日本所有的电脑和软件系统都必须在当天同步改用新年号。而在日的国际 IT 公司，更需要将公历与日本皇历切换，将日本使用的软件版本日期更新为新年号纪元。
而且，1989 年开启的长达 30 的年平成时代里，互联网信息技术迅猛发展，比起上次改元时，今日的网络系统对人们生活的影响已不可同日而语。如今电脑、手机、保险券甚至 ATM 机都已经接入了计算机系统，对于日本程序员来说，让所有的计算机都在5月1日同步改元，这还是历史上从未有过的大挑战……
以至于一位 Twitter 网友吐槽到：在改元的祝贺气氛里，IT 从业者看到这幅画面却只想骂人。
身为 IT 业不相关人士、隔壁看戏人员，大家可能无法理解日本程序员“随时都会被拖出去祭天”的恐慌，然而在程序员甚至日本政府看来，改元确实是件关系国计民生的大事。
令和开年有点慌
尽管从小接受西式教育、业余热衷研究虾虎鱼的明仁天皇非常特立独行，2016 年就宣布自己将打破惯例成为第一位生前退位的天皇，然而新年号还是要等到退位前一个月才能揭晓。对于需要做出“技术性调整”的各行业人员来说，真正留给他们的时间只有短短一个月。
于是，新年号甫一公布，全日本上下立刻紧张了起来！
一些选择手动升级的中小企业为了继续利用已经打印出的文件，开始抢刻令和年号橡皮章，橡皮章一时洛阳纸贵。
办公用品制造商 Hanko21 的总经理泷口修表示，自己从4月1日起就开始亲自下场和 20 多名工人加班加点在工厂里赶制令和图章，但是他的努力没有维持多久，因为“年号公布三天后，我们囤积的橡胶原料就全部用完了。”
而为了在一个月内对旗下的八十多个行政单位计算机系统进行快速调整，名古屋市政府拨款四亿八千万日元进行加班加点在5月1日前完成了赋税、社会保障等重要系统的改造，但还有更多“不紧迫”的系统会留在1至7日由程序员加班完成……
当然，最发愁的还是电脑系统老旧过时的私人小企业。因为更新系统耗资巨大，有些日本公司的电脑系统已经二三十年没有更新过了，几乎和平成年代一样古老，根本无法自动升级。
面对改元，山梨县北杜市的一家老字号点心铺可能是少有的能淡然处之的实体之一。这家店的老板在30多年前昭和时代预定账本时，把 50 本订成了 5000 本，整个平成时代过去了账本还没用完。
元号变成令和后，起码老板今后只用改一个字了（昭和改令和）。
中小公司改元乱成一锅粥，而那些自称“我好了！”的公司，也纷纷出现大漏洞。
一个月前微软表示，将通过云端向日本客户推送令和更新包。而5月1日上午，就有还在加班的日本上班族表示 Excel 日期混乱，不仅显示出平成31年5月1日这种不存在的日期，公历年份还变成了 5 位数。
与此同时，北海道银行、北陆银行和横滨银行开始发生大面积 ATM 机混乱事故。所有转账日期都变成了1989年5月7日，至于被转走的钱到底去了哪里利息怎么计算谁也不知道（毕竟在系统里这已经是一笔来自1989年，存了 30 年的钱），不过这三家银行表示他们有信心尽快修复错误。
而这场旷日持久的改元混乱，还要持续到5月7日。
在2019年5月1日内阁会议后的新闻发布会上，日本内阁官房长官菅义伟宣布，尽管5月1日年号就已经更替为令和，但改元工作要到5月7日才会结束。“我们不会影响公众生活。”菅义伟说，但日本民众对此存疑。
菅义伟菅义伟
何事惊慌？
也许有人不理解，“年号不过是一个名字而已，会造成这么大的影响吗？”
事实是，年号与日本的计算机系统和各种证件的计数系统息息相关，一旦出现混乱，轻则证件失效，重则金融交通系统崩溃。
比如著名的“驾照迷思”。平成29年发放的驾照有效期至平成32年（2020年），然而在这个日期来临前日本就已经进入了令和时期，理论上平成32年是不存在的。
人工操作时还比较好加以判断，然而对于六亲不认的计算机来说，所有有效期在平成31年4月30日以后的契约合同证件证券，全部都是无效的。
此时，就需要程序员们上阵迅速修改系统，保证人们的正常生活了。
而在平成12年（即2000年）2月，因为日本程序员忽略了2000年是个大闰年，没有在系统里加入29日，这一天在北海道札幌市拿月票卡通勤的上班族统统被堵死在路上，造成了交通瘫痪和大面积迟到。
虽然犯这种低级错误的真实原因已经不得而知，但总觉得换做用公元纪年的话，应该挺好发现2000年是闰年的。
因为年号和计算机系统实在过于烦人，维基百科专门在日语“元号”条目中加入了“元号与计算机”这一栏，长篇大论元号的种种弊端。
日本程序员受的苦，外人真的没法数。
令和之后会更慌
尽管令和的劫已经快渡完了，但日本程序员的夜明还远远没有来到……
在2019年开年之初，有一位程序员小姐姐在 Twitter 上提醒大家：“比起新元号对应问题，还有更需要担心的事哦～昭和 100 年就快要到了哦～”
她的言论立刻引发大量转发，评论区一片程序员的悲鸣。
日本的昭和时代从1926年开始，1989年结束，历经 64 年，因此昭和年号最多只有 64 年。那么让日本程序员听了就要跪的昭和 100 年又是什么鬼？
这还要归功于前代程序员绵延三十年甩来的巨锅。
1989年，日本经历了昭和到平成的改元，那时的电脑还比较原始，内存只有 64-128KB，每一个 bit 都至关重要，程序员只能想方设法从各种地方抠内存。于是，在记录日期时，年份都只会记录后两位，比如1989年1月1日，就会被记录为 890101。
然而一旦到了2000年，巨大的 bug 就出现了。由于只保留后两位数，银行里面的电脑可能把2000年解释为1900年，从而算错利息甚至直接消除账面记录，而你在1999年12月31日23：59分打了三分钟的电话，电话局的账单却可能出现负数计数而导致系统崩溃（-100年+3分钟）。
这就是大名鼎鼎的千年虫问题。
在全球同行都为千年虫焦虑不已的同时，先代日本程序员们却灵机一动……
如果继续延用昭和年号计数的话，千年虫问题就会被推后 25 年，即昭和 100 年（ 2025 年）才归零！比别人多了 25 年，肯定足够我们解决问题了！
所以如今日本政府和企业的系统里表面上看起来一团和气，实则一直在底层为昭和续命。
然而眼看令和元年都来了，清算的日期还有六年就要到了，新一代日本程序员们面对 COBOL 等上古语言开发的系统却更加迷惑了。
“银行和大企业的基础系统像古董一样脆，怎么也不能更新……！”“30年40年前的代码根本没有说明文档，剩下的部分也没有追加变更记录！”“法律规定的5年追诉期早就过了，因为人事变动，当年的负责人全都找不到了。”
日本程序员大型崩溃，只能祈祷到 2025 年自己已经转行了……
当然看热闹不嫌事大的人也是存在的。
“从平成到令和时代，昭和100年问题即将到来，好像被遗忘的时代的亡灵要来了，这不是很帅吗？”
到那时面对“时代的亡灵”，日本程序员会不会想出新的甩锅办法，那就是另一个故事了。 至于当年甩锅的老程序员则表示，“谁能想到 20 年后你们还在用这一套啊！！”
✋热门推荐