Java 建议重新设计项目

我的问题是一般性的，我甚至不确定这样的问题是否被允许，但在过去的几个月里，这一直困扰着我，我在其他地方找不到任何关于这方面的东西。我应该提到的是，我仍然是一名初级开发人员，这可能是我在整个事情上犯了错误，但这里什么也没有发生

我目前的任务是维护和进一步开发Android应用程序。在我接手之前，对它所做的工作最好的描述是“至少它能工作，但不是真的”。大部分功能都存在，伴随着大量间歇性出现的小错误以及其他多任务和异步行为问题和限制

没有达成一致的设计，我想这表明没有对如何构建整个东西进行适当的研究，javadoc几乎不存在。我相信它只是从进口到这个项目的来源，而不是从零开始的

用技术术语来说，这是一个残废的MVC，其特点是厌食症模型（getter、setter、no behavior）和饥饿视图（只是必要的小部件）以及以活动形式出现的病态肥胖控制器的自助餐，以弥补这一切。这些活动负责处理业务逻辑、用户交互、数据操作以及网络通信——从解析消息一直到根据服务器的响应启动新活动

显然，每一个问题都必须在活动中得到处理，但解决办法越来越受到限制，越来越狡猾。我有另一个维护iOS版本的开发者加入进来，他对事态的发展感到非常震惊，还有一个高级开发者几乎说“没办法，做你能做的”

总之，这篇文章的重点是，我想把一些细节转移到模型中，让它负责服务器通信以填充数据，并有自己的行为来提供给控制器和维护自己。这一变化将几乎完全使活动与直接处理服务器通信分离，而现在将重点放在业务逻辑和用户交互上

---

有过类似经历的人最终会做什么？结果如何？

你真的有两个选择1）你是否重构2）你是否从头开始反向工程应用程序。如何实现新代码取决于您。无论您选择哪个方向，都必须考虑测试。我不是说TDD，但你的主要问题是，所有东西都混在一起，不稳定/不稳定。去耦合方法听起来确实是正确的选择（使用任何适合实现这一目标的模式——最好的MVC、MVP、MVVC等），将Android框架从您的业务逻辑中移除，因此您使用纯java的左撇子将有助于简化测试过程。@MarkKeen是对的，但有一点需要考虑：时间。从头开始是一项不错的投资，但需要时间。另一方面，重构可能会花费更少的时间，但这取决于。。。所以，在开始做任何事情之前，先做一些估计，并和你的雇主谈谈。@AnixPasBesoin-我不可能知道的事情：可用的资源、时间尺度等等。。。这就是为什么我说了两个选择——每个选择的影响将由OP决定。@AnixPasBesoin感谢你们两位的评论。从头开始可能是不可能的。这将立即引起警报，我建议的版本3.0可能弊大于利。目前，重构是唯一的选择，我很想找到一些关于这个主题的好书，到目前为止，我偶然发现了一些网站上有有趣的信息。在我采取行动之前，我必须仔细阅读，在我走向管理层并告诉他们我有一个伟大的想法之前，我必须先进行测试并采取行动。@mark渴望澄清，作为整个项目的初级开发人员，只有我，目前没有其他帮助，也没有第一篇文章中提到的文档或设计原则。我相信他们也在努力争取尽快发布，我不责怪他们，这肯定已经酝酿了很长时间了。