F2E Evolution - Speaker Deck

Slide 1

Slide 1 text

F2E EVOLUTION Be a Growing and Lead F2E! Speaker: @josephj Image Source:

Slide 2

Slide 2 text

•蔣定宇 / 啊嗚 / josephj •部落格：這樣做就對了 •2008 年完成跑步環島 •熱血前端：經驗 9 年關於講者 F2E, Evangelist F2E Manager Lead F2E

Slide 3

Slide 3 text

「我們正在尋找 F2E Lead」關於此主題「我們想要成立 F2E Team，該怎麼做」「因為我們沒有 F2E Lead，所以...」「我們正在尋找第一個且最重要的 F2E Lead」「前端部門剛成立，但很頭痛如何分工」 JSDC 後、一直聽到的聲音

Slide 4

Slide 4 text

「我們正在尋找 F2E Lead」關於此主題「我們想要成立 F2E Team，該怎麼做」「因為我們沒有 F2E Lead，所以...」「我們正在尋找第一個且最重要的 F2E Lead」「前端部門剛成立，但很頭痛如何分工」 JSDC 後、一直聽到的聲音前端已經成為網路產業不可或缺的一環除了會寫相關程式、更需要能帶領前端團隊的人才只要有心，人人都可以是前端領導！分享自己在前端 9 年的方法論、核心技術希望能協助更多公司成立前端團隊也能協助更多的人才往 Lead 的方向成長

Slide 5

Slide 5 text

• Form a Team   閒聊團隊的組成、常見的分工方式 • Modular Development  個人認為最關鍵的前端開發模式：模組化 • Be Faster   一些提昇開發速度的小訣竅 • Automation   藉由工具的回饋、持續改善前端代碼本日課程大綱

Slide 6

Slide 6 text

Form a Team 成員的天賦與分工合作 Image Source:

Slide 7

Slide 7 text

老闆 / 創業夥伴㓲征徍⌻7+珮ⰸ粕ㇰ哨羝㡺ㆌ 此時什麼都會 (不用精) 的工程師比前端好用許多㓲征徍䠃➢䥝㏔工程師 / CTO You Are Not Gonna Need It 除非產品特殊、剛開始時並不需有前端這麼專業的角色

Slide 8

Slide 8 text

You Are Not Gonna Need It 工作大解放：「為解決困境而雇人」 Image Source: http://www.books.com.tw/products/0010482162

Slide 9

Slide 9 text

You Are Not Gonna Need It 工作大解放：「為解決困境而雇人」 http://www.books.com.tw/products/0010482162 在招聘前端前，請先思考自己的公司 (部門) 的產品是否真的碰到困境、或者是需要提昇一個 Level 再下此決定人才能發揮、產品能更好才能創造雙贏

Slide 10

Slide 10 text

成長到一定規模解決問題、追求更好時就要導入前端老闆/PM 美工工程師㓲征徍㚱槡㼣寞∽屰㬝哨㬧傻疍⻨㬧傻疍  寞∽㓱傓櫢 ⰸ,CXC5ETKRV珮㠚%55  2*2#524CKNU珮&$ ⻨疍截碍㓱傓櫢征徍㔡㧪ׅ㶃屷⚀瘟䮝׆ 䧬㉸┑䥥㩒屠前端工程⻩㿉㢝屷岛崎峩視覺設計⻩㿉㢝/QFGN珮 #2+珮&$2GTHQTOCPEG 後端工程多一個角色、所有人都可在更舒適的分工下工作

Slide 11

Slide 11 text

