明明如月的技术博客

正式成为支付宝的预备讲师。 有幸成为公司代码评比的大众评审。

很多人想提升没人带，有人分享资料或者经验，收费不舍得花钱，免费又不珍惜。 所以对于大多数人而言，该走的弯路一步都不会少。

工作中，大家使用线程池时。 一方面根据《阿里巴巴Java 开发手册》的规定，不要允许使用 Executors 来创建线程池，用以规避资源耗尽的风险之外。 另外一个很容易忽略的地方是，使用常规线程池时会造成 "Tracer上下文丢失"，会造成 traceId 丢失，压测标记丢失等，需要根据公司的框架采用包装器模式对 Runnable 或 Callable 进行二次封装。

设计接口的时候要秉承着：“封装复杂度” 的理念，避免让上游感知不必要的业务和技术复杂度。 案例： 比如某个视频是否是热点的判断依据是，视频的优先级大于 1000，视频的有效期在 1个小时以内。 工作中居然会有同学会选择将优先级大于 1000 和有效期大于 1 小时的视频的有效期时间置为空，让前端再根据优先级大于 1000 且存在有效期作为热点的判断条件。 后端都已经判断到这个程度了，顺手加个“是否热点” 的标识简直是轻而易举，前端压根不需要感知优先级和有效期，只需要根据后端的返回值判断是否是热点，如果是热点展示对应样式即可。 这种案例还有很多，这种是非常不专业的行为。

记入职支付宝一周年。一年坛发，酒香四溢。初心不改，方得始终。以后继续努力，加油！

最近很多大厂校招缩招，社招几乎只出不进，甚至裁员。 最近一两年需要参加校招的同学要早点投入复习，早点抓住重点，对校招的严峻性要有明确的认识。

【经验分享之缓存】 工作中使用缓存时，要斟酌好缓存的 key，权衡好缓存过期时间的合理性。 [1] 思考清楚缓存的维度，如日期维度？用户维度？ 案例：比如对某天是否是交易日缓存，如果使用统一的 key（如 isTradingDay ），缓存10分钟，当跨天时，会导致交易日判断错误。这种情况下，缓存 key 应该是“前缀+ 日期”更合理。 [2] 思考清楚缓存的目的，了解清楚待缓存数据，尽量设置相对保守的缓存时间，尽量可以通过动态配置可以灵活调整缓存时间（方便测试；方便应急）。 案例：由于特殊原因，下游数据错误，找你清理缓存，结果没有清理缓存的途径，也无法调整缓存时间，这就尴尬了。

什么是好代码？ 首先要能满足功能要求，然后要符合高内聚、弱耦合，能够封装必要的复杂度，能够符合设计模式的几大原则，如单一职责原则、迪米特法则、开闭原则等。 可读性强，不能一个函数一百行以上，逻辑让人困惑。 要符合一些细节规范，如符合《阿里巴巴 Java 开发手册》对日志、异常处理等方面的规定。

代码是软件的基石、血液。字如其人，代码亦如是。程序员如果对代码没追求就会少了很多乐趣，热爱可抵漫长岁月，未来再接再厉。

【自己专坑自己之使用小众工具类】 建议大家多使用知名的工具类库，少用一些小众类库，否则很容易被坑。 不要轻易使用非知名的三方类库。 如需要对模板进行解析，尽量使用 freemarker 而不是 beetle。 最近遇到一个坑，使用 Beetle 对模板进行渲染时，出现奇奇怪怪的偶发异常。 还有建议优先使用知名三方类库而不是自己再写一次，知名三方类库单测非常充分，而且经历很多公司的验证，自己写的方法很容易因为单测不充分，边界条件考虑不充分而出现 BUG 或者没有充分的性能考虑导致性能问题。

【自己专坑自己之违反单一职责原则】 一个函数设计用来判断某种类型的内容是否展示，伪代码如 SomeCard card = cards.stream().findFirst(特定条件).orElse(null); if(card == null) return; if(canShow(card)) { //省略一些业务逻辑 } // 判断的函数定义 boolean canShow(SomeCard card) 由于此类型的每种卡片的判断逻辑都一样，因此选取第一张卡片进行判断即可。 后续需求变更，需要在展示卡片时为卡片填充一些特定属性。 显然应该在返回 show 之后再进行处理，但是填充的属性又依赖于是否展示，同学为了省事，直接在 canShow 里面对card 进行属性填充。 线上代码审查时，看到该函数用于判断是否展示，没特别仔细看发现没问题。 实际上 canShow 干了两件事，一个是判断是否可以展示，一个是进行属性填充。 结果只对第一张卡片进行了属性填充，出现了 BUG。 这是一个典型违反单一职责造成的 BUG，希望大家能够吸取经验和教训，在开发时尽量遵循设计原则，少踩坑。 另外，特别强调，我们写代码的原则一定是怎么合理怎么写，而不是这嫌麻烦，那嫌麻烦，很容易给自己埋坑。 宁愿多定义一个对象，也不要因为省事违反单一职责。