【從學員練習影片觀察到一個關於 TDD 的有趣現象】
極速開發的課後練習作業,雖說重點是放在極速開發要學習的技巧與刻意練習的模型,但開發的方式、順序也是刻意安排成類似 TDD 的進行方式,來讓生產力最大化(TDD 本來就是幫助開發的,不是幫助測試的)
我從2位第一次上我課的學員(當然就是 #極速開發,代表他們沒上過#單元測試 跟 #TDD與持續重構),雖然他們是照著示範影片、上課教學用 TDD 在寫整個 tennis 的過程,但從他們執行測試的時間點就可以發現:
「他是用測試來驗證 production code 的正確性」,即使他先寫了測試,也不先執行,沒有看到紅燈,每次都等到 production code 寫完了,應該要綠燈時,才執行測試。
而其他上過 TDD 課的同學 ,或是上過單元測試的同學,知道測試是用來描述情境,如果現在「加入的這個情境是新的需求或需求異動,代表目前 production code 還不支援這個情境,執行測試跑出的紅燈,就是等等 production code 要完成的 #目標」
test-frist 從來都只是 TDD 其中一個小小的衍生產物,而不是全貌。TDD, 測試驅動開發 從來都是一種開發方法,而不是測試方法。
總有些人老愛把 TDD 拿來跟測試相提並論,就總是喜歡把 test-first 當作靶子打,覺得違反人性跟直覺,覺得先寫測試在很多情況下是浪費時間或是不 work,可能拿來跟一堆測試的方法論相提並論,或總是只拿回歸測試的效益來當作 TDD 的整體。抑或是陷入 isolation unit test 與 integration test (其實就是非 isolation 等級、有實際依賴的自動測試)之爭。
```
註:TDD 事實上是可以不是單元測試等級的。
```
要比較正確看待 TDD 的角度,首先要知道它是幫助開發的、它是一種開發方式(當然不是唯一一種,甚至也不會是最好的一種,因為根本沒有最好,只有剛好)
接著要了解 TDD 可能用 IPO 模型還比較貼切,input-process-output,在你開發任何功能之前,你總要先想過這件事。而先想這件事,才是 TDD 的最基本精神。
接著是怎麼把你想好的東西,變成可執行的 spec,我們只是用測試程式來「描述」你腦袋中的「IPO模型」,把 process 的過程當作一個黑箱子。
而這個 IPO 模型在結合成「使用情境」,就會帶來「高易用性 API 的好處」,只有在一開始就先想好怎麼給別人用,最後才會好用。所謂的一開始想好,指的不是預先設計一堆 class,而是 input/output 想清楚期待(一般會結合實例化需求,搭配 Given/When/Then 的 gherkin style 來把前置條件、資料、前提想好,當發生什麼事,應該是怎樣的結果),然後描述它。在紅燈定義清楚目標,綠燈完成 input/output 關係且沒弄壞前面的所有情境後,來針對 process 進行重構(事實上 Kent Beck 的 TDD by Example 更多是用 refactor 來 #完成 process。
```
註:所謂的 output 不一定只有回傳值,包含外部依賴狀態、資料的改變,甚至顆粒度小一點,針對物件導向設計的話,物件內部狀態的改變也算,只是物件內部狀態改變,驗證點要嘛是拿得到內部狀態,要嘛就是要驗證物件哪個行為會因這個內部狀態而有所不同。
```
## 戰 TDD 之前該先做好的功課
要戰 TDD,是不是至少要把 Kent Beck 的 TDD by Example 看完?
要戰 TDD,請不要拿它跟測試方法論來比,那只是一下就被人看破手腳。因為它是個開發方法論。
要戰 TDD,請不要把它的好處只限縮在跟回歸測試、自動測試的比較,因為那只是它的衍生好處,當你試過在白海報紙上 TDD 就懂,TDD 是在釐清你的思緒的同時,又可以以終為始,確保你在 production code 的每一個動作都是為了滿足某個期待的情境。
要戰 TDD,請不要去把 單元測試、整合測試捲進來,那是測試的顆粒度,那是測試的分類,TDD 從來都不是只能限於單元測試。
要戰 TDD,請不要在那邊戰他是 bottom-up ,是直接從程式/class 的角度出發,事實上 TDD 既不是 bottom-up, 也不是 top-down, (書裡面就有講這件事咩),實務上的 TDD 結合倫敦派(GOOS)跟芝加哥派(Classic TDD),會更像 Outside-In 的進行方式,先定義好驗收情境,接著從最外部(也就是使用者看得到的部份)一路把依賴往另一邊的系統邊界推,直到推到系統以外的依賴資源(persistence 或 external API/service)
```
註: ATDD by Example 中 ATDD by Example, Kent Beck 寫的序最後的一段話。
Kent Beck:
「就像我曾說過的,TDD的一個缺點是,它可能會退化為一種用來滿足開發人員需求的編程技能。某些開發人員從更廣泛的角度來看待TDD,輕易在他們測試的不同抽象級別間跳躍。然而在ATDD中不存在歧義,這是一種加強與非編程人員溝通的技術。我們之間良好的協作關係,以及作為這種關係基礎的溝通,能夠使軟件開發更有效率。採用ATDD是向著溝通更清晰這個目標邁進的重要一步,而此書是一本全面又平易近人的入門讀物。」
```
要戰 TDD,請不要只關注在 test-frist,因為他只是用 test 來幫助你 think-first,不要邊寫邊想。然後不要過份依賴或相信你腦袋的能力,把你想好的東西具體化出來,最好可以被直接執行,最好除了你以外每個人執行出來的結果都會一樣(不管是對的,還是錯的)
要戰 TDD, 請不要把論點放在見樹不見林,如果你有看 TDD by Example 的 Part 1, Part 2 那兩個加起來共 24 個章節,就知道一開始就得把當下想到的全貌紀錄在一個「紙本」的 backlog (所謂的紙本,只是要講這並不依賴於任何工具)
而這個需求輪廓的全貌,會隨著你逐漸完成一部分一部分的情境,設計逐漸浮現後,而隨時跟著增減調整。
但不代表 TDD 就是先想到一個測試案例,就直接先幹下去了,那根本是亂搞。
以上這些,都還不是在列 TDD 的好處,而是針對那些從來沒搞懂 TDD 但又愛戰 TDD 的人一點提醒,你戰的很可能是「你誤解的 TDD」。
TDD 還有許多實務上的用途,列上我在譯者序中的一小段:
>> 測試驅動開發(Test-Driven Development, TDD)!一種以測試為開發輔助、以測試來描述需求情境、以測試來當作目標、以測試來表達期望、以測試來驗證疑問、以測試來實驗學習、以測試來溝通協作、以測試來協助設計高易用性 API 的「開發方法」。
譯者序有開放給大家看,請見:https://tdd.best/book/tdd-by-example/
拜託,要戰之前去看一下祖師爺 Kent Beck 對 TDD 的原始見解:https://www.tenlong.com.tw/products/9789864345618?list_name=srh
如果你想正確的使用 TDD 來幫助你在實務上產生許多的價值,帶來許多的好處,尤其是需求釐清、持續重構、小步快跑的部份,最好理解的培訓課就在這:https://tdd.best/courses/classic-tdd-by-example-video-training/
最後我想講一段話:
TDD 從來都不該被導入到團隊中,但它是一種很好的自我鍛鍊與學習的方式,也是一種能用很低的成本來帶來很多好處的開發方法(見下方註腳),然而它也不是適用所有的情況,但它可以讓『完美』變成一個動詞,而非不變的形容詞。
```
註:
Kent Beck 在 DHH 靠腰:《TDD is Dead》 之後寫的一篇反串文:《RIP TDD》
https://www.facebook.com/notes/1063422864115918/
我幾年前的簡易翻譯,通常也是 TDD 可以幫助你解決的問題,如下:
- Over-engineering (過度設計)
- API feedback (改善API的設計與可用性)
- Logic errors (想的跟寫的不一樣,寫的跟需求不一樣)
- Documentation (寫跟維護文件是痛苦的)
- Feeling overwhelmed (找不到切入點)
- Separate interface from implementation thinking (抽象設計)
- Agreement (確保已修正問題的證據)
- Anxiety (改東壞西的擔心受怕)
```
很久沒對 TDD 發表這種長篇大論了,因為不理解、不想理解、不同角度理解的人居多,能真的到各自的塔上用不同角度來看原義,以及實務上用它來幫助解決的問題有哪些的人,真的太少。
大部分人只想針對這個詞彙來攻訐以博得流量跟吸引目光,而不是想著「我可以用它來幫助我什麼」
問題跟需求是中性的,解決問題跟滿足需求的手段與方式有千萬種,不會只有一種,也不會有所謂的對錯,多點角度去了解不同的方法、方式,然後融會貫通,發揮綜效,在實務上用最少的成本與風險來產生最大的價值,這才是真正的目標。
導入敏捷不該是目標,導入 TDD 也不該是目標,目標永遠都是在實務上產生價值、解決問題、滿足需求。
同時也有3部Youtube影片,追蹤數超過44萬的網紅閱部客,也在其Youtube影片中提到,如果好好學「SCRUM」專案管理方式, 你就擺脫加班魔咒,每天準時下班, 甚至可以提前好幾個小時完成工作, 「能提早完成工作的日子」 book們是不是覺得這樣的生活,很棒呢? 其實我們最近也在用「SCRUM專案管理」方式, 開發Podcast的線上課程, 課程設計主要會包含入門到進階的內容, 如...
「敏捷開發書」的推薦目錄:
- 關於敏捷開發書 在 91 敏捷開發之路 Facebook 的最讚貼文
- 關於敏捷開發書 在 軟體開發學習資訊分享 Facebook 的最佳解答
- 關於敏捷開發書 在 我在大陸的日子 Facebook 的最佳貼文
- 關於敏捷開發書 在 閱部客 Youtube 的最佳解答
- 關於敏捷開發書 在 李基銘漢聲廣播電台-節目主持人-影音頻道 Youtube 的最佳貼文
- 關於敏捷開發書 在 Untyped 對啊我是工程師 Youtube 的精選貼文
- 關於敏捷開發書 在 [討論] Scrum敏捷開發是這麼操作嗎? - 看板Soft_Job 的評價
- 關於敏捷開發書 在 91 敏捷開發之路's post 的評價
- 關於敏捷開發書 在 【讀好書】敏捷開發經典(2020/10/06) 的評價
敏捷開發書 在 軟體開發學習資訊分享 Facebook 的最佳解答
🔥 課程特價中
敏捷與持續交付是目前應對真實軟體開發環境的主流方法。
本課程講師是兩本暢銷敏捷書籍的作者:The Agile Samurai 和 The Way of the Web Tester,在/任職 Spotify、ThoughtWorks、Microsoft,曾與許多大公司的團隊合作 (SONY、BMW、Ford 、Tesla、Facebook、Twitter、Apple…等)
通過學習敏捷武士的方式,你將會了解:
✅ 敏捷是什麼? 原理以及重複施行所需的思維方式
✅ 如何建立一個好的敏捷團隊
✅ 傳統瀑布式的角色(如開發人員、分析師、測試人員和專案經理)在敏捷專案中的變化?
✅ 如何建立一個你和你的客戶都可以相信的計劃?
✅ 如何使用敏捷用戶故事在相較傳統少部分的時間內收集到需求?
✅ 如何每週提供一些有價值的東西
✅ 當每日計畫出錯時該怎麼辦? 如何像一個專業人士來矯正這問題?
✅ 敏捷工程的四大要點以及為什麼它們對敏捷 (Agility) 非常重要。
https://softnshare.com/the-agile-samurai-bootcamp/
敏捷開發書 在 我在大陸的日子 Facebook 的最佳貼文
親愛的大家晚安啊~昨天晚上我去了很好的聚會喔!
這個聚會的學名叫「上雲開發者小聚」,白話來說,就是一群工程師的聚會。
現場氣氛輕鬆歡樂,一群工程師在一起聊天,有一種空氣很好的感覺~可能是與工程師在一起,我就特別放鬆吧?
畢竟我短暫的人生中,在一起最久的人大概是工程師了XD
大學四年資管系,同學都是工程師;
畢業後十三年都是網路業,跟工程師們一起熬夜、加班、吵架、做項目。
不管是叫企劃、PM還是產品經理,都是與工程師們相愛相殺的關係啊XD
-----
這個聚會由一位老師發起,報名的話還給便當!
現場是輕鬆的閑聊氣氛,並且解說了資策會的補助計畫,還有抽獎環節~抽便當還有老師寫的書,還有很令人好奇的「區塊鏈桌遊」
我抽到了一本關於上雲的書,很好!
讓我了解一下上雲在工程師的世界里,究竟代表什麼呢~
對我來說,大陸版本的上雲就是:
1.把數據、主程式都放到阿里雲上,上面除了布署之外也有插件可以買,容量可以隨時擴充
2.利用git管理文檔與程式分支,達到文件統一、分開開發的需求
3.利用JIRA做項目管理
4.利用以下工具完成人事、產品經理、設計師的協作
釘釘:遠端協作平台,用於通訊、開會投影、預約會議室、存放文件
墨刀、藍湖、Axure:原型、設計
這一切都base在雲端,雖然主要是阿里雲+git的組成,但未來總有一天會往前打通JIRA、釘釘的?
而台灣是怎樣的我就不清楚啦...這也是我今天去聽的主因,總之多方了解嘛XD
從去年到現在了解下來,只知道台灣的上雲比較偏工業化,都是toB討論的比較多、toC討論的...目前好像在銀行這種大公司階段,涉及服務業的正在開始?
舊企業上雲、新產業直接長在雲上,這個有趣的世界:D
上雲、數位轉型、項目管理、敏捷開發、遠端協作、JIRA、google、facebook、line...我的台灣工作,塞滿了這些詞哈哈。
-----
而為什麼會參加這場聚會呢?來龍去脈是這樣的:
1.2019年
我想著回台灣,但離鄉十年,對我來說台灣是很陌生的,於是想著多認識一些台灣人。從而經由這個粉絲頁認識了李老師,在台北見了一面。
2.2020年
我回到台灣,在台北網路業工作,要學習的事情很多,知道未來的業務中包含上雲。
3.2021年
在臉書上看到老師說「上雲開發者小聚」,我想著先了解一下這圈子的工程師,就跑去參加了。
這個臉書,實在是讓我接觸到很多不一樣的人!
老實說我很容易沉浸在自己的世界里,在去年的時候簡直要沈到海里,自己能溺死自己。
但是在姊姊、同事、北京認識的學長,還有粉絲頁認識的朋友的陪伴下,我一點點慢慢爬起來了。
老師說我是「很厲害的PM」
我好高興呀哈哈哈~我以為我是很任性的PM呢哈哈哈
總之,非常榮幸認識大家,以後請多多指教啦~
敏捷開發書 在 閱部客 Youtube 的最佳解答
如果好好學「SCRUM」專案管理方式,
你就擺脫加班魔咒,每天準時下班,
甚至可以提前好幾個小時完成工作,
「能提早完成工作的日子」
book們是不是覺得這樣的生活,很棒呢?
其實我們最近也在用「SCRUM專案管理」方式,
開發Podcast的線上課程,
課程設計主要會包含入門到進階的內容,
如果有興趣的book們可以持續關注我們。
在製作線上課程的過程中發現
很多平台,從募資到開課,
大部分都要弄到3個月甚至是半年;
但我們預計在一個半月內要上線。
在這方面上就可以顯示,我們的速度已經比業界還要快2到4倍了。
所以「SCRUM專案管理」方式真的很棒,建議book們可以嘗試看看。
▶️《SCRUM敏捷實戰手冊》博客來書籍介紹:https://bit.ly/31nPaLz
👉🏻將於7/6,在YouTube抽出1位幸運兒送出《SCRUM敏捷實戰手冊》~~~
💬抽書資格:只要BOOK們「留言」此次觀看心得、「分享」影片連結,並「訂閱頻道」❤️
💬註:7/5號截止於隔天7/6號公布得獎人,僅限台澎地區
刀刀的解憂信箱✉️: [email protected]
成為大會員:https://youtube.com/閱部客/join 🙇🏻🙇🏻
更多閲部客影片:https://goo.gl/YbtPFh 👏👏
:::::::👊上一集!:::::::
《遠距工作模式》
https://youtu.be/UTCkzt29zDc
:::::::👊【更多影片】:::::::
閱說書▊https://goo.gl/28WFVy
學習的知識▊https://goo.gl/hnGHH1
心理學的知識▊https://goo.gl/PsWGn9
大學系列▊https://goo.gl/PrHMMM
徵求BOOK們一起讓閲部客更好,徵求翻譯者!!!
▶️翻譯閲部客:https://goo.gl/NP1hKi
:::::::👊【關於我們】:::::::
我們是閱部客
我們關注「人生x學習」,並樂於分享知識、傳遞價值,
希望讓生活更聰明、生命更精彩!
閱部客靈魂人物:水丰刀
喜歡書、喜歡玩遊戲、喜歡有趣的學習
快來''訂閱''不要錯過我們每日最新內容唷!!!!
👇你今天''閱''了嗎? 👆
訂閱我們►►https://goo.gl/crn2yo
特別感謝以下成為會員的朋友►►https://goo.gl/pZfqoW
:::::::👊【追蹤我們】:::::::
FaceBooK
https://goo.gl/DM279v
Instagram
https://goo.gl/8W3K2S
Youtube
https://goo.gl/xDvL6R
Twitter
https://goo.gl/wYJoZU
B站
https://goo.gl/MaZ6iw
微博
https://goo.gl/ehj6gh
知乎
https://goo.gl/Gy3B2q
::::::👊【業務合作】:::::::
請聯絡信箱
yuubuke@gmail.com
敏捷開發書 在 李基銘漢聲廣播電台-節目主持人-影音頻道 Youtube 的最佳貼文
本集主題:「拓展你的人生地圖」介紹
訪問作者:郭顺杰 (Soon Kiat Ker)
內容簡介:
《拓展你的人生地圖》是一本很適合中學生、大學生、或者剛出社會工作的人閱讀的一本激勵書,也是給一群正在求學、追求夢想的朋友們的一本借鑒之書。
本書將會從求學、思想、處事、成功等四大篇章,來為讀者點出讓自己卓越傑出,通往成功道路所需具備的思考邏輯與觀念,並點評讀者在社會上常聽到的一些謬論以及大家可能會面對的問題和疑惑。比如,在求學篇中我將會提到,大學文憑到底是不是只是一張紙?隨後,在思想篇當中,我也會為讀者講解為什麼乖孩子難以成功?
當然,市面上關於各種技巧的書多不勝數,有教導成功的技巧、談判銷售的技巧、應對考試的技巧、有泡妞的技巧⋯等等。要知道光學技巧是不夠的,技巧是會跟著時代的改變而改變的。這些技巧總是會有漏洞,會因為文化地理的差異而有所不同,而這些漏洞將會科學式地被研究, 然後我們的後代便會發明一個技巧去填補這一代的漏洞, 下一代技巧的漏洞就會再被下下一代填補上去,如此反復的驗證,這就是科學。
外在的技巧還有另外一個問題,那就是每個人使用出來的效果都不一樣。它是由個人教育、理解程度、領悟力和天分而決定的。我常常把這種技巧,比喻為武俠小說裡面所說的外招,光練外招是不夠的,還必須要修煉「心法」。武功裡面的「心法」指的就是內功、氣和心靈的修煉。
我們除了要掌握技巧和知識之外,還必須訓練處理事情的思維,這種修煉是需要時間的,但是當你修煉了以後, 它就成為你的一部分,不管遇到什麼問題,這個心法都會為你帶來屬於自己的一套方法。
而本書所要帶給讀者的正是一個心法,一個修煉自我的旅程。
本書名為《拓展你的人生地圖》,在 NLP(神經語言程式)的學問中, 其教條中有一句話是這麼說的:「地圖上的界線並不等於真正的地域 」(英文譯:The map is not the Territory)。當年,我在新加坡學習第一階段的 NLP 執行師認證課程的時候,第一次接觸了這個教條,並對於它的含義有著很深的共鳴。所謂的「地圖」,代表的是我們對事物的認知,是由感官經驗、環境所得來的,由我們給予它們意義。而「地域」則類似所謂「絕對真實的世界」, 一個等待我們去突破的領域。有鑒於這樣的啟發,我決定在本書中拓展這樣的思想。
其實,每個人心中都有一個「地圖」,而這個地圖可以理解為框架一個人的行為,成功與否的界限。正如地圖上的界限,它框架著你的活動範圍,能走多遠等等。
在現實生活中,我們的閱歷(教育與上學的程度)、思想、處事方法、對成功的觀念、正決定了我們人生地圖上的界限。本書,我要表達的是地圖上的界線並不等於真正的地域。每個人一生下來,都會受到環境的影響,而為自己繪製各式各樣的地圖。然而,我們不應該被地圖的界限框架了自己,相反地應該勇於拓展未知的領域。
作者希望透過書中的四個篇幅來拓展讀者的人生,讓大家獲得多方面的提升。透過本書,你將理解讀書的重要性、學習讓你卓越的思維模式、處事法則,與建立良好信念的方法。這些心法將讓你飛得更高,走得更遠,人生更卓越!
作者簡介:吳文捷
出生於馬來西亞的柔佛麻坡,通曉中文、英語、馬來語、日語和西班牙語。
他目前在著名會計咨詢「四大」的安永(EY)擔任科技諮詢顧問,主要負責處理業務與流程自動化(RPA)與大數據專案,並曾協助多家國際銀行與 500 強企業制定策略與自動化方案。順杰擁有多個編碼與科技認證,截至目前為止,他已榮獲 Blue Prism、Automation Anywhere、UiPath 高級RPA 研發認證、Python,SAS,區塊鏈等IT認證。此外,他也是專業敏捷(Agile)開發教練與專家,精益六西格瑪黑帶(Lean Six Sigma Black Belt)執行師與樂高團隊組織訓練員(Lego Serious Play® Teamwork Facilitator)等證照。
教育背景方面,順杰 2016 年畢業於英國曼徹斯特大學,主修國際貿易與經濟,隨後他在 2017 年獲得了英國劍橋大學科技政策碩士學位。他致力於研究國家科技管理與法律,包括中小型企業的競爭與創新,網際網路發展的商業策略與社會文化的進程等。
白羊座的順杰,有著一個燃燒不完的學習熱情,工作的同時也熱愛藝術。他獲得了英國皇家鋼琴與吉他 8 級文憑的榮譽。除此之外,他努力鑽研佛教、西方神秘學、哲學、東方儒道家的經典以及塞斯與奇蹟課程等,遍訪名師,積極地探討生命的旅程,並到處授課演講。迄今,他榮獲美國 NLP(Neuro-Linguistic Programming,神經語言程式學)與時間線療法(Time Line Therapy®)高級執行師認證、英國EFT 協會(舊名:AAMET) 情緒釋放技巧治療師,美國NGH(National Guild of Hypnotists,美國國家催眠師協會)催眠諮詢師與日本靈氣三階導師等證照的殊榮。
作者粉絲頁: SK 郭顺杰ᵀᴹ
出版社粉絲頁: 寰宇軒行
請大家支持,我全部六個粉絲頁
李基銘主持人粉絲頁:https://www.facebook.com/voh.lee
李基銘的亂亂分享粉絲頁:https://www.facebook.com/voh.happy
李基銘的影音頻道粉絲頁:https://www.facebook.com/voh.video
漢聲廣播電台「fb新鮮事」節目粉絲頁:https://www.facebook.com/voh.vhbn
漢聲廣播電台「快樂玩童軍」節目粉絲頁:https://www.facebook.com/voh.scout
漢聲廣播電台「生活有意思」節目粉絲頁:https://www.facebook.com/voh.life
敏捷開發書 在 Untyped 對啊我是工程師 Youtube 的精選貼文
不該去美國工作的3個原因 - 美國v.s.台灣・軟體工程師・工作經驗比較-薪水/工時/文化 | Software Engineer in Taiwan v.s. The U.S.
-
有美國夢?想出國工作?想在矽谷當工程師?在美國當軟體工程師跟在台灣有什麼差別?
今天要針對薪水、工時、文化這三個層面來比較美國程序員跟台灣工程師生活與工作上的差別。影片中也會分享我的求學背景跟工作經歷。因為我有在美國跟台灣實習工作過,所以能有比較客觀的看法分享。
薪水:台灣/美國、實習/正職軟體工程師的薪資比較,也會討論稅務跟物價唷!(雖然稅務方面數字有點誤差:P)
工時:軟體工程師一天工作到底是八小時還是無限小時?又是什麼造成工時上那麼大的差別?
文化:比錢更重要的是文化!台灣美國工作環境的文化到底有什麼不一樣呢?產品開發流程的不同?員工工作心態?公司看待員工的方式?工作模式?
只能說這系列的內容真的是乾貨滿滿,是我親身經歷最真實的分享!希望你有滿滿的收穫~
【㊫ 電腦科學/軟體工程 學習資源 📖】
全端工程師密技 Full Stack Eng - Career Path (Codecademy)
https://bit.ly/3niTwLN
前端工程師密技 Front End Eng - Career Path (Codecademy)
https://bit.ly/32K1eql
用Scala學習函式程式設計
https://bit.ly/2IF0Thv
Scala 函数式程式設計原理
https://bit.ly/3kBQXTb
平行程式設計
https://bit.ly/3pCeaZf
Android 應用程式開發 專項課程
https://bit.ly/3lGCUwW
普林斯頓大學 電腦科學 演算法 基礎理論
https://bit.ly/3nxomAh
Go 語言學起來
https://bit.ly/35AWhlv
Parallel, Concurrent, and Distributed Programming in Java 專項課程
https://bit.ly/2IGnlH4
Java 軟體工程基礎課程
https://bit.ly/3fa4gJi
全端開發 跨平台手機app 開發 完整課程
https://bit.ly/2UCGWum
一定要看到影片最後面並且在「YouTube影片下方」按讚留言訂閱分享唷!
-
歡迎留言告訴我你的想法,或是你想認識的程式語言唷!
每(隔週)週六晚上9點更新,請記得開啟YouTube🔔通知!
-
【相關連結】
影片中根據的美國所得稅計算機:[https://goodcalculators.com/us-salary-tax-calculator/]
【愛屋及烏】
Facebook 臉書粉專 [https://www.facebook.com/untyped/]
圖片影片:微信表情包 [giphy.com] [pexel.com] [pngwave.com]
-
Untyped - There are so many data types in the world of computer science, so are the people who write the code. We aim to UNTYPE the stereotype of engineers and of how coding is only for a certain type of people.
對啊我是工程師: 是個致力於推廣電腦科學給各領域族群的頻道,更希望想嘗試卻又不敢踏入的人有更多機會了解 Computer Science。
By 一個喜歡電腦科學邏輯推理,在科技圈努力為性別平等奮鬥的女軟體工程師。
#美國工作 #軟體工程師 #台灣美國比較
【Disclaimer 聲明】
Some links are affiliated.
上面有些連結是回饋連結,如果你透過這些連結購買商品,我可以得到一些小獎勵,但不會影響到你購買的價格,甚至會是更低的價格!謝謝你的支持💕
敏捷開發書 在 [討論] Scrum敏捷開發是這麼操作嗎? - 看板Soft_Job 的推薦與評價
最近在工作上遇到主管採用敏捷開發的管理模式,剛好在論壇上在報導高雄某間醫院的資
訊室在程式專案開發所採用的管理模式。
報導標題提到”擁抱敏捷開發全臺第一家的醫院IT”,於是好奇看了報導內容。
看完之後,覺得是不是真的懂什麼是Scrum、迭代循環(黑人問號狂冒出)。
內容當中提到兩點:
1. 系統開發過程,不再跟使用者爭辯,為什麼這次提出的需求,又跟上次不一樣,「溝
通衝突無益於系統本身,」她強調:「不一樣沒關係,我們改就對了!確定完成的功能是
使用者要的,更重要。
2. 盡可能地不要撰寫詳細的開發需求書,使用者只需提出申請,簡單說明想要完成的事
。但是,資訊室不會要求使用者一開始就能提出明確的需求。
所以不用詳細規格書? 不用跟使用者討論內容? 只要使用者提出需求意見,說什麼就做
什麼!
Scrum是這麼操作運作?!
報導來源:https://www.ithome.com.tw/people/119258?
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 27.242.70.169 (臺灣)
※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1686448325.A.5C6.html
... <看更多>