文章目錄
農藥之坑，唯有陷入才知曉。每逢晉級賽，總要被打回原形。
前言
項目經歷了一個又一個，代碼擼了一遍又一遍，來來回回拷貝舊東西，似乎絲毫提不起興趣。
想要手持大刀隨意砍殺，卻發現根基便有問題，扎心不扎心。
與其盲目調整根基，不如從點擊積累，江河入海流，終將匯成汪洋大海！
首先簡單說明下目前項目中遇到的問題吧：
- 重複性功能較多；
- 需求不明確造成多次返工，大量時間消耗無腦擼碼微調中；
- 。。。
可能是項目的特殊性吧。也可能是我整體構思有問題，很直接的爲了趕所謂的進度，讓項目代碼中充斥了不少重複性的東西。
事情的起因源於某次懶得說明緣由，便直接截了部分截圖併發到羣裏，事後才發現這個各種不舒服。
一起先來看一下，之前“封裝”：
下面圍繞着此事例進行逐步分析，衍化。
開搞
當初封裝的原因就是後臺突然返回了一種類型，嗯，是挺突然的，突然的都沒關注這種類型，顯然針對 App 出現了問題。最原始的方案則是在每個地方無腦式 Copy，所謂簡單高（搞）效（笑）的代價，則是白白新增了冗餘代碼，且直接導致後續維護起來很是麻煩。
說實在的，自己看着咋也好說，實際發羣裏，突然感覺這段代碼寫的真 low。果斷諮詢我雞老大有什麼好的優化方案。
雞老大說的倆句話很有意義，在此分享下：
- 你可以做抽象，而不是抽方法；
- 抽象的東西不是業務，但是是根據業務形態做的。
Long long ago，曾以爲自己對於面向對象理解已經達到遊刃有餘，雞老大的一番話，讓我不得不再次審視自己，直面自己的漏洞。可惜，目前現有的能力只是停留在抽方法 😅，這裏就不過多說明了，某天可能幡然醒悟吧。
雞老大超級喜歡反問，聽取了我的思路後直接提示你這個寫法還有很大的改進空間，重複代碼太多了，怎麼改。
在 “仔細” 觀察封裝後的方法，在每種類型中都要實例化一個 Intent 並且傳遞對應的 id，方便後續根據 id 查看詳情。
知道了下刀子的地方，現在對此方法進行一下小手術：
- 簡單粗暴的使用一個 Intent，通過不同的 Type 實例化對應的 Intent 跳轉實例。
分分鐘改造完成：
美滋滋找雞老大得瑟去～
雞老大不緊不慢的來了句：還有很大的改進空間，你再想想。
經過上面一步，成功將 Intent 實例化精簡到 Only One。仔細觀察，每個 Type 下都對應類似相同的操作：
- 實例化即將跳轉的 Intent；
- 傳遞對應的 id 值
那我爲什麼不直接定一個私有化的專門處理 Intent 方法呢？不同的 Type 只需要給我對應的參數值即可。說幹就幹，改造後如下：
可以吧，嗯，我覺得還不錯。找雞老大得瑟去～
雞老大又說了，你這不行啊，還有很大改進空間，class 發給我，我來。
這咋能讓雞老大親自動手呢。😅😅😅 我來，我來。
雞老大又說了幾點：
- 去掉註釋，不明白你寫的是啥，難以理解；
- 如果我想單獨調用 when case 中某個方法呢？怎麼辦？
- 不要私自處理 error，對於可能會造成問題的需要 throws 出去；
- 一個方法只做一件事，同樣只用到了 id，爲什麼要傳遞 bean？後續有新需求可以拓展重寫方法呀；
- 首先你要保障別人來讀你代碼，一眼就知道你這個代碼是什麼意思。其次，做需求更多的是面向業務去代碼，可讀性是首要保障，其次纔是優雅性。而且你並不是爲了性能而去考慮去設計的。
最後，雞老大給出一條原則 （不喜勿噴，我老大話我奉爲經典，謝謝！） ：
安全性 > 可用性 > 可維護性 > 代碼簡潔 > 性能
針對雞老大提出繼續優化：
- case 中單獨提供對應處理方法，可單獨使用，方法名鑑名其意；
- 檢查代碼現有業務邏輯只需要一個 id 便可使用，將參數 Bean 替換爲具體參數；
- 提供方法不再處理 error 情況，而是直接 throws，由實際調用方處理；
針對以上調整後代碼如下：
End - 思考 🤔
從開始以爲的最優，到三番五次自認爲最優找雞老大點評，老臉吶。
不得不跪服雞老大，短短一個代碼片段，便能直擊痛楚，甚至我這寫代碼的人都忽略的跳轉多場景調用，多次頻繁拷貝，甚至後續沾沾自喜封裝了一個小方法。
寫代碼，不僅僅是寫代碼，如果單純的爲了寫代碼而寫代碼，爲了完成任務而寫代碼，寫出的代碼，真的難以自看，此處是對自己說。
冗餘的代碼和精簡的代碼相比；
依靠註釋纔可磕巴通讀代碼和單純通讀代碼便可知其意；
雜亂無章的代碼和良好設計的代碼；
。。。
捫心自問，還是想糊弄自己嗎？
路漫漫其修遠兮！
番外
問個小問題：
- 你有嫌棄過自己的代碼嗎？
- 怎麼處理的？