一、緣起
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時，會話保存。
下圖是優化後的結果，僅供參考
