唉，今天仍然是被感冒困扰的一天，一大早发烧到38.5，腰酸背痛千辛万苦的走了两公里去了东方医院发热门诊。
不得不说发热门诊的服务还是很好的，人少，地方小，好处就是快，看病，验血，测核酸，CT，缴费，拿药，都在这前后不到20米的区域内搞定，还不用排队。各种化验的速度也很快，最后的核酸大概两小时出结果，出了结果就把我放回家了。
配的药和我前几天吃的也没啥区别，不过就是猛一点，本来一天两颗的改成了一天四颗，另外还有祖传的金花清瘟冲剂，相当的不好吃。希望明天发烧能好吧。
继续修炼，正式进入了干货部分，首先讲得是不要代码重复，这一段的篇幅比较长，大体讲了两个例子：
一个是处理文本，确实处理文本是非常容易产生重复逻辑的地方，比如第一个改进将负数的处理统一来做，减少了重复的逻辑，赞同。第二个改进是将处理打印格式的逻辑做了封装，好处是打印格式调整起来更方便。这点存疑，疑在两点，第一就这段代码而言封装以前的逻辑就很直白了，封装后反而有点绕。第二虽然封装后对格式的修改在同一个地方进行，但是对于不同场景需要不同格式的需求反而会较难满足。
这个和我们处理接口的情况有点像，一开始我们的希望是一段代码处理不同客户的同一类接口，因为其中有大量重复的逻辑，但是渐渐的我们希望即使对同一类接口不同客户之间也能做到一定的隔离，减少相互影响对代码的的稳定性更加重要。
去掉重复代码当然是好的，但在复杂环境中的重用特别是业务逻辑类的重用一定要小心，确保你已经充分理解了被重用代码的意图。然后被重用的这段代码要保持稳定不要随意变动。相反工具类的重用因为其含义清晰，逻辑稳定通常是没问题的。
第二个例子是定义了一个类，线段类包括起点，终点和长度，咋一看是没有问题的，不过实际上线段长度这个属性是完全由起点和终点推出的，在这个类的定义里就不适合作为一个类的属性，更合适的是作为类的一个方法实时计算获取。
这个例子非常好，有一些导出量如果存成了实体量，将会带来非常多而复杂的刷新逻辑，最好能避免(少数情况因为性能原因需要提前计算的除外)。此外这种情况在我们产品中也大量存在，碰到要小心。
网友评论