XP 與持續集成解決了軟體工程不接地氣的一面;所有的軟體工程實踐的產出, 都沒法與產品的代碼建立起直接的關連。也就是說,所有的軟體工程的實踐都沒法及時的反映出產品代碼的現況。

Scrum 又將軟體開發拉回到軟體工程般不接地氣的場景;從 Backlog 的管理、站立會議、到回顧會議,都沒法及時的反映出產品代碼的現況。許多人都會說,這不是 Scrum 不接地氣,而是團隊的 XP、持續集成上的問題。但大多數實際的情況是,Scrum 使得不想寫代碼、甚至是不會寫代碼的一群人,也能對團隊進行輔導、指指點點。

遠離代碼的敏捷教練與軟體工程的顧問是一樣的;都只是會引導著團隊離代碼越來越遠, 離用戶越來越遠、離市場越來越遠。

DevOps 讓我們認知到,我們是可以有個軟體架構的思維、方法,能在軟體開發的階段就能預期、評估出軟體產品在運維時的狀況。也就是說,是先有了這樣的軟體架構的思維、方法的誕生,才有了 DevOps。

然而, 同樣的歷史又再度的重演;DevOps 又再度使得不懂架構設計的、沒進過機房的一群人,在對著團隊進行輔導、指指點點。使得 DevOps 只是場加入了運維人員的 Scrum 大戲;也同樣沒法及時的反映出產品代碼的現況,更不用說是持續交付、持續部署。

不要遠離代碼、更不應對軟體架構是無知的; 代碼、軟體架構才是在軟體這行的我們, 所應具備的 Common Sense。

發表評論

您的電子郵箱地址不會被公開。 必填項已用*標註

此站點使用Akismet來減少垃圾評論。了解我們如何處理您的評論數據