我经常听到有人说你不应该急于采用新技术,直到它们变得稳定,经过试验和测试.关于如何正确使用3个版本甚至还有一个笑话.这可能是现实生活体验的声音,但至少有时这种姿势是自满,抵制变革和学习新技能所需的努力的结果.
但是,在我看来,软件行业的成功与创新保持同步至关重要.虽然大公司有整个部门致力于研发,但在较小的公司中,开发团队必须跟上.即使在正式推出之前就开始使用新技术 - 这将为您提供一些启动,并帮助您跟上其他技术.
这是我尽可能遵循的策略:
到目前为止,我从来没有付出过于热衷于跳上一些新技术列车的代价,但我仍然获得了好处.我想知道这只是巧合,还是早期采用者毕竟不是那么危险？
这个问题肯定是有争议的和主观的,而不是邀请就早期采用这个问题进行讨论,我希望听到现实生活中的经验,即采用早期新技术被证明是一个严重的错误,而且必须付出沉重的代价.支付.
规则引擎通常在商业人员可以直接修改应用程序的一些非常动态的部分的前提下销售,而无需开发人员的任何参与或编程.
在我看来,投入生产任何未被自动化测试覆盖的代码都会带来严重的风险.我知道许多规则引擎实际上是一个规则管理环境,包括版本控制,环境之间的升级等等但是他们为BA编写测试提供了哪些支持？我已经看到一些文档似乎将JUnit等框架集成到引擎中,这肯定不是非程序员会做的类型或编程.
BA可以通过业务引擎轻松更改规则,但是如果没有程序员的帮助,他可以轻松编写可以覆盖它的测试吗？在实践中如何解决规则测试覆盖问题？