DevOps扼殺的不是開發者，而是開發生產力！

此前，研發頻道曾發表過一篇文章《DevOps正在扼殺程序員？ 》該文引發了CSDN網友們的激烈探討。有人認為，DevOps的流行讓越來越多的程序員身兼多職，而這種流行趨勢正在扼殺真正的程序員。而在這篇文章中原文作者Jim Bird則認為DevOps扼殺的不是開發者，而是開發本身和開發生產力。

文章譯文如下：

所幸到目前為止，暫時還沒有看到哪個開發者受到了如此重大的打擊。真正受到Devops影響的是開發本身和開發生產力。敏捷開發如上了膛的槍支，而Devops正扣在扳機上。

交付被工作流取代

開發的規模和重心持續收縮，因此花在決策上的時間相應減少。從前需項目團隊花一年才能完成的交付演變為只給開發團隊一個月，甚至是要求開發者獨立在幾周內就完成?，F在，完成的意思是已發布完畢而不僅僅是完成代碼工作。

持續交付和持續開發取代了持續集成。如此快速的產品上線節奏，測試用時越發變得稀缺，這也意味著開發者不得不演變為“超人”，既要搞代碼，又要兼顧測試，既要對內，又要對外。

Devops活生生就是多快好省的代名詞，最終目的就是推動產品上線，不斷加快工作流的速度。再三強調的標準化自動化，開發周期的一再壓縮，軟件開發仿佛一下子就從工程的范疇蛻變成制造和生產控制的領域。

Devops在消磨開發生產力

不論是采用LOC(Lines Of Code)還是別的計量方法，開發者的代碼量輸出都在持續萎縮，因為他們要把時間分配到運營工作中。但時間恰恰是個可惡的零和游戲，這邊多的恰是那邊少的。幫助運營團隊查找和解決問題，回復客戶的咨詢和疑問，監控系統，幫助執行A/B測試……面對如此繁重的任務清單，還能要求開發人員寫出原來一樣的代碼嗎？

亟需改變的期望值、度量方法以及激勵措施

在Devops中，不論Dev還是Ops，他們的工作已經發生了改變，因此需要采取應對措施來順勢而為。期望值、度量方法以及激勵措施應成為應對措施中的關鍵組成。

Devops的成敗需要由運營相關的度量來判別，無關乎項目交付目標或者產品設計目標。比方說：

• 對于重大變更或問題能否快速響應：把籌備周期開發周期的重心從交付里程碑上轉移到實際產品；
• 能否快速把變更應用到實際產品中，以天/小時/分鐘來衡量；
• 錯誤的頻率，變更次數/錯誤次數的比率；
• 系統可靠性的考量，例如用MTBF，特別是MTTD和MTTR；
• 變更的成本，總體營運成本和支持成本的分析。

Devops更著重于Ops

由于越來越來的軟件被更迅速和頻繁地推出，開發轉變成維護。項目管理被突發事件管理和任務管理取代。計劃制定的范圍變得越來越窄，或者說是受到高優先度事件編排的制約。

Dev在慢慢轉變成Ops。電商行業尤甚，購物平臺一旦推出，客戶開始使用后，如果作出變更，所有前期制定的工作和計劃都不得不跟著改變，可謂牽一發而動全身。對于開發者來說，目前的大環境充耳皆聞的是有關精簡和培訓的理論，強調更多的責任和義務，更為關注發布和部署環節，對開發本身的冷淡程度每況愈下。

開發者和他們的管理者們需要適應這種轉變，這或許就是將來軟件產業的真實寫照。但這不是所有人都喜歡看到的，或者說能很好地完成角色轉換的。

英文出自： Dzone

生活不易，碼農辛苦
如果您覺得本網站對您的學習有所幫助,可以手機掃描二維碼進行捐贈