導入碰到的困難有時候導入前端並不是這麼容易前端工程視覺設計後端工程 ≁⌻䥥2TQVQV[RG  ⃮万⛩/QEMWR 2TQVQV[RG  ⛐✇⃡⛭糱⑆)KV! ┆年㓲㠚8KGY •不符合設計：  透過 Peer Review 解決 •納入版本控管：  前端「工程」師必然得會版本控管 •別讓我改 View：  假資料就應該放 Controller 或 Presenter •某方面比較好：  主管可以主動調配適合的工作、Hire 㓲,5㺵%55痙猺㓲%55㺵,5痙猻

Slide 12

Slide 12 text

實際情況前端團隊每個人天賦都不一樣 JS、Rails 很厲害的前端 Lead/CSS/JS/Rails 很平庸的前端視覺、CSS 很厲害的前端 CSS、JS 很厲害的前端 ⇜甒ⓧ䀟珮ⓨ 䔩珮,5␤⇗⑒䠉珮哨砒䷐㡕⛩ 崎峩珮ⓨ䔩珮  %55␤⇗⑒䠉 ⓨ䔩珮  %55,5␤⇗⑒䠉 #UUGVU2KRGNKPG珮,5 ␤⇗珮哨砒䷐㡕⛩

Slide 13

Slide 13 text

實際情況前端團隊每個人天賦都不一樣 JS、Rails 很厲害的前端 Lead/CSS/JS/Rails 很平庸的前端視覺、CSS 很厲害的前端 CSS、JS 很厲害的前端 ⇜甒ⓧ䀟珮ⓨ 䔩珮,5␤⇗⑒䠉珮哨砒䷐㡕⛩ 崎峩珮ⓨ䔩珮  %55␤⇗⑒䠉 ⓨ䔩珮  %55,5␤⇗⑒䠉 #UUGVU2KRGNKPG珮,5 ␤⇗珮哨砒䷐㡕⛩ 依照屬性跟能力分派適合的工作並一起 Pair 完成自己不熟但有興趣的領域能順利完成工作、大家也能互相學習、一起成長  成功的前端團隊必然有此特質

Slide 14

Slide 14 text

常見 F2E 資源分配的作法

Slide 15

Slide 15 text

Resource Pool 中央游泳池不管大小公司，最常見的 F2E 分工模式專案 1 專案 2 F2E Pool 不會有閒置資源 Image Source: http://projects.ajc.com/gallery/view/travel/cruises/trdisneyap0210/

Slide 16

Slide 16 text

Dedicated Resource 專人服務專門在做某個案子或服務的 F2E 重要服務會有自己的 RD, F2E, QA, SE Image Source: http://www.ﬂickr.com/photos/intranation/160210709/

Slide 17

Slide 17 text

知識+ 電影⾳音樂通⾸首⾴頁部落格遊戲拍賣購物中⼼心新聞 Manager 曾經同時跑三個專案 Y! US 汽⾞車 Image Source: http://www.ﬂickr.com/photos/bluebeckie/149667476/in/faves-josephj/

Slide 18

Slide 18 text

不管是 Dedicated 或 Pool，如果都只忙自己的專案最後必定會發生慘案一定要有個 Lead 負責組織 Guide、分享、Review、Quality 注意！

Slide 19

Slide 19 text

實際案例 •由新人負責、跟其他專案成員關在小房間（沒有其他 F2E） •View 全部用 JS 組、後端只給 JSON •不支援 NoJS、沒法上一頁 •重複程式碼非常多，沒人敢大改 •專案結束沒多久，新人離職 •2012 年底，此服務關閉

Slide 20

Slide 20 text

永遠在我心裡的一句話 “As a team, F2E 的價值究竟在哪裡？” 好不容易培訓一個新人、卻又因制度不健全害了他 Image Source: http://www.ﬂickr.com/photos/missbitter/868761050/in/photostream/

Slide 21

Slide 21 text

開始去思考「團隊」這件事 • Code Convention 團隊規範 • Code Review 定期 Review 程式碼 • Checklist 上線前需達成的清單開始非常重視一致性、維護性

Slide 22

Slide 22 text

規範一些最基礎的小事情一致性、像同一個人寫的 https://github.com/josephj/f2e-styleguide

Slide 23

Slide 23 text

Code Review Image Source: http://programmers.stackexchange.com/questions/170211/php-data-access-layer 程式碼接受所有人檢驗、或用 GitHub Pull Request

Slide 24

Slide 24 text

Pair Programming Image Source: http://en.wikipedia.org/wiki/File:Pair_programming_1.jpg 一個人寫程式、一個人當觀察員

Slide 25

Slide 25 text

常見的產品開發流程以及文件

Slide 26

Slide 26 text

BDD  商業企劃書 Wireframe  框線圖 Spec  規格書 Design Guide  設計標準 User Story  使用者故事 User Flow  使用流程 Mockup  PSD 圖檔 HTML Pages  JS/CSS/HTML EDD  工程設計文件 Test Case  測試範例 Website  完整網站 Deploy Script  佈署文件與程式 Site Map  網站地圖 PM ID Producer VD F2E RD QA 產品文件多如牛毛確保跨 Team 產出的品質 Balsamiq Axure

Slide 27

Slide 27 text

單一小團隊：用溝通、往返確認來減少文件、增加速度小公司：手繪 Wireframe 就解決！ From Wireframe to Interface (by Derek Clark)

Slide 28

Slide 28 text

回顧 Form a Team •你真的需要 F2E 嗎？導入 F2E 的改變？ •資源共享、或專屬於某產品（Team）？ •應建立真正的「團隊」、團隊機制 •產品開發流程

Slide 29

Slide 29 text

回顧 Form a Team •你真的需要 F2E 嗎？導入 F2E 的改變？ •資源共享、或專屬於某產品（Team）？ •應建立真正的「團隊」、團隊機制 •產品開發流程對於 Form a Team 有任何問題嗎？ Q&A Break

Slide 30

Slide 30 text

Modularization 模組化開發㉿;CJQQㄗ┑㺰⃡⇞テ∽ 㔑䐂⃮␬珮⃡⹻㉸䠉䥥㴂倥甙瞪⑆砒櫧┊崒⯻ Image Source: http://intersis.com/features.html

Slide 31

Slide 31 text

看過太多 CSS 爆炸的慘案例如：不知道樣式該設定到哪支檔案、修 A 壞 B 或者是一支 JS 會影響全域、有加載順序的問題... 網站開發已經變得非常複雜過去以「頁」為單位來開發、該改為用「模組」為單位看似很笨又靈散的作法、但卻可解決上面所有問題你是否也有相同的困擾？

Slide 32

Slide 32 text

頁是由許多模組構成 Image Source: http://intersis.com/features.html

Slide 33

Slide 33 text

頁是由許多模組構成 Image Source: http://intersis.com/features.html

Slide 34

Slide 34 text

標題

內⽂文

更多...

標題

內⽂文

更多...

id 代表一個模組，不能重複使用。 .hd, .bd, .ft 代表模組的頭、身體、尾巴標準模組結構考慮不支援 box-sizing 的瀏覽器。

Slide 35

Slide 35 text

Reports

...

.bar table #reports position: relative .bar background: #eaeef4 table th text-shadow: 0 1px 0 #fff font-weight: bold _report.html _report.css.sass 檔案小，幾乎不會超過 100 行命名空間，樣式不可能會互相打架 _report.js.coffee define (require) -> ! # Stops execution if no matched element. $view = $('#reports') return unless $view.length ! #################### # Shared Variables #################### $form = $view.find('form') ! #################### # Bind Events #################### $form .on 'change', '.report-check', -> ID 存在才會執行 #reports

Slide 36

Slide 36 text

頁面層級：合併零散的模組

Slide 37

Slide 37 text

更深入 CSS/JS 載入剛剛以 Rails 的 Asset Pipeline + RequireJS 為範例你也可以用 grunt-usemin 來解決 (Yeoman 內建) 比較複雜的架構就請參考我的另兩份投影片了

Slide 38

Slide 38 text

FUSE/Minify/usemin • FUSE：從 Yahoo! 學習到的工具 (開發機安裝、配合 build)  XML Configuration  http://www.eztable.com/mini?module=index&type=js • https://github.com/josephj/mini (php) • Minify：YUI 動態模組載入的作法 (開發與線上都要安裝)  http://www.eztable.com/min/?f=a.js,b.js,c.js • https://github.com/rgrove/combohandler (node.js) • https://github.com/mrclay/minify (php) • grunt-usemin：Yeoman 內建工具 (build 時 parse HTML 標籤) 還是補充一下，解決 CSS/JS 請求數量的一些作法！

Slide 39

Slide 39 text

快速解決 CSS/JS 請求數量問題 Google Page Speed • 自動圖檔最佳化：不需要自己處理圖檔最佳化的問題 • 自動壓縮 HTML/JS/CSS：不需要自己處理合併、 JS/CSS 甚至可以設定直接內嵌在頁面上。 • 自動加入 Google Analytics 安裝 Apache/nginx module 即可用！不想改變架構時的懶人速成法 http://modpagespeed.com/ 即使未來需自己處理載入方式、還是可留下部分好用功能

Slide 40

Slide 40 text

模組化開發有什麼好處 • 維護性：CSS/JS 該改哪邊，不再有灰色空間 • 沙箱理論：大幅減少與別人程式衝突的機會 • 好上手：新人只要專注小區塊的開發 • 可測試：未來導入測試較簡單（區塊小） • 擴充性：多國語系、線上動態編輯、模組間訊息廣播、 Panel，甚至臉書的 Big Pipe 架構都可以基於模組架構改善導入。 Image Source: http://thefreshnes.com/blog/uncategorized/tigers-ﬂy/

Slide 41

Slide 41 text

模組化開發有什麼好處 • 維護性：CSS/JS 該改哪邊，不再有灰色空間 • 沙箱理論：大幅減少與別人程式衝突的機會 • 好上手：新人只要專注小區塊的開發 • 可測試：未來導入測試較簡單（區塊小） • 擴充性：多國語系、線上動態編輯、模組間訊息廣播、 Panel，甚至臉書的 Big Pipe 架構都可以基於模組架構改善導入。對於模組化有任何問題嗎？ Q&A Break

Slide 42

Slide 42 text

Be Faster 快速開發 ┮⇞テ∽苌亡ⰰ恦㋌苌㉸䇠悔勢梧珮㋌聋䠃ⓛ勭㧪䥥⃡ⅼ⻰⻰㊤㉸珯 ⌻⃡⋬.GCF㉸缙㕟㢚㾶珮䧂⛐叞㧠Ⰸ⺗䃼⻲撮综テ∽磢桴珯 Image Source: http://www.ﬂickr.com/photos/behindthesteeringwheel/9466714943

Slide 43

Slide 43 text

Lesson From Rails • Asset Pipeline + Precompile  框架內建 HAML, Compass, CoffeeScript、部署時壓縮及最⼩小化  （替代⽅方案：模組加載策略、Yeoman, FireApp） • UJS (Unostructive JavaScript)  強⼤大 data attributes（直接安裝 jquery-ujs） • Helper  看似無意義的標籤產⽣生⽅方法，但與 Ruby 配合、明顯讓程式更好維護（替代⽅方案：⾃自⼰己寫？） • Bundler  強⼤大的套件管理，不需⼿手動下載或升級（替代⽅方案：Composer, Bower）

Slide 44

Slide 44 text

開發環境線上環境（經過 Precompile） Asset Pipeline + Precompile 每個網站都有一樣的需求，為什麼不能像 Rails 一樣簡單？

Slide 45

Slide 45 text

表明用 AJAX 送出，不需再寫 $.ajax 做手動送出 UJS = 少寫 $.ajax

Slide 46

Slide 46 text

點選後會先跳視窗、顯示訊息確認後會改 disabled、內容會變每個 RailsDev 都知道的基礎、你怎麼做？ UJS = 善用 data 屬性

Slide 47

Slide 47 text

<%= render "my/profile_sharing" if (!$is_owner && $viewer_uid) %> 0): ?>

