---
# System prepended metadata

title: 學習目標

---

# 學習目標
1. 前端遊戲頁面製作
    - 了解PixiJS基本原理與操作
    - 進行基本練習
    - [ ] 圖片載入畫面
    - [ ] 元件移動、旋轉、縮放控制
    - [ ] 元件顯示、隱藏控制
    - [ ] 點擊事件捕捉處理
    - [ ] 如何產生特效
    - [ ] 如何製作遊戲頁面素材
    - [ ] 建立場景
    - 了解開發工具使用
        - [PixiJS Devtools](https://chrome.google.com/webstore/detail/pixijs-devtools/aamddddknhcagpehecnhphigffljadon)
    - [框架Phaser(選配)](https://phaser.io/)
    - 參考 
        - [官網](https://pixijs.com/)
        - [教學](https://github.com/Zainking/learningPixi)
        - [鐵人2018](https://ithelp.ithome.com.tw/users/20106532/ironman/1249)
        - [鐵人2022](https://ithelp.ithome.com.tw/users/20152526/ironman/5741)
2. DDD相關
    - Event Storming
    - Context Mapping
    - TDD(Test-Driven Development)
        - [ ] 撰寫測試程式碼
        - [ ] 在測試的保護下至少進行一次重構
    - BDD(Behavior Driven Development)
        - [ ] 進行example mapping
        - [ ] 建立Scenario list
    - ATDD(Acceptance Test-Driven Development)
        - [ ] 建立user story
        - [ ] 產出驗收測試文件 
    - 參考資料
        - [Think in Domain-Driven Design(2019鐵人)](https://ithelp.ithome.com.tw/users/20111997/ironman/2730)
        - [在 Ruby on Rails 中導入 Domain-Driven Design 是不是搞錯了什麼?(2021鐵人)](https://ithelp.ithome.com.tw/users/20108265/ironman/4846)
        - [馬克的軟體架構小筆記(2021鐵人)](https://ithelp.ithome.com.tw/users/20089358/ironman/4359)
        - [30天快速上手TDD](https://ithelp.ithome.com.tw/users/20010292/ironman/462)
3. TypeScript
    - 熟悉TypeScript基本語法
        - [ ] 了解interface並使用在程式中
        - [ ] 了解class並使用在程式中
        - [ ] 了解泛型<T>並使用在程式中
        - [ ] 了解decorators並使用在程式中
        - [ ] 了解modules並使用在程式中
    - 了解TypeScript編譯器的運作方式
    - 參考資料
        - [TypeScript 新手指南](https://willh.gitbook.io/typescript-tutorial/)
5. 前端測試
    - [學習使用Jest](https://jestjs.io/zh-Hans/)
        - [ ] 安裝Jest
        - [ ] 了解discribe(), test(), except()
        - [ ] 斷言練習toBe, toMatch, toEqual, toContain
        - [ ] 如何進行非同步測試
        - [ ] 建立mock
    - [vut-test-utils](https://test-utils.vuejs.org/guide/)
        - [ ] 測試一個component行為
        - [ ] 使用mount(), shallowMount()撰寫測試案例
6. 自動化部署
    - 了解github actions
        - [ ] 學習Event, Jobs Step Action Runner
        - [ ] 目標: merge code時自動上版


[Event Storming](https://discordapp.com/channels/937992003415838761/1074962049551044638)
[讓大語言模型(LLM)擁有私有知識方式](https://discord.com/channels/937992003415838761/1097367369338339358)
    
# 筆記
Event Storming 是為了同步團隊成員對於'流程'的知識,因此重點要放在流程和同步知識,其他的可以註記即可

5/5
    若已有一份顆粒度較細的ES，是否還有必要特地簡化成較粗的?較細的ES對後續的分析,開發有何影響?
    
5/6 可以將ES的結果切開，分步驟進行
    自然語言會有不同的認知，每個人都會有先入為主的認知造成歧異性，就會有誤認需求的問題
    SBE(Specification by example),透過ecample Mapping來完成SBE,這整個流程就是BDD
    example mapping和rule的不一樣
    1. 更明確描述情境
    2. 帶Data更好
    3. 也可以畫圖

    Gherkin language:
    Given [Preconditions or Initial Context]
    When [Action performed by the user]
    Then [Expected outcome after the action]
5/9 Cascading Events 連續性的event 可以拿掉後面的comment 把兩個event放一起
    ES重要的是對話不是成果
    Policy會強調這個地方有複雜度要注意
    policy語法: whenever event then command
5/13 關於Gherkin language
    1. 盡量明確(例如有有多少玩家,每個玩家給個編號)
    錯誤示範:
    
    
    Given 當領袖分配完指示物
    When 當贊成票大於反對票
    Then 成功!
    
這只是換句話說,並沒有更具體一點,盡量帶入實際的資料
    較好的範例:
    
    Given目前有五位玩家A,B,C,D,E, 現在A是領袖,且已分配指示物且所有人投完票
    When A, B, C 3人贊成、D, E 2人不贊成
    Then 成功進入執行任務階段
    
2. 從example mapping有可能會找到新的rule
3. 列出EM後,可以在寫code之前就可以知道這個story的複雜度
4. 如果太多EM可以Zoom-in, 可以切分問題後專注處理
    
5/16
    1. [心得]不會影響整個流程的comment其實不重要可以刪掉
    2.
    
5/20
    
    1. [問題]UML中 常數該如何表示?
    2. OOA步驟:
        1. 結構化 將需求中的所有重要的(領域核心概念) 名詞和動詞捕捉起來
        2. 名詞分類
        3. 物件分類
        4. 關係分類
    3. UML圖的好處: 
        1.幫助建立更強的Ubiquitous Language
        2.視覺化梳理概念
5/27
    
    1. domain可以有多個聚合根
    2. 概念和程式語言語法是分開的，不同的程式語言或許會用到不同的語法來呈現相同的概念
5/30
    
    今天聽完直播，對乾淨架構更了解一些，之前認為，event要回傳那些資訊取決於api要回傳什麼，而api要回傳什麼取決於前端要呈現什麼畫面。現在覺得這個說法有點問題，event應該專注於domain的領域知識就好，領域決定該傳什麼就傳什麼，至於api要長什麼樣子讓外層controller 自己去轉換就可以了。不該讓外部需求來影響核心的動作
    
6/3 DevOps
    
    1. Deliver the outcome and the Value
    2. 從自動化轉移到組織文化
    3. 傳統開發流程的問題
        1. 會有Silo effect(穀倉效應)，大家只想做份內的事,不想對別人負責
        2. 裡面存在許多Waste(浪費) => 提出Lean 精實開發
    4. 有7種wastes
        1. wait/delay
        2. transport(運送成本)
        3. inventory(unused code / unused legacy code)
        4. defect(bugs)
        5. extra processing(重工)
        6. over production(過度工程)
        7. ??
    5. 目標就是減少wastes

devops演化
```
    2009 devops被提出
    2010 dev / ops 協作
    2011 devops tools -> 影響大家的行為 -> 建立好的文化
    2012 更快的回饋
    2013 startup 新創各種蜂擁而上 time to market -> devops matters
    2014/2015... devops: Saas (EKS / serverless / cloud native)
    ....
    2017: devops 不是一個 pipeline 而已，「每個人都有問題」
    2018: dev + ops / hr / sales / legal / marketing 人的問題很大了
    ....
    2020: devops: building trust
```

DevOps = Everything you do overcome the friction created by silos.

    Silo effect 穀倉效應：它讓我們感覺到彼此 are different
if we are in different, we feel indifferent (漠不關心）.
    1. 建立文化 解決完這個問題
    2. 透過技術解決這個問題
    
我如何把這些知識，帶回我的團隊落地？
好的開頭：domain-driven 我們要交付價值
我們要感受到意義 我們要同步認知
---> 這些 practice 使我們保持雀躍和開放的心態在持續學習
    1. DevOps的第一步驟就是Walking Skeleton
    A “walking skeleton” is an implementation of the thinnest possible slice of real functionality that we can automatically build, deploy, and test end-to-end.
    
6/10
    
    工作三步法
    1. flow thinking & deploy
    2. feedback loop and evolve
    3. build up a culture
    
    Walking Skeleton
    A “walking skeleton” is an implementation of the thinnest possible slice of real functionality that we can automatically build, deploy, and test end-to-end.
    三個要素 1.實際功能 2.end to end test 3. auto build test deploy
    第一版ci/cd雖然很爛,但一定要在一開始的時候堅持架完
    
    越晚建立成本越高：成本是大在哪裡？
    1. 機會成本考量：之前浪費一堆人為時間，幹嘛這麼晚架？
    2.漸進式增加（演化）好像比較爽？
    3.人為時間有可能帶你們進入惡性循環
    
7/1
    
    API路徑設計: https://www.youtube.com/watch?v=xDMTP2OVROo

7/15
    
    人生三大寶具
    1. 槍: 不可妥協的目標
    2. 地圖: 整理自身的目標
    3. 雷達: 資訊流，找出未知的未知
    
    心得：
    1.找出未知的未知很重要，持續的探索未知才能拓展更多的可能性
    2.每月回顧這個月學到的新東西

12/19 分享note
    
    1. socket.io 要加上polling才連得上
    2. azure的app 沒在用會關閉 要先搓一下才會啟動
    3. azure的app socket.io會定時斷線, 要實作斷線重連機制
    4. 三角函數分享
    