一、缘起
k8s改造，xx系统 用到了redis，解决了 缓存、分布式锁等常见问题。
主要是 x群 x浩 解决的。
xx系统,xx等其它系统，进行k8s改造，也需要解决这种问题。
但是呢，由于时间问题，两位小哥写的代码，不能简单配置就在其它项目用起来。
这里，涉及到 软件复用的问题。
另外，日常中发现的几个问题，正好顺手总结下：
1、沉迷技术细节，http、session、redis。
PM等非研发人员，或没有亲自参与的人，听不懂。
PM也是搞笑，明明一脸萌逼，还要装作认着听，想听懂的样子。
可行的办法也许是：哥哥，我听不太懂，可以换个表达方式吗。
2、需求还没搞清楚，技术实现还没想清楚，就慌忙coding去了。
一边做，一边改，最后还是苦了自己。
3、把技术实现和需求业务混为一谈。
产品、前端、后端，一起讨论问题。和产品过多去讲解“怎么实现”。
一个需求问题，能讨论几十分钟~甚至...
二、讨论点：软件复用、清晰表达、coding人员更好地与PM交流协同
一个人写的代码，另外一个人、另外一个项目、同一个项目，能不能尽可能少做重复劳动，就能立即复用前人的成果。
第1个图为xx系统代码，第2个图为xx系统代码，一看就是复制粘贴的。
如果其他项目需要使用，也只能复制粘贴再修改。
短期看，这是比较快的方式，但是从小组、部门、公司、个人积累角度，都很低效。
工作久了，各种常见问题，得有自己的一套解决方案，工具包。
这是第1个讨论点，软件复用，涉及到 标准化，目的是 提高效率。生产力提高了，个人价值才有提高的扎实基础。
第2个讨论点，在看这些代码的时候，不能直观地看出，写代码的人，他所有的真实意图。看了好几遍，才能看出真实意图是：
redis4部曲：redis本身的配置config，用SpringBoot自动扫描装配。
4部曲，解决了4个场景的问题：
1、传统的分布式Cache缓存，key-value
2、分布式锁，lock
3、分布式主键生成，PrimaryKey
4、分布式Session，解决的是使用Shiro时，会话保存。
第3个讨论点，干事的人，他的想法在他的大脑里，落实在行动里。
对比现实情况，有没有发现，研发人员大多被“PM”等其他人指挥呢？尤其是当研发人员，逆来顺受的时候。
归根结底，PM等角色 对接着客户需求、领导的需求，进而掌控产品、项目的需求、进度、发展。
项目原型，刻画需求。
项目验收，业务方感受到价值。
研发人员，说的标准一点，就是资源，随时可替换。
主导性、主动性问题，需要思考。
第4个讨论点，研发人员需要清晰表达自己的想法。
1、写代码之前，先把要解决的问题定义清楚，代码应该清晰可读，通过包结构、类名、方法名，就知道思路。
2、积极分享，多给别人讲自己的东西，才能提高自己的表达能力，理解每个人的特点。
在准备和写材料的过程中，更容易发现自己对某个点理解不够通顺，需要不断调整语法措辞、甚至全文结构。
3、与PM等人交流，少用http等技术术语。
与有技术背景的管理层交流，技术术语可以用一些。
与研发人员交流，可以多用技术术语。
4、准确表达，避免歧义
某糖果表述：A项目，把附件上传到了B项目。
B项目的PM，听了，有点担惊受怕，第一反应以为会影响B项目。
显然，又涉及到二次确认，甚至多人反复确认。
准确表述：A项目，通过B项目的API接口，把附件存到公共的文件服务器上了。
最佳表述：这是个纯技术问题，我们已经搞定了。如果你想了解技术细节，我再给你吧啦吧啦一遍。
如果PM听不懂，又想知道，那就用非技术语言，非技术词汇，把这个事简要描述下。
分层表达，单独讨论：
和PM等非技术人员，讨论问题，重点关注 价值、需求、业务规则、工期进度、其它一些想法。
技术，简单评估下 某个需求的难度，大概需要多久，就可以了。
技术怎么实现，研发人员多沟通，少和PM等人讨论这个问题，这是研发人员的核心本职工作。
技术细节，慎重讨论，诸如 http、redis、session，少谈。
三、redis4部曲，xx和xx，想表达的意思是：
redis4部曲：redis配置config，然后解决了4个场景的问题：
1、传统的分布式Cache缓存，key-value
2、分布式锁，lock
3、分布式主键生成，PrimaryKey
4、分布式Session，解决的是使用Shiro时，会话保存。
下图是优化后的结果，仅供参考