... <%= content_tag :ul, :class => "student-list" do %> ... <% end if $items.count > 0 %> 積少成多下來真的差很大 Syntax Sugar & Helper

Slide 48

Slide 48 text

Lesson From Bootstrap • Reduce to write CSS and JavaScript  ⼀一種不錯的開發模式：只要加 class 與 data attribute 就可以指定樣式與 JavaScript • Make Icon Reusable  把常⽤用裝飾性的背景圖、採⽤用 glyphicons 的作法重複利⽤用 • Make Your Own Bootstrap  重新整理出⼀一個套件，就可以迅速套⽤用到多個服務上。 

Slide 49

Slide 49 text

不用每次都寫重複的 CSS 把樣式設定好，連不懂 CSS 的 RD 都可以快速套用！

Slide 50

Slide 50 text

不用寫 JS - 範例 1 Slider - 自製可以左右換頁的控制項

Slide 51

Slide 51 text

A very long text...

Continue Reading 不用寫 JS - 範例 1 Cascade - 內容收折區塊

Slide 52

Slide 52 text

不用寫 CSS 背景使用快、較可避免重複圖檔出現、或 Sprites 重複壓縮的問題學習 glyphicons，即使沒字型檔、相同方式仍可用於背景圖！不⽤用改 CSS 就可設定裝飾性背景圖檔

