[个人见解] 本项目的设计对于简单需求过于复杂，导致预期修改正确比较困难。 搜索了一下 login 这个功能点，该页面的正确性关联7个文件。

[bronze1man]

本issues 是个人基于之前项目实际需求场景 对本项目代码框架的见解。如果贵方需求（特别是变更需求）不是那么简单需要进行这种复杂的分割方能理解，建议基于实际讨论/给出相关参考信息链接。

• 问题：本项目的设计对于简单需求过于复杂，导致预期修改正确比较困难。

搜索了一下 login 这个功能点，该页面的正确性关联7个文件。

• 随便搜索了一下本项目有关 login 的功能点，该页面的正确性关联7个文件。
• 场景：
  • 登陆页面功能需要修改：密码错误失败提交次数超过三次，需要显示验证码，并且需要用户输入验证码，验证码输入正确才可以继续登陆。一定程度上避免密码被暴力破解 及dos问题。（对付比较菜的黑客还是管用的。。。）
• 问题：
  • 需要找到/看懂 login 功能点关联的7个文件。这些文件在本项目的路径如下：

    app/src/main/java/com/kunminx/puremusic/ui/page/LoginFragment.java:44
    app/src/main/java/com/kunminx/puremusic/data/repository/DataRepository.java:132
    app/src/main/java/com/kunminx/puremusic/data/api/AccountService.java:15
    app/src/main/java/com/kunminx/puremusic/domain/event/Messages.java:11
    app/src/main/res/layout/fragment_login.xml
    app/src/main/java/com/kunminx/puremusic/domain/request/AccountRequester.java:96
    app/src/main/res/values/strings.xml:38

    这些在不同路径的不同文件的位置，找到它们已经很费脑力了。看懂之间的交互关系 和 预期我的修改是正确（比如没有漏掉一个地方忘记改） 更加困难。

• 实际项目需求变更的时候，往往类似前面的场景，有很多情况下 是某个功能 从api接口到 ui 样式 到 ui交互逻辑 全部都在改。
• 建议解决方案：
  • 使用android Jetpack Compose 开发ui和ui逻辑，login功能点单独开一个类，所有ui/ui逻辑/调用api 代码放在这个类 里面。不同语言 翻译/api 可以考虑 隔开，使用工具（比如grpc）自动生成后直接调用即可。这样最多关注3个文件（ui/翻译/api接口）即可阅读/修改 login功能点。

[KunMinX]

kotlin 是笔者最喜欢的语言之一，“函数第一公民” 的设定引发了蝴蝶效应，颠覆了传统开发格局。

不过本项目旨在引导 java 开发者，在功能实现之初注意和规避不可预期问题，以减少后续维护成本。 关于 string 等资源的分布，是 android 传统开发方式的设计。 受限于 java 语言本身限制，尽管项目中做过多方变通，相比 kotlin 的高信息密度，还是容易注意力滑坡。

如一开始便使用 kotlin + compose，建议参考官方案例。