上圖為用戶、角色、組織資料模型設計原稿 https://corework.3medu.com # 描述 這項專案是我任職於浙江三米教育科技時執行的，在我加入三米時，並沒有規劃這個專案。 當時制定研發策略的決定人，要採用合作廠商的平臺作為用戶、角色、組織管理使用，我們基於合作備忘錄以該平臺開始開發應用，然而在合約談判過程中，廠商卻不再授權公司使用該平臺，換言之，平臺之上的應用開發等於無法繼續執行。 由於發生如此嚴峻的狀況，我直接建議運營團隊，由我們自己開發，避免未來再有發生被綁架的可能性，也才有了這個專案。 CoreWork 的目標是作為「ADLS 適性化知識診斷平臺」的底層，設計並實現支援高變動頻率的用戶、角色、組織及其權限的管理系統。 # 最困難的技術問題 由於目標市場是中國的高中，而重點的合作學校在上海，上海的高中生上課的形式類似臺灣的大學，有一個行政班，不同的課要跑堂（走班）到不同的教室上課，雖然都是數學課，但因為能力不同，要到不同的教學班上課。此外，不管是行政班還是教學班仍有二次、三次、四次分班的可能。 對每個老師來說，在意的是現狀（更關心現在帶的班級，而不是以前帶過的班級），但對學生來說，在意的卻還包括了歷程（如：一年級上學期在哪幾班、下學期在哪幾班）。 最複雜的是，每個人當下是有多重身份的，如：某老師是一年一班的班主任且是一年級數學三班的老師、某學生既是一年級一班的學生又是一年級數學一班的學生。 為了解決前述的問題，我花了不少的時間去設計可以支持版本變更，同時可完整記錄及存取每個人、每個人擔任的角色及每個組織的異動歷程。 此外，還仔細設計好 CoreWork 的 API，除了追求 DB IO 最小化之外，還要足夠讓 ADLS 的呼叫次數越少越好。 最大的一次 API 改版是發生在一個特殊的例外狀況，運營團隊開設了數十間學校檢視權限的帳號，在該帳號使用某些功能時，由於 ADLS 要查詢每個身份所能看到的資料範圍，就對 CoreWork 循序發出了大量的請求，結果就是該用戶的界面看起像是壞掉卡住不動了。 為了解決這個問題，我進行了 CoreWork API 最大幅度的一次改版，單次請求支援同一人提交多重身份。改版完成後，同樣情境的呼叫，所需時間只需原本的 1/30，效率高達原本的 30 倍。 # 技術 - Application Server｜Payara Server 4.1 on Alibaba Cloud - Programming Language｜Java, JavaScript - Web Technology｜HTML5, CSS3 - Framework｜jQuery & Java EE 7 including EJB, CDI, JPA and JSF - Version Control System｜Git with GitLab.com