DevOps 每日一句 | 重新認識 DevOps

每日一句

DevOps 每日一句

過往以來我們經常看見以工廠生產線的方式來比喻軟體開發交付流程。但我相信有實際參與過軟體開發工作的團隊，恐怕多少都曾感受 …

時間與成本是有限的，而能夠追求的軟體品質可能是無限的。不論是傳統的瀑布法或近年被講到爛的敏捷開發，都難以在『測試』這件 …

DevOps 並非是一個橫空出世的全新關鍵字。它更像是經過了這麼多年，隨著 Dev 與 Ops 兩邊的工作者逐步發展出 …

本日金句出自關於 DevSecOps 的書，作者提到我們既然我們會累積欠下『技術債』，當然當你開始更多的關注 …

想要在團隊內倡議一項新的事物？先問一個問題，你有先找到你的暗樁（追隨者）嗎？畢竟萬事起頭難，即便眾人理智上知道新倡議 …

不只是『部署』，整個軟體開發生命週期內的任一環節遇到規模化時，都會有對應的問題需要面對。即便是 CI/CD …

因此撇開是不是導入 DevOps，其實你總是需要面對『變革』。與其抗拒，不如早點接受變革的必然性，即早開始培養一個『擁 …

自動化測試能夠為你的軟體開發加上一道守護。讓自動化測試成為一道驗證機制，避免發生修 A 壞 B 這種窘境。試想，你今 …

就如金句所言，如果想要交付價值給客戶，讓使用者買單。我們不僅要交付能滿足需求之『正確的產品』。同時我們也需要『正確地 …

這金句讓我想起了『知識的詛咒』，我們很容易誤以為他人與自己擁有相同的背景知識，誤以為他人與自己擁有相同的共識，這樣的誤解 …

是的，很不幸的往往我們遇到的都不單純是『技術』問題，而是牽涉溝通、協作與文化層面的『人』的問題。又或者，你遇到的其實是 …

『變化』大概是軟體開發中唯一不變的事情了。軟體開發確實一直在變，需求、程式碼、環境、軟體架構、系統架構、組織架構、團隊 …

是的，DevOps 就是如此！因地制宜並多管齊下的去提升交付價值的效率。如果引入合適的工具可以加快交付價值的效率，那 …

隨著技術演變，個人電腦、網際網路、智慧型手機、APP⋯⋯，軟體透過不同的形式普及至我們日常生活的各處。如今我們每日使用 …

再一次的溫伯格在書中提到，他將家庭治療師薩提爾的內容運用在軟體專案中。薩提爾利用『人際互動模型 …

溫伯格在書中引用了家庭治療學家薩提爾女士的話。這句話直白的回答了一個問題，為什麼推動『變革/改善』是如此的困難？這也 …

什麼是『軟體品質』？這也是一個問不同的人會得到不同答案的問題。雖然我們可以找到一些關於『軟體品質』的定義與規範，但當 …

導致團隊無法頻繁交付的原因有哪些？是什麼導致每交付一個新版本都需要花費許久的時間？上述問題的答案可能會有很多種，但其 …

什麼樣的交付才能為客戶帶來價值？ 1.本週完成了資料庫架構設計？ 2.這個 Sprint 完成了三個功能的自動化測試？ …

那麼你相信嗎？你相信客戶、老闆或業務單位告訴你的那句『這個需求已經定案了』嗎？面對現實吧，需求與規格總是在變，變化本就 …

作者簡短扼要的一句話，帶出了重點。在談論『可觀測性』時，我們通常會先想到 Ops 或 SRE 領域內的技術議題，你用哪 …

站在收集回饋資訊，以便產生改善措施的角度來看，針對軟體開發生命週期進行『度量 / 測量』，這似乎是一件重要且必做的事情。 …

非常有意思的一句話，既然維持現況看似一切都能繼續，馬照跑、舞照跳、薪水照領，那為什麼我要多問一些？多做一些？多學一些？ …

對於世界、社會、組織、團隊、人類保持好奇的眼光。以開放的思維與心態，對於既有的組織架構、工作流程、分工與協作模式，持續 …

程式碼過多不是一件好事，這會導致後人無法輕易的解讀，造成後續維護及變更程式碼的困難度與成本。反之，程式碼過於精簡也不是 …

喔，我喜歡這個詮釋。既然 DevOps 已經被發展成是一個涉及組織變革議題的關鍵字，並且還在持續被演化中，那麼將 …

我們都想要持續改善，但我們也都知道資源是有限的。當你什麼都想做時，往往也就什麼都做不成。這也是為什麼 DevOps …

作者說純粹浪費工時的行為，就是直接的浪費；非直接投入在軟體開發的工時，但有產生其他效益的活動，則是間接的浪費。前者沒有 …

想要讓生病的人願意接受醫療，首先必須要讓他們有病識感，病人必須能看見、識別或意識到自己生病了，接著才能針對問題去對症下藥 …

開發者如何確保自己不是 bug 的製造者，避免產出 bug 為交付價值帶來浪費。是開發者沒有寫測試的緣故？是軟體架構 …