由于业务需要，比如歌曲，我们需要对部分歌曲开放限免的功能，而且需要限制开放限免的场景。比如这首歌在场景A免费，在场景B收费。
先说正确的做法，下发另外一个字段比如free_token，通过这个字段判断业务来源，和判断是否可以免费。free_token是随着对应的场景查询时下发的，是变化的。即同一个歌曲的free_token不是唯一的。
现在有另外一种情况，想对现有的业务做限免（前端业务是不认free_token的）。这时可以把歌曲id使用free_token的值来下发，后续通过歌曲id来判断是否符合限免。
- 这样做有个前提，就是前端业务没有使用歌曲id来做唯一性的业务（因为这是歌曲id是变化的），比如收藏。所以使用这个方案，要充分测试，而且可能还有其他不兼容的场景。
职场中的“善于沟通”和“高情商”
很多人普遍认为，不跟人起冲突，能得到别人满意的评价，那么就一定程度上证明他高情商以及沟通能力好。
然而，这种观点真的正确吗？在某些情况下，这样做是否必要呢？
先说结论，在高人才密度的公司中，基本也应该确实是这样。因为大家能相互理解，目标是做正确的事，简明扼要节约时间提升沟通效率，尊重别人及尊重自己，对有能力的人表示钦佩并愿意向他们学习。
相反在低密度人才的公司或者公司领导人不开明等情况下，情况就有所不同。举例来说，如果公司内部人际关系不够平等，或者产品地位高于技术。产品需求缺乏认真性和逻辑性，技术人员只能被动接受，甚至放任不管，那么这种沟通方式就变得有问题了。技术人员默默忍受、妥协，把自己变成产品的需求完善员，即使自己的时间被浪费也不可惜。
当金钱和地位给予足够时，技术人员选择妥协也可以理解。否则，那简直就是对自己的不尊重。
这件事情你需要跟进吗？
在工作中，大多数情况下，大家都喜欢积极跟进事情的人。但有时候，这事情你真的要跟进吗？
关于这个问题，其实并不是0或1这么简单。很多时候取决于公司的工作氛围或者分工、以及你对自己的定位等情况。
在工作中，在相当长的时间里，我执行力特别强的人。我的原则是事事有结论（不给别人挖坑，不让事情烂尾）。所以我会很积极的跟进事情。
但渐渐的，我开始怀疑，有些事情是你需要跟进的吗？
以技术人员为例。你需要把自己当项目经理那样跟进事情吗？答案是分情况。
有些情况你需要跟到底，而有些情况你只需要尽你责任即可，毕竟你有更重要的事情去做，或者说你的价值不应该在这里虚耗。
以下情况可能需要你跟进
- 属于你自己责任范围内的事情
- 这个事情是你主导发起的事情，关于你绩效等
- 你的公司的范围就是要你做项目经理，而且你也能接受（精神损失费不够另说）
- 你个人有意愿通过这种方式发展自己的综合素质或人脉等等
其他情况不需要跟进到底
- 已经当天反馈结果并提供解决问题的方向
- 需求方并未声明事情的优先级，自身也未跟进（说明不重要，不要经常给别人做无用功）
- 技术侧不应该每件事都跟进那么深入，尽了自己的义务即可，毕竟要合理分工
- 关于管理人员：不能以治标不治本的方式解决问题，技术领导应该表明立场，也是以后类似问题的处理立场，而不是一味认怂服从，累死下面的兄弟，而且没啥成长，纯粹苦力活
- 关于自身的话语权：作为基层员工，有些事情就是推不动，这个大家都很清楚，做到及时反馈的义务即可
再浅谈接口的安全性和回调机制
最近的工作原因，涉及到接口充权益的接口安全性问题，这里趁热再说说个人看法
基于之前写的这篇使用回调机制提高接口安全性继续聊。上次扩展中提到是不是可以使用非对称加密，替换回调验证？目前我所负责的业务确实使用这种方式。
业务中要对接多个渠道，渠道需要调业务的接口来加权益，为了安全性，目前的做法是由渠道自己生成RSA私钥，提供RSA公钥到业务这边。渠道使用私钥生成签名，业务这边则使用公钥解密验证，从而保证请求是合法的。
其实这里还是有潜在漏洞，之前的文章也提到过，如何保证私钥不泄漏？虽然说保证私钥不泄漏是渠道自己的问题，但是多年的经验告诉我，大多数公司并没有很好的保存这些私钥的方法。按照我的猜想，这些私钥在公司内部会被经常拷贝发送，至少开发人员基本都有办法知道的。万一知道私钥的人后续离职了作恶呢？
而我们经常对接一下小渠道，参差不齐。尽可能保证渠道的安全也是我们作为平台要积极考虑的问题。
所以个人的看法，即使使用RSA保证签名的合法，还是要提供回调的能力，提供给渠道，通过二次校验保证知道私钥的人也无法直接从自己的私人客户端发起请求并成功加权益。毕竟回调的请求是到达渠道方的正式服务器，要在正式服务器上线恶意代码，靠谱的公司都有一定的限制和管控。
扩展
- 接口一般都会分外网访问和内网访问，我们平常要注意避免只能内网访问的接口暴露给外网访问，因为大多数情况下，我们的内网接口会安全性低一点。
打工人心态应该是怎样的？
先来两段经典的话:
一
为众人抱薪者，不可使其冻毙于风雪；
为大众谋福利者，不可使其孤军奋战；
为自由开路者，不可使其困顿于荆棘。
二
愿中国青年都摆脱冷气，只是向上走。
不要听自暴自弃者的话。
能做事的做事，能发声的发声。
有一份光，发一份热。
就令萤火一般，也可以在黑暗里发一点光。
不必等候炬火。
迫于由于现实的压迫，大家普遍焦虑，也会在工作中认怂，即使是不合理不正确负能量的等等；
这些其实都能理解，不管是迫于生活压力，还是对方给得实在太多等原因；
但有时，希望我们可以
- 我们只是个打工的，有些东西不必过度较真
- 虽是打工但也人格独立和自尊，不必唯唯诺诺
- 有自己的时间分配和生活，不必紧盯信息，实在紧急对方会打电话
- 不必焦虑，事事回复，根据自身情况，适当保持高姿态
- 换位思考，容人之度，当然容人不是纵容
- 工作时专注和高质量，不浪费自己时间
Reference
ToB业务随便讲讲
以下内容格局比较小，仅做个人记录
从我个人接触过的ToB和ToC业务讲，有以下特点（当然肯定不是一定对的，毕竟业务形态实在太多，我没真正接触过的，就不提了）：
- ToC的业务团队，一般只做若干个业务模块；不同的业务有不同的团队
- ToB的业务团队，需要对接几乎所有业务，进而对外提供平台能力
关于ToB业务的规范
- ToB的业务，出于通用性，会制定各种规范由客户进行对接
- 当然，所谓的规范，有时候是看哪方处于强势
- 弱势方即使作为平台也要给客户做定制化
- 比如一个简单的回调规范，客户不配合，需要平台这边按照他们的规范适配
- 但同样支付宝和微信作为平台，难道要支付宝和微信去适配每个接入方？无非是谁更强势的问题。
- 从这方面看，可以一定判断出这个公司目前的状况
提升自己职场中的“可替代性”
怎么看待职场中的“业务壁垒”？
在我的工作中，曾经发生过这样一件事：有一天我们在讨论，能不能实现一个业务通用组件，让各个业务接入，提升业务需求的开发效率等，这时候有一个同事就跟我说：‘那如果真的实现的话，那你这边的业务就啥都没了’，言外之意就是我这边“没事做了”。我给他的回答是：‘没关系，只要是有意义，有价值，对公司是正确的就行’
那么？我真的那么爱公司吗？
- 当然不是，我只是觉得应该做自己认为正确的事，顺便说一下漂亮话忽悠一下。
在工作中，你们到遇到很多“业务壁垒”。通俗来讲，这个东西只有他会，或者短期内只有他能搞定。你甚至会觉得一股恶心，就是很乱很难受，并惊叹对方的忍耐力。
然而，无数的事实证明了，这个世界不会因为没有谁就不行。
而我的原则是：做正确的事，不制造业务壁垒；保持出色的整理学习能力，输出业务文档，让自己随时可替换，甚至寻找可以替换自己的人；不做狭义对自己有利的事，尽量做广义对公司有利的事。
具体来说，可以这样阐述
- “业务壁垒”不是我认同的核心竞争力，甚至混乱的“业务壁垒”不是我能忍受的工作体验；
- 出色的整理学习能力，坚信长期主义，才是我认同的核心竞争力；
- 我在提升自己可替代性的同时，也是在提升自己的“不可替代性”；而有些地方，并不需要“不可替代性”的人；
- 提升自己可替代性，其实也是在保持业务的稳定；不会因个人而大受影响，甚至我因此可以放心度假，因为我会的东西，别人也可以快速学会和处理；
关于“可替代性”另外补充：
- 增加自己的安全感（休假可以找到别人）
- 增加别人（比如上级）的安全感（万一找不到，出意外有其他人解决）
- 个人清高，一定程度上，喜欢更高维度的不可替代性
对服务架构中的聚合层理解
以前刚毕业的时候，进入一个组，叫中间层，那时候还懵懵懂懂不知道想表达啥意思
图来源网上，已未知出处
这个组是直接给app提供接口的，主要的职能大概有以下
- 业务适配
- 服务聚合
- 数据展示
- 安全隔离
聚合服务，简单的来说就是聚合底层的各个业务系统，给用户端应用提供接口
- （直接对接用户前端的接口服务，手机app，网站，h5等用户终端）
- BFF —— Backends for frontends（服务于前端的后端），是为了让后端API满足不同的前端使用场景，而演进出来的一种模式。
- BFF避坑指南
那么这个组有存在的必要吗？特别是现在服务内部都微服务化，很多业务服务都是直接对app提供接口的。
先从表面上看看使不使用聚合层各自的特点和好处
- 使用聚合层
- 前端需要对接的接口比较少，对前端来说比较友好
- 聚合层可以聚合底层业务的接口，相比前端直接对接，有些业务场景可以提升接口性能
- 能根据前端的业务场合适配和统一改动，便于快速迭代和打补丁等
- 可以根据前端对数据的不同使用场景，减少不必要的性能损耗
- 如果统一接口，入参就会变得复杂，增加前端的对接成本
- 不使用聚合层
- 有些业务场景，减少多一层调用，有利于提升性能
- 业务接口可以复用，不需要聚合层再包一层，减少开发时间
- 前提：整个公司统一接口规范，同个接口可以复用于不同app
- 分散接口故障风险。一个业务故障，不会导致其他业务也故障。
- 相对使用聚合层，聚合层的服务不可用，整个app都会受影响
- 使用聚合层
仔细想想，简单理解，其实使用聚合层就是水平架构，不使用就是垂直架构；根据康威定律，其实公司决定使用哪种方案，一定程度还受公司组织关系的影响。
提外话：由于前后端分离的流行。聚合层服务有时候会由前端团队来维护。使用node服务用于聚合页面和后端接口，从而提升性能。相对于传统的聚合层，前端的聚合层比较轻量化，基本是无状态服务，不存储数据和加工数据，纯粹做聚合接口和页面。
扩展
职场中“马后炮”现象
职场中有一种奇怪又平常的现象：没出事就没人重视，出事了就各种马后炮。
以软件开发人员平常应对的事情为例，这里其实有一种无奈的解释：
- 需求这么多还没做完，有什么充分的理由去重视这个问题？
- 你把事情做好了，完全不出事，怎么证明是你的功劳？
普通的干实事的程序员，最讨厌跟行外人谈收益。就像把代码写好了，自然后续维护成本就低了。但是硬要把他转化为节约多少人力。只想一心老老实实写代码的程序员，好心做个事情还要花费心力想办法给你解释，久而久之自然是多一事不如少一事。所谓劣币驱逐良币，有追求的程序员自然离开了，剩下的可想而知。
那么，难道这个问题就无解吗？
- 当然不是。要建立在不干涉和充分信任的基础上。CEO相信CTO，CTO当然知道把代码写好的好处，所以也不需要底下做事的人过分解释。
- 但实际上很多公司，CTO不做CTO的事，只是专注向上汇报，还把汇报的事情层层外包给下面的人。导致本应该自己屏蔽，让底下安心做事的事情，层层透传，苦了干实事的人。而自己就成了汇总PPT的汇报员。
最后讲一个故事
魏文王问扁鹊曰：“子昆弟三人其孰最善为医？” 扁鹊曰：“长兄最善，中兄次之，扁鹊最为下。” 魏文王曰：“可得闻邪？” 扁鹊曰：“长兄于病视神，未有形而除之，故名不出于家。中兄治病，其在毫毛，故名不出于闾。若扁鹊者，镵血脉，投毒药，副肌肤，故名出闻于诸侯。” 魏文王曰：“善。”
善战者无赫赫之功
防患于未然的人不如亡羊补牢者获得的赞誉多
小团队管理经验
转眼工作十年了，从20年10月开始，断断续续做了近三年的小团队管理，这里作简要总结一下。
所谓小团队管理，其实就是现在说的虚线组长，需要写代码、给团队提供指导等，但是由于不是高级别大领导，不需要应付很多烦人的破事。从这层来看，挺适合我这种性格的人。
以下是以小团队为背景来总结的，格局显得较小；当然每个人的观点不一样，不一定是正确的理解。
核心要点（对自己）
- 情商、基于别人的角度思考
- 个人习惯采取对内温和对外强硬的方式；当然结合自身情况和环境具体选择；这个方法可以让你更好的理解人和事情；我不认为所谓的“情商高”就是“老好人”。
- 以身作则
- 以自己为榜样，让团队其他成员看到正确的做事方式等；包括技术方案、沟通方式等，当然包括一些无法避免的脏活累活等；用高效和人性化等方式应对 。
- 令人信服的技术功底
- 小团队管理的特点，就是领头的人也是需要写代码和干实事，而且跟团队成员的距离是最近的；需要保持自己良好的技术功底，才能更好的给团队提供有效的建议；另外作为有追求的技术人，谁都想跟着比自己优秀的人一起共事。
- 保证成员尽量免干扰、休息时间如无必要不打扰
- 这一点是我基于人性化的角度考虑的，有些人可能会觉得不重要。给团队提供深度工作的环境，才能提升效率；在一些不紧急的事情少，要做到不随意打扰，减少团队的负面情绪。对应上面第一条，将心比心，每个人都想要良好的工作体验。
- 真诚、谦虚、透明
- 尽量保持团队一定的透明度，减少不必要的暗箱操作。大部分情况下不需要开会，只需要一篇简明扼要的文档，即可让团队快速了解事情的内容。团队成员也在发展，要清楚有一天他们的能力会超过你。而我一直坚持的做法是，业务上坚持写文档，尽量减少业务壁垒（也是为自己放假偷懒准备），技术上提供合理的建议，不遗余力的提高自己的“可替代性”。
- 认清自己。领导需要团队的力量才能发挥作用。不要错把平台的能力当作自己的能力。把公司的给予当作自己的给予。
- 人性化管理
- 现在很多公司都追求狼性文化，说着各种假话哄下属为自己加班干活
- 个人管理经验理念是，先做人再做领导
- 如非必要。不严厉。许多人还没到那个层级就采取低端没人情味的管理方式。要和同事成为朋友，营造友好的工作环境，而不是一味向上管理。
- 尽量保持技术更新升级
- 在确保充分测试，稳定灰度的同时，适量的升级有利于系统的稳定，增加维护人员的积极性。这种东西无法直接给出具体收益，但应该长远考虑，一味的保守只会让技术越来越落后
核心要点（对团队）
- 聪明、叙述简明扼要、能抓重点
- 乐于分享、采用高效的分享手段（文章即可）、实事求是
- 有团队主人翁意识，主动了解业务
- 对技术原理好奇并积极探索
- 尊重别人的时间
- 跟进事情有反馈和结论
- 在正确的事情面前，敢于说不
- 重视自己的“可替代性”、免于个人单点、提升团队容错性
小团队技术管理者的事项列表
- 业务侧
- 快速满足需求
- 通用业务组件抽象
- 旧业务熟悉
- 定期删除无用代码，增加代码可维护性
- 遗留需求记录和跟进
- 业务知识文档化，方便查阅和备忘
- 需求上线时间定时跟进（你就是项目经理）
- 技术侧
- 旧业务梳理和重构
- 架构灾备和优化、资源隔离等
- 通用工具类封装
- 管理后台搭建 （解放技术）
- 服务异常监控（后端接口，前端APM等各个维度）
- 技术组件升级，提升团队技术广度
- 废弃业务下线，回收资源
- 业务技术调研，团队具备快速满足产品新需求的能力
- 分享，相互学习，个人认为文档就行了，会议实际上挺形式和浪费大家的时间
- 帮助review方案和代码
- 技术债务登记和逐步处理（分优先级[每个季度一定要完成一定比例的低优先级任务]，保持代码洁癖，不给后来人挖坑）
- 开发规范制定（避免后续维护混乱，也方便大家日常开发查阅）
- 开发阶段和上线阶段checklist，避免犯重复的错误，避免上线遗漏导致项目延期
- 技术面试
- 应急处理、日常维护等文档化（公开、透明、高效）
- 团队文档整理规划
- 新人指引
- 业务模块（服务模块、业务知识整理、业务交接记录、业务安全风险点）
- 工作规划（需求列表、技术规划、技术债务）
- 开发规范（项目上线流程、公共库说明、开发协议、服务架构图、业务逻辑开发套路等）
- 工作文档（应急、日常维护等）
- 常见问题处理导航
- 技术文档（技术型、分享类）
- 技术方案（日常需求上线方案归档）
- 复盘、故障报告
- 业务调研
- 其他备份