如果编码变得更快，架构应该在何时进行？
一个功能可以正常工作，测试通过，拉取请求（PR）也不大。业务希望进行实时测试。没有人想因为架构问题而阻碍价值交付，尽管这个问题在当下听起来可能有些抽象。
但这似乎变得越来越困难。
人工智能辅助开发、快速编码、内部工具和更好的框架都减少了生产代码的摩擦。这是有益的。团队可以更快地进行原型设计，并更早地发布实验。
问题在于，架构判断并没有变得同样便宜。
代码可能正常工作，但仍然会使系统变得更糟：逻辑重复、所有权不清晰、模式不一致、安全漏洞、边界不明确、应当可重用的单一组件，或者后续难以删除的功能。
一种选择是强制在代码审查中引入更多架构内容。但这样一来，PR就会变得缓慢、令人沮丧，并充满难以解决的设计争论，因为代码已经存在。
另一种选择是加快合并速度，同时使合并后的架构反馈循环更加明确。架构本应是持续的，但更快的代码创建可能需要更强的合并后机制：审查系统级别的变化，检查重用机会，重新评估安全假设，安排重构，保持功能在标志后面，并愿意禁用或重写某些内容。
这只有在“稍后重构”成为一个实际流程，而不是一个愿望时才有效。
随着代码生产变得更容易，您的团队是否改变了处理架构的方式？您是在合并之前、合并之后，还是通过某种持续审查流程来处理这个问题？
返回首页
最新
我刚刚查看我的主屏幕，突然发现我的iPhone上安装了《荒野乱斗》。我从未安装过这个应用，似乎是自动安装的。
我热爱HN，不想看到它消亡。<p>但是机器人账号每天都在增加。需要采取更激进的措施。