MedPartner團隊誠徵 #前端工程師,薪資 55000 ~ 85000 元,歡迎優秀生猛的人才加入我們團隊!
俗話說的好,在家靠父母,出外靠朋友。有病就要看醫生,網站生不出來就要找工程師。我們團隊生病有醫生、吃藥有藥師、畫畫有設計師、拍片有影音剪輯跟動畫師,但因為目前工程師都是兼職無法全心投入網站改版的開發,所以一年多了,網站還是很陽春。但我們真的好想要一個更好用的網站啊(怒吼)
光把正確的知識寫到一般民眾看懂就不是容易的事,但更重要的是要讓資訊更有效傳遞,以及讓呈現的方式以及介面更適合我們的讀者。因此我們非常期待徵到一位強者夥伴,可以協助這個團隊做出更容易搜尋、更容易互動、更能讓我們持續優化服務的網站。也期待在您的加入後,我們可以挑戰互動式網頁以及更多有趣、有效果的資訊呈現形式。
您的同事保證都是聰明而且善良的人,非常樂於溝通與協作。在這裡工作,我們一定想辦法讓你工作有意義,每天都能幫助到很多人。
#上班地點
台北市重慶南路一段121號(重慶南路衡陽路口星巴克斜對面日藥本舖樓上)
距離捷運西門站、台大醫院站走路都不到五分鐘,樓下有公車站牌
#職缺能力經歷要求
* 媒體、電商網站產品開發與維護,包含實作前端介面與後端 API 介接
* 開發由設計師提出的 A/B 測試
* 廣告版位開發維護
* 前端效能優化調校
* 搜尋引擎優化調校
* 撰寫自動化驗收測試(End-to-End Testing)
#技能需求
* 熟悉 HTML/CSS/JavaScript,具備跨瀏覽器相容性開發經驗
* 具備 AngularJS, React, Vue.js 任一前端框架之應用程式開發經驗
* 熟悉 Chrome DevTools 瀏覽器開發者工具(Timeline, Audits, etc)
* 具備自動化測試與相關工具開發經驗(Jest, Mocha, WebdriverIO, etc)
* 具備 RESTful API 介接經驗
* 具備 Git 版本控制系統多人協作經驗
#加分條件
* 資訊相關科系畢業
* 具一年以上軟體開發經驗
* 熟悉 Progressive Web Apps 開發實作
* 具備任一後端語言開發經驗(PHP 或 Node.js 尤佳)
* 具備 Google Anayltics & Google Tag Manager 使用經驗
* 暸解 Web Security
#希望您的價值觀和我們一樣
* 共善:我們追求和服務的對象、以及整個社會的共同利益。
* 樂於分享學習
* 認同知識是用來分享,而非用來掠奪
#工作福利
-不需自備電腦,由公司配發你需要的裝備
-無打卡制度,彈性上班時間,一週可 2 天遠端工作
-週休二日,依國定假日休假,到職即有特休
-團隊工作氣氛佳同事好溝通,決策明確不做任何沒意義的事
-辦公室備足健康食物與咖啡 同事隨時可以跟你腦力激盪
-不定期舉辦電影包場
-免費看病因為老闆是醫生(這是福利嗎?)
-沒有應酬、尾牙沒人會叫你表演
-你一定吃得比老闆好,睡得比老闆飽
-國內相關課程進修給予補助、買書公司買單,如果你願意分享讀書心得的話另外發獎金
#聯絡方式
有興趣進一步了解的朋友請來信 info@medpartner.club 並附上不超過兩頁的履歷。
希望您讓我們明白您的技術能力
如果可以的話,請附上你的GitHub 或相關作品集,謝謝!
有請大家協助把這個訊息分享出去,感激不盡啊!除此之外,也請多支持我們的訂閱計劃,我們才能繼續找最優秀的人才,為台灣做出更大的改變。拜託大家了~
美的好朋友 #做夥伴報計畫 ▶︎ https://backme.tw/ref/GsHuB/
同時也有10000部Youtube影片,追蹤數超過62萬的網紅Bryan Wee,也在其Youtube影片中提到,...
「api自動化測試」的推薦目錄:
- 關於api自動化測試 在 MedPartner 美的好朋友 Facebook
- 關於api自動化測試 在 91 敏捷開發之路 Facebook
- 關於api自動化測試 在 91 敏捷開發之路 Facebook
- 關於api自動化測試 在 Bryan Wee Youtube
- 關於api自動化測試 在 Travel Thirsty Youtube
- 關於api自動化測試 在 スキマスイッチ - 「全力少年」Music Video : SUKIMASWITCH / ZENRYOKU SHOUNEN Music Video Youtube
- 關於api自動化測試 在 Postman:从零基础入门到精通- REST API接口自动化测试 的評價
api自動化測試 在 91 敏捷開發之路 Facebook 八卦
看吧,每人每天至少 merge 回主幹一次,基於主幹的開發 搭配 feature toggle,才能比較容易達到真實的 CI, CD 的精神。
CI 本質是「持續整合」,不是 build server。
CD 是「持續佈署」,不是自動化佈署。
TDD 也不是自動化測試,是測試輔助開發,用測試來描述情境,確保每一行程式碼都是剛好的為某些情境而存在,沒有多餘,重構沒有負擔,顆粒度小的單元測試能完整且扎實。(你們確定你們團隊有能力在實務上有效、有用地使用TDD來獲得好處嗎?)
紅燈除錯時間降到最低,上版後要 hotfix 也可以直接關掉 toggle 再找到問題的原因,快速地 merge 回主幹,直接推到 production 再開 toggle。
如果走 feature branch,那你們產品是多久才 merge 回主幹一次?一天多次?如果是,那你會覺得連開 feature branch 本身都是個多餘、不必要的 effort。
一切都是基本功,不要只被絢麗的工具、解決方案給迷惑了。
#給了你鑿子也不會因此變成米開朗基羅
--
每次在上課或是在輔導的客戶那邊聊到,Odd-e 幾乎所有人一般都是不走/不建議 用 git flow 之類的 feature branch,工程師們總是十分吃驚。你們不拆 feature branch? 那你們怎麼做的?
feature branch 的主要目的就是為了避免 conflict 造成的成本,然後透過 delay merge 來降低這一段成本(事實上降低的是頻率,而不是成本),因此而付出「延遲整合」的代價。
其實如果退回來敏捷出來之前的瀑布式或傳統的開發方式,大部份都是 component team 或是專業分工團隊,依據大家的專業去內聚成一個 team, 看起來貌似 efficiency 提高,其實是在增加整合的困難,失去全局概念,增加依賴的不穩定性,甚至「避免」溝通。
如果你看過前端一個 team, 後端一個 team 在做一個產品,他們只透過 API spec 跟 文字在溝通如何界接,最終都會導致許多無形的浪費。(怪了,我們這樣分的原始目標還是為了避免浪費)
一個需求需要兩個 team 跨 team 合作的配合,才能正常且順利 deliver,分頭開發就是導致延遲整合,如果再用類似 sprint 的 iteration,一個 sprint 的結束之前才來做整合,當時間已經用盡,但整合出現問題時,就會開始出現責任歸屬問題。
例如前端改也可以,後端改也可以,那麼誰要改?沒時間了啊...後面的工作跟時程都安排好了。
其實,本質問題都是一樣的。
總是碰到客戶那邊用了華麗的 build server 之後,再套上潮流的 git-flow, github-flow,再搭配上一個產品超過 3 個團隊在同個 product code-based 上工作,不同專案不同時間點要上線,再加上從 local/dev 到 prod 至少有三個環境。
結論就是光一個佈署、merge、上版、退版、pull、解 conflict,他們就身在其中痛苦不已。越痛苦,就希望痛苦的頻率降低,做一次痛總比老是痛來得好。
所以,誰晚 merge 誰倒楣。
--
當然啦,feature toggle 也不是萬靈丹,他會帶來 application 複雜度的挑戰,而 application 的複雜度控制,其實卻反而是最簡單的,因為只要設計的底子夠足,這一段可以設計地很美、很無感、很無痛,而且開發維護成本低廉,品質良好。
api自動化測試 在 91 敏捷開發之路 Facebook 八卦
【錢,要花在刀口上】
測試,是測不完的。
測試是用來提昇品質、降低風險的手段之一。(當然,當你打通任督二脈之後,你還可以拿測試來加速開發。)
資源有限、時間有限,所以測試的投資,需要考慮 ROI(投資報酬比)。
※ 就像你不會(也不該)把畢生積蓄,全都拿去買意外險一樣。
by the way,「只」想透過「測試」來提昇「品質」,是很吃力的,測試只是其中一個實踐。
要提昇品質,產品開發過程中還有許多你該落實的實踐,例如:
☑ Specification by Examples
☑ ATDD/TDD
☑ Unit Testing
☑ Code Review
☑ Pair Programming
☑ Commit Frequently
☑ Continuous Integration
☑ Exploration Testing
☑ API/Integration Testing
☑ Manual Testing (你沒看錯)
☑ Production Monitoring
☑ Third-Party Services Monitoring
☑ Exception Monitoring and Analyzing
...
上述有些實踐,不只是提昇品質的好處,所以,找到導入的 road map,找到綜效甜頭比較大、抗拒比較小的切入點,還是相當重要的。
▍補上之前給學員的提醒
不要忘了、也不要企圖,只用自動化測試,想要防止一切 bug 的發生,你應該還要有 pair programming, code review, 其他的自動化回歸測試, 各個環境的手動測試,都通過之後,才 deliver to production。
經過這一連串的把關,如果 production 還發生邏輯上的 bug,那我敢跟你保證,那個 bug 絕對不是主要流程,影響範圍小,甚至不影響你的價值或業務。
那時你應該把重點放在,如何快速的 fix 它,快速地上版,而不是糾結在還沒交付前,「把畢生積蓄拿來買意外險」。
api自動化測試 在 Postman:从零基础入门到精通- REST API接口自动化测试 的八卦
link to this coursehttps://click.linksynergy.com/deeplink?id=Gw/ETjJoU9M&mid=39197&murl=https%3A%2F%2Fwww.udemy.com%2Fcourse%2Fpostman- api - ... ... <看更多>