当您无法更改其他文件时打破依赖关系？
我正在对一个项目进行一些秘密敏捷开发。首席程序员认为单元测试、重构等是浪费资源，而且没有办法说服他不这样做。他的理念是“如果它没有坏，就不要修理它”，我理解他的观点。他已经在这个项目上工作了十多年，并且对代码了如指掌。我不想讨论开发实践。
我是该项目的新手，我的任务是添加新功能。我之前曾参与过遗留项目，并使用敏捷开发实践取得了良好的结果，但这些团队更容易接受这个想法，并且不害怕对代码进行更改。
我被告知我可以使用任何我想要的开发方法，但我必须将我的更改限制为仅添加该功能所需的更改。我在编写的新类中使用了 tdd，但由于全局变量的自由使用以及我需要与之交互的类中的高耦合，我不断遇到障碍。通常，我会开始提取这些类的接口，并通过将它们作为构造函数参数或公共属性注入来显式地显示它们对全局变量的依赖。
我可以说这些改变是必要的，但考虑到领导者从来没有必要做出这些改变，我怀疑他会以我的方式看待它。我可以使用哪些技术来打破这些依赖关系，而又不会激怒首席开发人员？
我已经使用以下方法取得了一些进展：
- 提取接口（对于我正在创建的新类）
- 使用测试存根扩展和覆盖任性的类。 （幸运的是，大多数方法都是公共虚拟的）
但这两个只能让我到目前为止。
注意
领导者的部分职责是审核代码提交。他可能会认为反腐败层往好了说是过度的，往坏了说是一种侮辱。
I'm doing some stealth agile development on a project. The lead programmer sees unit testing, refactoring, etc as a waste of resources and there is no way to convince him otherwise. His philosophy is "If it ain't broke don't fix it" and I understand his point of view. He's been working on the project for over a decade and knows the code inside and out. I'm not looking to debate development practices.
I'm new to the project and I've been tasked with adding a new feature. I've worked on legacy projects before and used agile development practices with good result but those teams were more receptive to the idea and weren't afraid of making changes to code.
I've been told I can use whatever development methodology I want but I have to limit my changes to only those necessary to add the feature. I'm using tdd for the new classes I'm writing but I keep running into road blocks caused by the liberal use of global variables and the high coupling in the classes I need to interact with. Normally I'd start extracting interfaces for these classes and make their dependence on the global variables explicit by injecting them as constructor arguments or public properties.
I could argue that the changes are necessary but considering the lead never had to make them I doubt he would see it my way. What techniques can I use to break these dependencies without ruffling the lead developer's feathers?
I've made some headway using:
- Extract Interface (for the new classes I'm creating)
- Extend and override the wayward classes with test stubs. (luckily most methods are public virtual)
But these two can only get me so far.
Note
Part of the lead's responsibilities is to review code submissions. He would likely interpret an anti-corruption layer as excessive at best and an insult at worst.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您应该创建一个反腐败层，基本上在您和使用包装器类的“专家”代码之间保留一个层。这将是处理这种废话的代价。
还有一些模拟框架允许您不必更改现有代码，但这些框架可能会比简单的包装类给您带来更多政治上的麻烦。
You should create an anticorruption layer, where you basically keep a layer between you and the "expert's" code using wrapper classes. This will be the price of dealing with such nonsense.
There are also some mocking frameworks that allow you to deal with not having to change existing code, but these would probably get you into more trouble politically than simple wrapper classes.
在这种情况下，反腐败层可能会起作用，但你必须小心，因为太多的反腐败层会导致非常可怕的结果。
有了这样一个层，您就可以威胁系统的其余部分，就像威胁外部资源一样。
In such a case, an anti corruption layer might work, though you have to be careful as too many of these lead to pretty horrible results.
With such a layer, you could threat the rest of the system as you would threat external resources.