Scalzdp的专栏

正则表达式是一种字符串匹配的模式，可以用来查找、替换、验证字符串。虽然每个数据库对正则表达式的支持程度不同，但 MySQL 提供了相对完善的正则表达式支持，使用REGEXP或RLIKE关键字来实现正则匹配。

设计一个字段表，字段表的每一行就存储业务字段配置信息，然后具体的数据存在另外一张数据表中，然后通过字段表中的字段与数据表中的数据进行关联，这样我们就可以做到应该业务字段随意增减的需求。，他可以实现字段JSON格式的存储和查询，效率非常高，这里面我们通过JSON字段，进行存储信息，就可以做到对JSON字符串中的字段任意增加和删除操作。应对用户需求字段不确定，我们觉得有两种方案可以备选，第一种方案需要转换一下设计思路，后期维护字段比较灵活易于理解，第二种方案比较简单，编码更加容易操作。答案是肯定的当然可以。

方案一：读写分离如果写少读多，那么可以采用数据库主从库：多个从库副本负责数据的读取，主库负责写，从库从主库同步更新数据，保持数据一致。架构是设计上就是数据库主从同步，从库可以水平扩展，以应对更多的读的请求（如果用户请求量太大，可以通过负载均衡将请求分散到多个从节点数据库进行查询）。方案二：单库太大，数据库切分以应对单库数据量太大，也就是单个数据库中数据表交多，如何将数据库进行切分呢？方法还有多个，我觉得比较容易实施的有两种方案，第一种方案、垂直分库：把一个数据库的不同表放到不同的数据库里面去。

1.为什么会有夸夸奇谈的未来性呢？当我们谈到这个问题的时候，我们就要反思在需求理解和设计的时候对程序变动性的理解出现了偏差。“哦，我想我们总有一天炫耀做这事儿的”常常是一念之差导致的代码坏味道。总结有以下四点原因是经常导致出现夸夸奇谈未来性的原因。第一、经常在理解需求的时候主观的认为需求变动非常大，那么在设计过程中就会出现过度的设计。第二、追求设计模式的使用，经常对程序的不必要的地方进

为什么我们随意命名变量会是灾难性的决定？随意命名变量是编写代码的灾难性决定，我这里说的比较严重，但是为了强调编程过程中不要随意命名我们的变量。因为从以下三方面的理由是不允许我们在程序中随意命名变量的。首先在编程过程中，随意命名的变量会导致我们编写代码中弄乱数据传输的关系，因为人们通过混乱的字段会把字段的本意理解错误的，理解错误字段的意思就会把该字段用在本不该她使用的地方。其次，当你费尽

过长的参数

1.为什么会出现过大的类我们的编码过程中，不知不觉的就把一个类编写的非常的庞大。为什么会这样子呢？我想无非由两个理由，首先是编码过程中为了贪图一时的方面不想动手去添加一个类用来管理不属于原先这个类的职责。其次整个系统使用了太多的继承关系，无形中就会造成子类变得异常庞大。总之，如果想利用一个类做太多的事情，往往就会造成这个类变得异常庞大。2.过大的类会照成什么严重后果

重复的代码开发，在作为初级的程序员是经常遇见的，因为被要求做一些很固定且比较简单通用的模块，所以很容易就遇上功能相同的代码进行重复的开发了。1.为什么会有重复的代码重复的代码可能会出现编写人员抽象公有模块抽象公有功能的能力，可能来自我们开发方式过于老化固定了类之间的相互应用所以导致编写的某一个功能只适用一个特定的系统使用，可能来自我们的设计人员对项目框架设计考虑不够仔细，没有重用性的设

1.重构和核心思想我们一直在强调，程序中我们要不断的进行代码的重构，但是重构作为一种高度的脑力活动确实不易。为什么重构在一般的团队中不易推进呢？究其原因我认为有两方面的原因，第一、项目执行计划中不包括，团队只想更快的看到结果，没有规定时间用来重构，程序员可能有这方面的意识但是做了又不加入绩效所以也没有主动去重构的行动了。第二、没有一个统一的标准，每一个具体的开发人员都会按照自己认为的标