Slide 53

Slide 53 text

很多時候已經不再需要視覺整理出套件、套用到所有產品 F2E 或甚至 RD 可以自己套版

Slide 54

Slide 54 text

整理出套件、套用到所有產品 keyb.com intersis.com 即使每個產品樣式不一，也非常有助於頁面的樣式趨於一致抽出了此客製化 BS 套件，套樣式跟飛的一樣 :D

Slide 55

Slide 55 text

Lesson From Preprocessors • Write Less, Do More  工程師一天能產出的行數是固定的，但 Coffee 平均可減少 1/3+ 的程式碼。 • More Semantic  Coffee 的寫法與思路較為一致、閱讀也比較輕鬆、有助於維護性。 • Less Duplication  SASS 的 mixin 與 nested 可以減少撰寫與維護許多不必要的程式碼。 • Use *.sass and 2 Spaces Indentation  習慣後能夠看的程式碼變多了

Slide 56

Slide 56 text

Rethink Best Practices • Mustache.js, Handlebars.js?  像 Mustache.js 與 Handlebars.js 這種 Templating 用 JSON Object Literal 組 HTML 真的是最好的方法嗎？ • normalize.css?  normalize.css 真的比 reset.css 利於網站開發嗎？

Slide 57

Slide 57 text

భ؊∄ϰ༢ⅼᆇ֥٤Ⴈ҂ॖĤ •前後端很難共用 •相同邏輯前後端各維護一份 •好用的 Helper 無法使用 •翻譯字串的問題 •Controller 得區分輸出 JSON 或 View 非 Node.JS 及 AngularJS、以內容為主的網站

