为什么我们常忘记使用正则表达式
有这么一个奇怪的现象，设计人员常常忘记使用一个非常了不起的发明：正则表达式。他们宁愿自己实现非常复杂的字符串处理逻辑，在一堆if、else里面晕头转向，面对变化的需求感觉束手无策。
今天系统出现一个错误，判断一个电话号码类型的时候出现错误，误将一个0133开头的号码当作中国电信的号码。在一番寻找后，认为错误可能在一段程序里。打开程序的配置，定义了各种通配府、开闭范围标记、号码头，比较复杂。查到最后，是这个配置的解释程序出现了错误。配置中有一个项目：以01开头的号码属于中国电信。这个配置的位置在0133的前面，程序又没有使用最长匹配，而是用的最快匹配，从而导致了错误。错误很简单，但是比较隐蔽，开发人员找了半天。
更麻烦的是，现在这个错误不好改了。系统已经运行了很长的时间，配置项目的序号不敢改，添加配置项目也要评估一下影响有多大。改程序也很麻烦。
系统里面很多地方有这样的判断，判断字符串的开头、结尾、长度、区间……全是使用if－else的判断。有了新业务，现有的配置规则不一定能支持，修改起来一定很麻烦。
为什么不用正则表达式呢？判断规则大大的简化，程序逻辑简单了，可配置性强，完全是数据驱动的形式，测试起来也更容易，万一有了错误，改改表达式就行了。需求变化也不怕，有什么串不能用正则表达式来表示呢？
还有什么情况下可以使用正则表达式呢：输入框的合法性检查，命令行的解释，字符串的替换，IP地址的范围界定……
应该把“正则表达式”五个字写在纸条上，贴在墙上。在设计的时候，要提醒自己不要忘记使用这么一个伟大的小发明。
今天系统出现一个错误，判断一个电话号码类型的时候出现错误，误将一个0133开头的号码当作中国电信的号码。在一番寻找后，认为错误可能在一段程序里。打开程序的配置，定义了各种通配府、开闭范围标记、号码头，比较复杂。查到最后，是这个配置的解释程序出现了错误。配置中有一个项目：以01开头的号码属于中国电信。这个配置的位置在0133的前面，程序又没有使用最长匹配，而是用的最快匹配，从而导致了错误。错误很简单，但是比较隐蔽，开发人员找了半天。
更麻烦的是，现在这个错误不好改了。系统已经运行了很长的时间，配置项目的序号不敢改，添加配置项目也要评估一下影响有多大。改程序也很麻烦。
系统里面很多地方有这样的判断，判断字符串的开头、结尾、长度、区间……全是使用if－else的判断。有了新业务，现有的配置规则不一定能支持，修改起来一定很麻烦。
为什么不用正则表达式呢？判断规则大大的简化，程序逻辑简单了，可配置性强，完全是数据驱动的形式，测试起来也更容易，万一有了错误，改改表达式就行了。需求变化也不怕，有什么串不能用正则表达式来表示呢？
还有什么情况下可以使用正则表达式呢：输入框的合法性检查，命令行的解释，字符串的替换，IP地址的范围界定……
应该把“正则表达式”五个字写在纸条上，贴在墙上。在设计的时候，要提醒自己不要忘记使用这么一个伟大的小发明。
