背景
工作中接触的一些零碎语录，颇有感触，总结记录下来。思考，探索，学习，成长
工作态度
这是一个很基本的素质(军规/规范)，找不到人要升级，不要把一个问题，自己不好意思在那里解决，这样只会让一个问题愈发严重。只要升级了就是团队的问题了，大家群策群力去解决这个事情。
遇到问题处理不了，就上报给ld，ld解决不了就继续上报。必须要做到这个事情。不要害羞，ld就是用来被你们烦的。如果你们ld觉得你烦，我觉得你们可以怼到ld上面，因为ld必须要帮你们兜这些事情
要充分发表自己的见解，不要这么内向，你都觉得不合理了还不提出来，那什么时候提出来呢。不管是在哪个公司，不合理的地方，忍声吞气的把它消化掉，不建议这样做，主动点
有急事的时候打电话，不要企业微信，企微这个消息，不要觉得人家看过你的消息，就真的看到了。已读不回就当做人家没看到就行了
研发规范
不要去怕这些研发规范，这些规范是用来帮助你们的
举个bad_case，某个同学在敏感时间改了个小地方，自己评估这个变更很小，就偷偷摸摸自己发布了，刚好他写了个bug，影响很多上下游。
因为每个人评估自己代码都是迷之自信的，觉得自己写的代码永远不会出问题，你们应该也会有这种想法
一般原则都是无需求不代码，要开发上线的代码都是要关联需求的，评审也是为了一起评估需求背景、优先级和是否需要测试之类的
故障和排查
面向失败设计。任何一个有可能产生故障异常，都要想一下怎么做预案处理和规避
出现故障优先解决问题，恢复服务，再安排问题根源调查
提问题的时候要提供详细的信息，数据库挂了（又一万个那个跑来跑去）是很不专业的说法，究竟是连不上，还是时间变得很慢
风控
如果都是不同的人的话，说明是非国伙行为，非国伙的就不好监测，只能是加强内容审核和排查
黑产是不会消失的
系统设计
(1) OCP开放封闭原则
软件实体对扩展是开放的，对修改是关闭的。
对于一个新的需求，对软件的改动应该是通过增加代码来实现的，而不是通过改动代码实现的。
开发过程中，应该把可能会频繁变动的部分抽象出来，当需要变动时，只需要去实现抽象即可。
(2) SRP单一职责原则
对类来说职责应该是单一的，一个类只能对外提供一种功能，变动这个类的理由只能有一个。
单一职责降低各种职责的耦合度，如果一个类负责多个职责，那么改动某一职责时可能会影响类行使其他职责的能力。
每个模块（类/方法）只承担单个职责，避免多个职责交叉，从而导致修改其中一个功能的时候，影响另外一个功能。
(3) ISP接口隔离原则
一个接口对外只提供一种功能，不同功能应该通过不同的接口提供，而不是把多种功能都封装到一个接口中。
否则的话，可能有的客户只需要功能A不需要功能B，但是提供A功能的接口内还封装了功能B，这就造成了客户被迫依赖某种他们不需要的功能。
模块之间不需要知道对方的内部实现逻辑，并且一个模块的内部改变也不会影响到另一个模块（黑盒原理）