XP 与持续集成解决了软件工程不接地气的一面;所有的软件工程实践的产出, 都没法与产品的代码建立起直接的关连。也就是说,所有的软件工程的实践都没法及时的反映出产品代码的现况。

Scrum 又将软件开发拉回到软件工程般不接地气的场景;从 Backlog 的管理、站立会议、到回顾会议,都没法及时的反映出产品代码的现况。许多人都会说,这不是 Scrum 不接地气,而是团队的 XP、持续集成上的问题。但大多数实际的情况是,Scrum 使得不想写代码、甚至是不会写代码的一群人,也能对团队进行辅导、指指点点。

远离代码的敏捷教练与软件工程的顾问是一样的;都只是会引导着团队离代码越来越远, 离用户越来越远、离市场越来越远。

DevOps 让我们认知到,我们是可以有个软件架构的思维、方法,能在软件开发的阶段就能预期、评估出软件产品在运维时的状况。也就是说,是先有了这样的软件架构的思维、方法的诞生,才有了 DevOps。

然而, 同样的历史又再度的重演;DevOps 又再度使得不懂架构设计的、没进过机房的一群人,在对着团队进行辅导、指指点点。使得 DevOps 只是场加入了运维人员的 Scrum 大戏;也同样没法及时的反映出产品代码的现况,更不用说是持续交付、持续部署。

不要远离代码、更不应对软件架构是无知的; 代码、软件架构才是在软件这行的我们, 所应具备的 Common Sense。

发表评论

电子邮件地址不会被公开。 必填项已用*标注

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据