本文主要講一下自己在平時業務開發中的一點心得體會，或許對新人有所借鑒
程序員能力
程序員變成能力主要的兩方面決定：
- 理論基礎
計算機編程和基礎知識，也包括數學知識
- 系統設計能力
系統設計能力是對問題進行抽象并設計出合理實現方案的能力
抽象意味著什么？
把一個需求看成一類需求，把一個產品看成一筐產品
- 維護成本低
怎么看待低維護或者無維護成本？真正的抽象業務能力應該是使端對同類業務擴展無感知，也就意味著對產品來說新的同業務產品在技術層面上面的改造應該是無或者是很小程度上在上游的適配。
- 高可擴
業務抽象能力能夠使的新增的業務需求在已有設計中可以做到很高的可擴展性，稍微增加一些業務抽象邏輯即可適配。
- 高開發成本(首次)
如果對一個業務需求都去做一次抽象，毋庸置疑會增加首次的開發成本，但隨之帶來的是高可擴和低維護。這是一個開發在日常業務中需要自己衡量的。
- 高嘲諷
這個主要是在業務開發進行抽象的時候帶來的一些問題，一般都是因為在首次開發的時候需要額外的開發成本。經常會聽到一些反面的聲音，會懷疑業務上拓展的能力以及額外的開發成本所帶來的反感。因為業務的抽象是會帶來額外的理解成本的。
抽象的妥協
每個業務開發程序員，都需要去帶著這樣的抽象思考去看待每一個需求，把一個需求看成一類需求，把一個產品看成一筐產品。因為即使無法從真正業務上做到抽象，也可以在代碼層面做一層抽象。這種抽象在我日常開發中顯而易見，也正是因為這樣的先見之明，在后續的一些業務對接上占據了很大的優勢。上面說到過，抽象肯定會帶來額外的開發成本，量力而行。一些業務可能并不明確或者抽象依賴對后端接口的設計。這些情況下，都是可以做首次抽象妥協的，先做一個版本試一下。把抽象作為下一次的迭代任務有時候也是一種明智之舉。
其他的思考
- 局部抽象
對于一些業務鏈路特別長，綜合考慮后覺得整條線要打通的話涉及部分之多可能會帶來產品的延期，那么就可以盡量做到局部的抽象，尤其是一些鏈路特別長的業務需求，局部抽象能力可以讓業務具有相對較高的可擴展性。下面舉一個具體例子 - 搭售超級會員：
超級會員這個業務比較復雜，復雜的原因是其涉及模塊較多，鏈路較長。分別從菜單(導購模塊)到籃子(籃子模塊)，再到結賬頁(BK模塊)，這樣一條長的鏈路如果在首次開發的時候直接做到對具體業務的抽象是非常困難的，其中涉及不光是客戶端的程序設計，也包括后端接口的抽象設計。因此當時折中的方案是做到下游(籃子，結賬也)的局部抽象，放棄導購作為上游業務端的營銷業務的抽象。具體的程序代碼不在此贅述，簡單的描述一下籃子和結賬頁。
在開發結束后，籃子作為一個食物緩存的容器，原本只保存一些食物和一些活動信息。那么對于超級會員產品被接入到籃子中，如果理解成一種搭售產品被加入到籃子中，那么搭售產品的就應該和食物平等的存在。而籃子也不需要去關注具體的搭售產品是什么，對于籃子來說超級會員的籃子加購其實就是一個具體id的加入并透傳到結賬頁(BK模塊)，結賬頁再把該List<id>作為參數傳入接口。可以設想一下，當搭售產品業務擴展后，我可能都不需要去籃子模塊和BK模塊做相應的代碼修改。
