我觉得从测试的角度写代码也有助于代码逻辑结构的模块化划分。每次写之前想想写完了这段代码能不能测试。

在维护前同事写的代码的时候，之前总是在其方法内部做增量，吃了几次亏后，果断写个方法把需要的业务处理好，然后勾到需要的地方，不光调试贼爽，还很清晰。老师讲的比较宏大，不知道我这个算不算😂

如此众多的类，它们之间的关系就相对复杂了，请问这如何管理呢？

原来大厂也会写“烂”代码，心里平衡了一些😄

职责单一原则其实挺难定义，有些资源文件虽然很大，但是其职责是单一的，这个文件就是维护一个映射。我个人认为，一个类与其包含的所有方法和属性，如果只有包含关系，可认为单一职责，例如用户和用户的名字。如果用户名字还有其他用途，例如和密码一道提供认证功能而用户类中还有其他属性和认证无关，就不再是单一职责，可以让用户名和密码单独成类。