Slide 58

Slide 58 text

Ⴈభ؊∄ϰῲẕ৘ᆇ֥὜ޓỮ 一大堆 Activity 組樣板會想殺人吧 XD 數字全部得更新其他不用動

Slide 59

Slide 59 text

ẖⅼٚمᾏẪ؟ਔ 一大堆 Activity 組樣板會想殺人吧 XD 數字全部得更新其他不用動 $(document).on 'ajax:success', (e, html) -> ! # 回傳的是⼀一個沒有 JS+CSS+多餘標籤的網⾴頁 doc = $(html) ! # 取得並更新通知訊息模組 .bd html = doc.find('#activity-list .bd').html() $('#activity-list .bd').html(html) ! # 取得並更新篩選器部分內容 fieldset.types html = doc.find('#activity-filter fieldset.types').html() $('#activity-filter fieldset.types').html(html)

Slide 60

Slide 60 text

normalize.css б reset.css ݺĤ 網路上所有文章都說後起之秀 normalize.css 好但操作過後還是覺得 reset.css 來得快、方便做網站你不會希望標題大小不一致、或 li 前面有 disc 我認為 normalize.css 只能用在像部落格內文的部份不適合用在較具規模的網站

Slide 61

Slide 61 text

快速回顧：Be Faster • Lesson From Rails  Asset Pipeline, UJS：學習站在巨⼈人肩膀上開發！ • Lesson From Bootstrap  好模式：只需寫 HTML、⼤大幅減少 CSS/JS 的撰寫時間！ • Lesson From Preprocessors  寫少⼀一點，反⽽而增加許多閱讀性及維護性！ • Rethink Best Practice  別⼈人說讚的，不⼀一定是真的。

Slide 62

Slide 62 text

Slide 63

Slide 63 text

Automation 自動化 ┮䷐テ粕⅀㤐テ粕苌 ⠐㧪哋▶甙㔮叞硺六㠚畏➢忋憌䎛.GCF⃡⹻缙屷䎛≠❞ Image Source: http://www.exacttarget.com/blog/marketing-automation-infographic/

Slide 64

Slide 64 text

工程師：寫程式只是基本

Slide 65

Slide 65 text

工程師、寫程式只是基本不再寫 HTML/CSS/JS 用編譯的如何？ JavaScript MVC 模組化與載入機制响應式設計工程師也能有好樣式命令行的瀏覽器用 JS 寫後端越來越應用程式化 TDD 測試框架重點如何在過程中得到「回饋」、而不斷地去改進？這些技術你會多少其實不是重點任何技術都是碰久了就會

Slide 66

Slide 66 text

git commit post-receive trigger CI  持續集成系統 Hosting  伺服器代管 Log Tracking  記錄檔查詢系統 Error Tracking  程式錯誤追蹤系統 Quality  代碼品質檢測系統 Monitoring  伺服器監控系統 Notify  通知系統 Issue Tracking  工作排程系統 VCS  中央版本控管系統 deploy report report report report report trigger Testing  跨系統瀏覽器測試人沒辦法隨時給你回饋、系統可以

