2020 年被視為是電商爆發成長的一年，願景是「讓人們能用好設計實踐自己對生活的想像」的 Pinkoi 也不例外。
在 10/29（四）晚間，Pinkoi 在自家經營的實體空間「品品學堂」舉辦了「Pinkoi Developers’ night - Code the way we are」的 Open House 活動，分享 Pinkoi 在過去一年間的 wins & losses，也邀請業界的前浪後浪一同前來與 Pinkoi 共襄盛舉。
而創辦人 Peter 跟 Mike 當天也都親自到場，再再凸顯出 Pinkoi 對工程文化以及技術內容的重視
當天沒有參加到的朋友不用覺得扼腕，現在就跟著 Yourator 的特派小編一同回顧當天的活動精華吧！
（附註：為了避免讀者以為是在技術社團，本篇文章不會針對各個技術有太過深入的解析和說明。）
開場
活動由 Pinkoi HR Karen 開場，明年 2021 就 Pinkoi 滿十歲了，現在正朝向多角化經營以圖創造「商業化、規模化、國際化」的 Pinkoi 集團。
活動當天共有六位講者，分別是：
- 沒有小怪的新手村 ➜ ZihZih
- FastAPI 出奇蛋 / 三個開發願望一次滿足 ➜ Toki
- 已知用火！如何在茫茫 Task 海中求生 ➜ Ray
- 人好好的為什麼要改變？ 使用 Webpack 的心路歷程 ➜ Devin
- MV*古蹟的現代化工程 ➜ Matt
- Pinkoi Data Team 的演進史 - 從猩猩到人類 ➜ Ben
沒有小怪的新手村 –– ZihZih
ZihZih 開場便說道自己其實加入 Pinkoi 還不到三個月，跟在場還未加入 Pinkoi 的朋友們是最為接近的。在她被問到「有沒有興趣接下站上週年慶的網站」時，答應後的她聽到周圍開始爆出熱烈的掌聲，後來才知道這是堪稱「新人殺手」的大型活動。幸運的是 Pinkoi 的前輩們都不吝幫助，才讓她能一腳踏出新手村。
而讓 ZihZih 印象最深刻的事是，有次 Code Review 時在 Pull Request 上寫了「跪求指導」，結果沒多久就刷刷刷地冒出了 23 筆留言，甚至連 Slack 上都冒出了「有空嗎？可以當面對一下程式碼嗎？」的訊息。但以為自己犯了大錯的 ZihZih 不僅沒有被前輩責罵，反而得到非常多寶貴的建議，幫助她改善程式碼、考慮得更佳周詳。在沒有義務手把手教導人的職場中，讓 ZihZih 感受到 Pinkoi 的工程文化是非常不一樣的。
ZihZih 也觀察到在 Pinkoi 沒有人是為寫而寫、只管寫 Code 的「碼農」，除了 Marketing 的同事會來詢問她對於行銷活動的想法外，工程師也能夠參與到商業面的決策，而不是單純接受規格進行開發的角色。
在加入 Pinkoi 的這段時間，ZihZih 也觀察到 Pinkoi 開發團隊永遠都專注在只做最重要的事情、了解每個任務背後的 Why。
Peter 曾經告訴她：
一般工程師非常不擅長連結努力跟商業價值，但這往往是我們升遷的時候很重要的一件事。
畢竟我們不是每天在公司待滿八小時就代表你有價值、你做的事情對公司是有幫助的。如果你連自己都沒有辦法知道自己做的事情有沒有價值，那公司要怎麼看你。
而在與其他夥伴對話的過程中，她也發現到：
Pinkoi 非常在乎我們做的事情能不能幫助到設計師跟客人，在日常的對話中讓我知道「把設計變成普世價值」不只是一句口號而已。
FastAPI 出奇蛋 / 三個開發願望一次滿足 –– Toki
- 你寫 API 嗎？
- 你寫文件嗎？
- 改 Code 之後都有記得更新文件嗎？
Toki 以三個提問起頭同時也藉此引出他的分享主題：基於 Python 3.6+ 開發的 Web Framework –– Fast API。
Python 3 的 Type Hint，在傳入參數時需要提示其型別，幫助開發者後續的判讀。但也遇到了一些不足：沒辦法設定像是「只能是英文大寫且長度剛好為 8 個字元」，只能另外再寫 Code 判斷、僅僅是提示而不具有強制力、只有後端工程師看得到，對於 Frontend Engineer、App Engineer 來說沒有幫助。
Fast API 除了 API 服務本身可以解決客製化判斷的問題以外，也會依照程式碼自動生成符合 OpenAPI 規格的 JSON 檔，意即可以在任何符合 OpenAPI 標準的文件瀏覽器（例如 SwaggerHub）觀看該 API 的文件。
而現場 Toki 也演示了一段 Fast API 的程式碼。最後作結時，Toki 說道：
程式碼即文件
程式碼可以自動生成給外部的文件
程式碼可以自動生成輸入驗證規則
三個開發願望，一次滿足！
即將邁入十歲的 Pinkoi，待開發的功能也跟著公司一同成長到令人讚嘆的程度，Ray 在當天分享了兩項 Pinkoi Backend 團隊採用的解決方案：優先專案制度、工具化思維。
優先專案制度是指在一段時間內，每位夥伴都只會有一項優先專案。藉以幫助每個夥伴對焦彼此現在最重要的任務。藉此讓工程師專注在重要的事情上而不分心。
工具化思維則是說新的設計必須採用「可工具化的思維」進行設計，降低後續開發及維護的負擔。除了工程師自己在開發時會將程式碼模組化以外，也將「其他工程師可能也會用到這些模組」的情境考量進去，減少重複造輪子而生的耗損。
節省一個工程師的時間，工程師可以做更多的事情。
人好好的為什麼要改變？ 使用 Webpack 的心路歷程 –– Devin
遙想 2010 年，那是個前端工具選擇不多的年代，Pinkoi 建立了自己的內部工具：mrbuild 用來打包網頁的 JavaScript 檔，而後來採用了 Webpack 之後，減少了需要手動撰寫各頁面設定檔的時間，甚至是透過動態加載，讓頁面載入速度提升、效能提升、開發體驗優化。
使用 Webpack 之後，Pinkoi 的網頁就像是邊開車變換輪胎，不用擔心網站會因為某頁的改動而全部掛掉。讓工程師可以專注在功能本身，也讓 Pinkoi 整體網頁的效能提升了 50%。但仍需要依照不同情境，選擇最適合公司的工具使用。
不管是 MVC、MVP 還是 MVVM，各種架構其實都需要追求「RUDT：好閱讀（Read）、好擴充（Update）、好除錯（Debug）、好測試（Test）」。
Matt 分享了 Pinkoi 是如何將工程師大神 Uncle Bob 提出的「The Clean Architecture」應用在 Android 開發中。
好的決定隨著時間的演進也可能會變成壞的決定，在使用各種框架的時候，都應該保持開放的心，不要害怕改變。
Pinkoi Data Team 的演進史 - 從猩猩到人類 –– Ben
Pinkoi Data Team 以 Machine Learning 起家，需要負責站上的搜尋引擎、推薦系統、商品排序等服務，現在是由資料分析師、資料科學家、資料工程師、機器學習工程師組成，同時也會需要跟分析師、User Researcher、PM 們一同協作。
只要可以用 Data 發揮出價值的事情，我全都要！！！
但後來發現，想當個大人將使用流程全都記錄下來，其實並不是一件順利的事情。Backend 追求 API 的回應時間最速化、使用者要有流暢的體驗、App 跟 Web 的使用流程不一樣以致規格會不同......因此要與其他部門協調，衡量埋下的紀錄與其對應的成本，是否有其價值。
結語
當天各位講者在分享的過程中，都不斷地提到使用者、設計師、團隊、夥伴，以及自身的專業該如何用最合適的方式傳遞價值給支持 Pinkoi 的設計師和使用者們。
凸顯出 Pinkoi 的工程師們也都是為了能讓使用者和設計師透過 Pinkoi 得到價值，同時也是以團隊合作互助為核心的企業。如果對於加入 Pinkoi 有興趣，歡迎到 Yourator 看看他們目前有哪些職缺吧！（點擊下方公司頁面）
