今天繼續做公司的工作，甚至書都沒看~
下班前和總監聊了下關於專案的管理，因為現在建了很多的service，其它們大多是定製的，重用性很差，而把原來三個專案的service都放在一起，取名就是一件很難的事情，因為會有大量的重名，它們甚至傳入的引數都相同，僅僅只返回值不太相同。
總監講了一些，再結合我自己的思考，總結下就是：
一，重用分為業務的重用和技術上的重用，如果滿足技術上的重用，那麼就需要盡可能的將服務原子化，那麼**的重用性就能達到很高，但是這樣會帶來業務上和效能上的冗餘，比如原本有3個功能，需要查詢同乙個表裡，a,b欄位，b,c欄位,c,d欄位，作為技術上的重用，那就會寫乙個方法把a,b,c,d4個字段都返回了，這樣把3個功能變成乙個功能，但是這樣做，就會帶來效能冗餘，某些方法從業務上來，可能就真的只需要a,b欄位，如果這個查詢業務的使用頻率非常高，那麼查詢多餘字段帶來的效能負擔就會很重。
二，現在將三個專案的service放在一起，是因為目前還看不出哪些業務是核心業務。這本來是架構師從開始就應該知曉和設計好的，因為某些原因，總監沒有做好這些工作。通過聚合服務，可以看出來哪些微服務是被經常呼叫的，業務會經常跨庫查詢。經常呼叫的微服務，就可以寫成核心業務，核心業務以業務為最重要，就會冗餘一部分效能已符合絕大數的服務。而經常需要跨庫查詢的業務，就反應出，要麼是業務不合理，有些資料並不是這個業務所必須得，那就砍掉。要麼就是我們的資料庫設計不合理，需要把這些字段冗餘一部分到其他庫，以免跨庫查詢，或者把整個表都移走。
三，到後期需把讀操作和寫操作區分開，我沒有特別的理解到，淺淺的認識，或許是因為讀操作，頻度會比寫操作高很多，那麼寫操作可以更偏向於技術重用，而讀操作又分核心業務和非核心業務，非核心業務就可以隨意操作，而核心業務又分是否高頻操作，高頻的，還是得定製化service，確保效能，低頻的可以做好業務重用。這部分還未想的特別明白。
羅里吧嗦又寫了一堆~
100天土雞飼養計畫（2）
今天因為工作變動的事情，浪費了不少時間，其餘時間了解了一下webservice的工作原理。webservice是一種通訊技術，是基於xml soap wsdl uddi來實現的，乙個個的說。empire burlesque bob dylan usacolumbia 10.90 1985 hide ...
100天土雞飼養計畫（11）
我的天，今天一天的時間浪費在除錯git上了！各種提交有bug！簡直浪費了大量的時間！順帶了解一下新的架構，有點失望呢 感覺並沒有什麼特別大的變化，僅僅只是專案裡的service，controller等重新根據新的思路，劃分到新的資料夾或者專案裡，資料庫的表進行了清理，各表的結構進行了優化，但也就僅此...
100天土雞飼養計畫（19）
今天週六，但是因為颱風的原因，需要補班，其實我好多時候週六都會自己來加班，但是自己加班和被要求上班感覺上還是差太多，總有一種被強迫的感覺.今天最重要的收穫是好好折騰了一下ef 是這樣的，有3個表a,b,c，a表和b表是一對一關係，b表和c表是多對多關係，他們都有關聯屬性。現在我需要生成乙個objec...