產品命名：以簡單有趣為榮，以冗長難記為恥。
靜兒從19年元旦以來，新創建的4個產品：heimdal、carter、hydra、stark。分別對應漫威里的：海姆達爾（Heimdallr是彩虹橋的守護神，我們項目用的是heimdal 是個一個地名，與Heimdallr音譯相同）、特工卡特、九頭蛇、鋼鐵俠。
這樣做的好處：
1>激發團隊熱情：
項目開發的時候，自己在打造一個「鋼鐵俠」要比打造一個「XX支付系統」、「XX管理系統」更激動人心，有木有？
2>精品意識：
自己做的每一個產品，將來都是可以做開源、可以對外宣傳、讓業界來學習的，這種產品從一開始就要定義一個可對外宣傳用的名字。
3>命名規約需求：
《阿里巴巴Java開發手冊》里寫到，包名兩個點之間僅能有一個自然語義的英語單詞。Java編程規約要求開發人員在自己定義的包名前加上唯一的前綴，一般人采用自己公司在互聯網的域名。不想讓自己的包是由太多點號組成的。一個簡練的產品名是個不錯的選擇。
單個方法：以短小精悍為榮，以冗長費神為恥。
代碼盡量短小精悍，提高可讀性。
靜兒用了兩周開發一個包含兩個服務的新產品hydra，周四上線了。周五做Code Review的時候，剛開始心里有些許傷感，代碼也就幾千行。每個類、每個方法看起來都很短小。實際上卻耗費了挺多精力。而且靜兒確信這個交給其他人做要達到同樣的質量要多耗費幾倍的時間，但似乎在代碼中表現不出來。
但是review結束后，團隊里另一個代碼也寫的挺好同事馬上發出感嘆：「開發工作量巨大。」知音哪！且不說里面整體架構的優化，靜兒的一行代碼可能實現了更多的功能。所以描述自己產出的一個思路是盡量將自己實現的功能包括改進點說細說明白。現在沒有公司績效把代碼行數作為考核項了吧？
舉個實戰的栗子🌰：
上面的代碼實際實現了一個thrift調用結果自動本地緩存，每次取數據都直接從本地緩存中取。執行效率和本地接口調用是一樣的。達到了一個遠程thrift調用平均耗時5ms。
@Lazy標簽對此類進行懶加載。引用了此jar包，不調用就不會執行，也不消耗內存、CPU等資源。
@Component標簽是將類的生命周期管理交給Spring。實現了控制反轉。
@EnableAspectJAutoProxy(proxyTargetClass = true)是java代理不使用默認JDK動態代理方式。而采用動態字節碼生成代理。這樣做的原因是這個類實現了runnable接口。使用默認的JDK動態代理時是基於接口的，會轉成一個代理對象Proxy，而不是對象本身。
評估對資源、效率的需求，采用單線程來定時執行刷新操作，將結果放到map中。單線程更新不存在更新並發問題，因為允許臟讀，所以用效率最高的hashmap即可。
代碼維護：以持續重構為榮，以停滯不前為恥。
為什么就算已經很成熟的項目，也要冒着：「沒有變更就不會出錯。變更上線就有造成事故」的風險，不斷的迭代升級，1.0到2.0到3.0？對的，不變更一般來說不會出事故。下面兩種場景除外：
1>架構不演進，但是業務量在增長。量級的增長可能會導致系統在某一時間點被打垮。阿里雲宕機半小時，按照業界SLA的標准，仍然可能宣稱可用性維持在4個9。但是架構問題導致的量級增長一般不是能加機器來解決的。短時間很難恢復。
2>有些問題如使用的基礎組件，它本身的BUG會在某一時間點被觸發。也有可能因為系統漏洞在某一時刻被攻擊。所以美團SRE那邊專門有針對業界系統的漏洞的檢測和升級流程。但是有時候為了更徹底的解決問題也會需要架構的調整。
以上場景肯定要升級迭代的。而更通常的場景是：如果不升級迭代，而團隊不斷人員變更，使用場景不斷的變化。代碼漸漸不能表達原有的意思，新人平時沒有對代碼做過修改，一改就會出錯。
所以寧可持續重構出點小錯，在代碼review，跑集成測試用例時就發現問題。也不能停滯不前。而作為大多數程序員來說，最基本的素養應該是每過一段時間回頭看自己以前寫的代碼，就應該有太爛了，應該重構了的沖動。不然的話，就該反思自己這段時間的學習成長了。
編程思想：以面向對象為榮，以面向過程為恥。
工作中經常發現有些程序員用面向對象的語言寫出了面向過程的方法而自己並沒有感覺到。舉個栗子🌰：
兩方進行通信使用json進行數據傳輸。接收方將接收到的數據轉成了json，然后String XXX = json.getString("xxx")。代碼里一堆get完成了功能。
這段代碼更好的一個實現方式是將接收的數據結構定義成一個對象，在java里可以使用objectMapper等工具直接將json轉成有業務含義的對象。
從json字符串轉成json對象不算是一種面向對象的思維方式，而更接近於面向過程的實現。因為功能實現了，閱讀代碼想知道表達什么意思就費勁了。
總結
抽象比細節活的更長久。 --《程序員修煉之道》
相關閱讀
作者簡介
作者是一個有美國硅谷、日本東京工作經驗，十二年堅持一線寫代碼的程序媛。堅持原創文章。歡迎技術交流！
