比较和对比软件体系结构策略的方法有哪些？

Question

我目前正在从事一个Android项目，我已经得出结论，需要为应用程序体验的核心部分进行重构。让我们把这部分的体验称为“搜索”。

通过查看bug报告、静态分析工具和代码本身，应该在重构中对搜索进行优先排序。

由于搜索是一个核心组件，我想建议我的业务使用TDD原则进行重构。这将需要重写应用程序的搜索部分，以利用TDD。

一些团队成员要求将现有的代码体系结构与我想提出的架构进行比较。他们本质上想让我证明我的新方法会使项目受益。

以前我还没有深入到这样的比较中去，我也不知道最好的方法是什么。

除了静态分析和UML建模之外，还有其他方法来展示软件体系结构的优缺点吗？

Answer 1

证据太过分了。你不是研究员。你是个暗号猴子。你需要的是他们的信心。

你可以通过政治来获得它。这一策略有时会奏效，尽管我个人对此很反感。您可以通过最简单的演示来获得它。你可以通过在某个周末偷偷摸摸，写一些英雄代码，在他们知道发生了什么之前，把它全部转化成这样就可以得到它。

在这三种方法中，我推荐最小限度的演示。这就是让团队买下的那个。您在这里的大部分精力都不是关于代码的。这将是关于改变一种文化。表明你已经准备好为这些想法辩护，反对那些讨厌学习他们之间的任何东西并按时回家的野蛮怀疑论者。

虽然我个人很想做第三种选择，但我知道从长远来看，它是行不通的。即使你解雇了每个人，带来了一个新的团队，他们只看过TDD模式下的代码库，你仍然会遇到麻烦，人们只是不烦恼和不理解。

当TDD做得半心半意的时候，它就不起作用了。你需要给人们一个关心和相信它的理由。因为当他们不这样做的时候，它可能会失败。因为这不是一个宗教，这意味着一个好的，热情的演示。

您需要诚实地向他们展示TDD可能造成的问题。假装跟随它的陷阱和错误的想法。这样做，他们就不会认为你是蛇油销售员了。

其中一个神话是TDD解放了你对设计的需求。不是的。TDD强制进行只能改进设计的体系结构更改，但这些更改不应该是设计的终点。TDD给你的测试，让你把自己画到角落，油漆你的方式回来，而不锯一个洞在墙上。灵活的设计态度意味着代码库将反映当今最好的智慧。不是昨天。

可悲的事实是，没有多少是要与你个人的业务目标一致。你应该展示的是，当你有好的测试时，对不断变化的目标做出反应是多么的容易。

你不应该让他们看到你在挣扎。练习要执行的转换和重构。把这当成一次面试。你真的需要做好这件事。

或者你可以做第四种选择。只要你能偷偷地加入测试，并希望有一天有人会关心在你之外维护它们。我看过很多次了。这是行不通的，而怀疑者最终更相信他们一直都是对的。