[Accelerate State of DevOps 2021 快速摘要]
找一些自己有興趣的地方, 快速用 Google 翻譯一下
主要發現
1. 表現最好的人正在成長並繼續提高標準
在我們的研究中，優秀的執行者現在佔團隊的 26%，並且縮短了他們對生產變更的準備時間。該行業繼續加速發展，團隊從中看到了有意義的好處。
2. SRE 和 DevOps 是互補的理念
利用我們的站點可靠性工程 (SRE) 朋友概述的現代運營實踐的團隊報告了更高的運營績效。優先考慮交付和卓越運營的團隊報告了最高的組織績效。
3. 越來越多的團隊正在利用雲，並從中看到了顯著的好處
團隊繼續將工作負載轉移到雲中，而那些利用雲的所有五種功能的團隊會看到軟件交付和運營 (SDO) 性能以及組織性能的提高。多雲的採用也在增加，因此團隊可以利用每個提供商的獨特功能。
4. 安全的軟件供應鍊是必不可少的，也是驅動性能的驅動因素
鑑於近年來惡意攻擊的顯著增加，組織必須從被動實踐轉變為主動和診斷措施。在整個軟件供應鏈中集成安全實踐的團隊快速、可靠和安全地交付軟件。
5. 良好的文檔是成功實施 DevOps 功能的基礎
我們第一次測量了有助於這種質量的內部文檔和實踐的質量。擁有高質量文檔的團隊能夠更好地實施技術實踐並整體表現得更好。
6. 在充滿挑戰的情況下，積極的團隊文化可以減輕倦怠
團隊文化對團隊交付軟件和實現或超越組織目標的能力有很大影響。在 COVID-19 大流行期間，具有生成性 1,2 文化的包容性團隊經歷較少的倦怠。
=========================================================
Technical DevOps capabilities
我們的研究表明，通過採用持續交付進行 DevOps 轉型的組織更有可能擁有高質量、低風險和具有成本效益的流程。
具體而言，我們衡量了以下技術實踐：
• 鬆散耦合架構
• 基於主幹的開發
• 持續測試
• 持續集成
• 使用開源技術
• 監控和可觀察性實踐
• 數據庫更改管理
• 部署自動化
我們發現，雖然所有這些實踐都改進了持續交付，但鬆散耦合的架構和持續測試的影響最大。
例如，今年我們發現，達到可靠性目標的精英執行者採用松耦合架構的可能性是低績效同行的三倍。
松耦合架構 (Loosely coupled architecture)
我們的研究繼續表明，您可以通過努力減少服務和團隊之間的細粒度依賴關係來提高 IT 性能。事實上，這是成功持續交付的最強預測因素之一。使用鬆散耦合的架構，團隊可以相互獨立地擴展、失敗、測試和部署。團隊可以按照自己的節奏前進，小批量工作，減少技術債務，並更快地從失敗中恢復。
持續測試和持續集成
與我們前幾年的發現類似，我們表明持續測試是成功持續交付的有力預測因素。達到可靠性目標的精英執行者利用持續測試的可能性是其 3.7 倍。通過在整個交付過程中結合早期和頻繁的測試，測試人員與開發人員在整個過程中一起工作，團隊可以更快地迭代和更改他們的產品、服務或應用程序。您可以使用此反饋循環為您的客戶提供價值，同時還可以輕鬆整合自動化測試和持續集成等實踐。
持續集成還改進了持續交付。達到可靠性目標的精英執行者利用持續集成的可能性是其 5.8 倍。在持續集成中，每次提交都會觸發軟件的構建並運行一系列自動化測試，這些測試會在幾分鐘內提供反饋。通過持續集成，您可以減少成功集成所需的手動和通常複雜的協調。
持續集成，由 Kent Beck 和它起源的極限編程社區定義，還包括基於主幹的開發實踐，接下來討論。
基於主幹的開發
我們的研究一致表明，高績效組織更有可能實施基於主幹的開發，其中開發人員小批量工作並經常將他們的工作合併到共享主幹中。事實上，達到可靠性目標的精英執行者使用基於主幹開發的可能性是其 2.3 倍。低績效者更有可能使用長期存在的分支並延遲合併。
團隊應該每天至少合併他們的工作一次——如果可能的話，一天多次。基於Trunk的開發與持續集成密切相關，所以你應該同時實現這兩種技術實踐，因為它們一起使用時影響更大。
部署自動化
在理想的工作環境中，計算機執行重複性任務，而人類專注於解決問題。實施部署自動化可幫助您的團隊更接近此目標。當您以自動化方式將軟件從測試轉移到生產時，您可以通過實現更快、更高效的部署來縮短交付週期。
您還可以降低部署錯誤的可能性，這在手動部署中更為常見。當您的團隊使用部署自動化時，他們會立即收到反饋，這可以幫助您以更快的速度改善您的服務或產品。雖然您不必同時實施持續測試、持續集成和自動化部署，但當您將這三種實踐結合使用時，您可能會看到更大的改進。
數據庫變更管理
通過版本控制跟踪更改是編寫和維護代碼以及管理數據庫的關鍵部分。我們的研究發現，與表現不佳的同行相比，達到可靠性目標的精英執行者進行數據庫變更管理的可能性要高 3.4 倍。此外，成功進行數據庫變更管理的關鍵是所有相關團隊之間的協作、溝通和透明度。雖然您可以從特定的實施方法中進行選擇，但我們建議，無論何時您需要對數據庫進行更改，團隊都應在更新數據庫之前聚在一起並審查更改。
監控和可觀察性
與前幾年一樣，我們發現監控和可觀察性實踐支持持續交付。成功實現可靠性目標的精英執行者的可能性是其 4.1 倍
擁有將可觀察性納入整體系統健康狀況的解決方案。可觀察性實踐讓您的團隊更好地了解您的系統，從而減少識別和解決問題所需的時間。我們的研究還表明，具有良好可觀察性實踐的團隊會花更多的時間進行編碼。對這一發現的一種可能解釋是，實施可觀察性實踐有助於將開發人員的時間從尋找問題的原因轉移到故障排除並最終回到編碼上。
開源技術
許多開發人員已經利用開源技術，他們對這些工具的熟悉是組織的優勢。閉源技術的一個主要弱點是它們限制了您將知識傳入和傳出組織的能力。例如，您不能聘請已經熟悉您組織工具的人，開發人員也不能將他們積累的知識轉移到其他組織。相比之下，大多數開源技術都有一個社區，開發人員可以使用它來提供支持。開源技術具有更廣泛的可訪問性、相對較低的成本和可定制性。達到可靠性目標的精英執行者利用開源技術的可能性是其 2.4 倍。
我們建議您在實施 DevOps 轉型時轉向使用更多開源軟件。
source: https://cloud.google.com/devops
技術債 在 [請益] 解決不了別人的技術債真的是自己問題嗎- 看板Soft_Job 的推薦與評價
又是代po 跟前一篇不同人
直接貼上了不解釋
鄉民好
個人想請益
最近在軟體專案遇到不知所措的問題
即使最近習慣了莫名其妙龐大的程式碼
但要去修改居然會有 人為因素 上的難度
我簡單描述整個程式的狀況
就是class不是有成員函式之類的嗎
本來這個class單體模式就只給一個裝置使用
但因為後來考慮第二個裝置的實作
所以先前人的做法就是…
在一樣的class裡成員函式copy paste然後名稱後面補個2 然後因為又是保持單體模式
就變成一大堆函式都有類似以下寫法
if 裝置一
程式碼一
else if 裝置二
程式碼二
其中程式碼一 和程式碼二幾乎超過百行 根本看不出一不一樣
我想說物件導向的介面不會寫就算了 麻煩重複的程式碼用函式先暫時包起來好嗎…
說到這裡應該高手已經知道怎麼處理這鬼結構 但是 這難度最麻煩的是 人
因為就是某個資深工程師寫
當然已經 溝通過了 但回答是
「那些做法就是debug的時候很好用啊，怎麼了嗎？」
「從頭改需要時間，就算改好程式保證正常嗎？出事誰負責？」
「你能想想現實面的問題嗎？公司不是給你用來玩實驗的。」
「你可以從小地方慢慢改起啊，一定要一次動那麼多地方嗎？」
「拜託請你考慮別人請不要那麼自私。」
然後繼續過著大家加新功能修改功能還要順便整理他很有產量的程式碼。
所以怪我囉？
為什麼我還要配合別人的智商做事情
而且你還待十幾年
連C++好用的語言特性都不會用 更不肯學
還好意思裝忙 說什麼急著趕案子
那種鬼寫法是最拖時間的最玩命的吧
整間公司也莫名其妙
不好好整頓他居然還隨便期待有其他還不到一年的員工
可以解決這個每天被他拉出的x code
我現在是攤手沒輒 不太想再留在那浪費時間
在其他工作我也沒看過如此奇葩的現象
各位看的鄉民覺得是我的錯嗎
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 110.28.42.7 (臺灣)
※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1573055871.A.BB3.html
他說那個架構太核心
也剛好是他改的
所以舉凡各種不同種類的功能新增
都要好好加進他的x碼兩次
如果有函式增加的話
請自己把函式取名一號和二號喔謝謝
他也不想改 不過被老闆指定了無奈
他也謝謝你們放棄掙扎開始重找工作
The End
※ 編輯: bb0x0 (27.52.236.218 臺灣), 11/07/2019 18:54:46
... <看更多>