Slide 67

Slide 67 text

感覺弄好這些架構要花很多時間問題是，真的有這麼困難嗎？

Slide 68

Slide 68 text

git push post-receive trigger CI  持續集成系統 Hosting  伺服器代管 Log Tracking  記錄檔查詢系統 Error Tracking  程式錯誤追蹤系統 Quality  代碼品質檢測系統 Monitoring  伺服器監控系統 Notify  通知系統 Issue Tracking  工作排程系統 VCS  中央版本控管系統 deploy report report report report report trigger Testing  跨系統瀏覽器測試其實一個下午就可以全部弄好

Slide 69

Slide 69 text

而且選擇多到讓人眼花撩亂 https://addons.heroku.com/

Slide 70

Slide 70 text

即時掌握其他系統回報的訊息 Push/Deploy 成功、JS 錯誤、品質下降、測試結果.... 峫㍐㉩⯻獑≁⛐⇆㕫撮缙䥥猺昐罠珮∩紶猻惀⃡緈䥥猺2WUJ 㠟┑⃮⛭䥥給Ⰺ⺅

Slide 71

Slide 71 text

CI 持續整合系統自動化測試的引擎，工程團隊一定要有

Slide 72

Slide 72 text

自動檢查程式碼品質用客觀的標準幫你評斷 JS 寫的好不好

Slide 73

Slide 73 text

不錯，修掉兩個 Lint 問題原來是有兩個一模一樣的 JS 品質居然從 A 掉到 F 給我抓出來打屁股！異常狀況即時回報

Slide 74

Slide 74 text

JS 有錯第一時間知道、開票通常只會對 Staging, Production 做偵測

Slide 75

Slide 75 text

在各種環境做單元與行為測試當然可以藉由 CI 去跑自動化測試、也可做本地端測試哋▶甙肪㽳㛿⹻苌耈㨀ロ磻⻌⃡糃揉圞㬝⑮惀Ⰸ⺗ⓧ↌  6TCXKU%+ 5CWEG.CDU猳

Slide 76

Slide 76 text

CSS Regression Testing 製作一些內容不會變動的頁面 (baseline) 套用最新的 CSS 納入 CI 持續做差異化 diff

Slide 77

Slide 77 text

工程師工具 •無聊 •重複性的 •浪費時間的藉由工具持續回饋每次的 Push 都會得到一些回饋（當然最好是 Commit 前就得到回饋、雙重把關）身為 Lead 一定要不斷地改善流程、更自動化可專⼼心在核⼼心開發 Q&A Break Image Source: http://www.slideshare.net/ariyahidayat/javascript-parser-infrastructure-for-code-quality-analysis

Slide 78

Slide 78 text

工程師工具 •無聊 •重複性的 •浪費時間的藉由工具持續回饋每次的 Push 都會得到一些回饋（當然最好是 Commit 前就得到回饋、雙重把關）身為 Lead 一定要不斷地改善流程、更自動化可專⼼心在核⼼心開發讓 RD 在最棒的環境下開發能省下可觀的時間、大家也開心 Q&A Break 對於「自動化」有問題或回饋嗎？

Slide 79

Slide 79 text

Before Ending… Be a Growing and Lead F2E!

Slide 80

Slide 80 text

帶領提昇 UI 的整體水平台灣比較少看到國外乾淨、大量應用 CSS3 的 UI http://dribbble.com/

Slide 81

Slide 81 text

當 Lead 很辛苦、也很有趣 • 對老闆：想辦法用有限的資源把任務達成 • 對員工：傾聽意見、指派合適的任務、協助成長 • 像橋一樣，需要有效溝通。也像天秤一樣需取得平衡、決定輕重緩急、解決問題 • 不斷地改善流程、讓團隊運行地更好 Coding 技巧不再是最重要的事，該關心的是... 不是管理職也可用這樣的思維去協助同事、會得到很多！

Slide 82

Slide 82 text

No content

Slide 83

Slide 83 text

一定會得到正面的回饋平常的努力都有被大家看到這樣就值得了！

Slide 84

Slide 84 text

Thank you! • GitHub - josephj • Facebook - 蔣定宇 • Slideshare - josephj • Linkedin - josephj6802 聯繫我