210828 反波膽接盤日誌
緣起
記得19年下半年我檢視了一份反波膽代碼，這份代碼是一個年輕老闆拿給我，要我「看看」，這個這個「看看」也許帶有合作或是帶領年輕工程師的意思在。雖然有交待工程師一些工作，但是後來疫情爆發順勢就停了，跟這個工程師也沒有再聯絡。
最近支付系統的告一段落時，剛好問起了那位年輕老闆的近況，竟然已經做反波膽好一陣子了，而且據說還做得不錯。做得不錯，我當然很祝福。只是想到當時在檢查代碼的時候，發現了許多不合理的地方，不知道他們改得怎麼樣了？如果我自己營運的話，是不是也有機會呢？
因為在此之前，已經做過反波膽的系統，我自認為規畫得還可以。基於職業道德，當時沒有拿出來直接給年輕老闆用。我認為別人出錢開發的系統，我們做為開發的工程師，背後拿出來賣或合作，除非是當時就講好，否則不應該在不改動功能的情況下加以利用。目前我還是那個系統的無給顧問，在不太白目的情況下，系統的任何問題我還是可以回答的，然後他們的工程師就能自行修改、維護，所以後來也擴展了不少功能。當然這些新擴展的功能我並不是很了解，就無法解答了。
對於新的反波膽系統，只要加上一些新的功能，對不合理部份做修正，不要跟年輕老闆拿給我的時候一模一樣，這樣也應該就符合職業道德了，畢竟當時也幫他們做了一陣子白工，修復到可以架設運營。
已經完成的工作
距離上次修改代碼己經是兩年前的事情，現在要再接續的話，要知道已經做完什麼，什麼還沒做，未來要做什麼，目標要先定下來。所以在以我自己設計的系統為主的比對之後，發現許多設計上不一致的地方，要一個功能一個功能的對照是不可能的。比如說，在賽程的設計上，我們依照運動系統的貫例，分為聯盟、對伍、比賽、玩法等資料表，這樣的設計，就可以很好的維護整個聯盟、隊伍、比賽、玩法等資料。可是新的代碼並沒有考慮到這些，很單純的就是把賽程整個采集下來，然後不考慮維護直接入庫。
在不確定新系統能夠正確動作之前，我們把這個定為可能的變數之一，先假設運行正確，但可能有問題並且無法維護。所以最好的做法就是，采集入庫時，按照不會出錯的貫例設計分為數個表格，然後再組合數據填入新系統的資料表。而且我把這樣做法，定為新系統及標準系統之間的擬合方法。如果新系統的行為出乎預期，就重寫該動作。
目標
主題式的社群不像是 facebook 之類的主題弱連結社群，而是強調主題的個性，並且希望資訊公開透明，所以不做成員間的直接互動，而是讓成員跟主題互動，來達到成員間的間接互動。用成員間接互動來取代直接互動，以強調主題性。所以最後把目標定為最終擴展為足彩社群，分為三個工作階段。第一個階段是復原系統的所有動作，如果有修改行為就做標準化，包括數據、行為、資料庫。第二階段是擴展為社群的前置動作，例如免登入賽程列表、以賽程為順序，比賽隊伍為主題的分區，包括修改所有不合格的數據，及擴展資料庫。第三階段為完成擴展社群包括留言、按讚，支持力度。
最後我並沒有定這個項目的完成日期，其實是因為時間有限，無法那麼精準地估算時間。雖然這是立項的大忌，不過在考慮到這算是 side project ，而 side project 本來也不應該這麼大，因此也沒有更好的解決方案了。
接下來我會逐步地完成這些階段，也許六個月也許一年，有進度我就會寫日誌，精準一點有 commit 我就會寫日誌。
