项目代码杂谈
项目现况
半路加入团队，在旧项目上进行升级改造。net core 版本的 wpf 上位机项目。界面部分：window 2 个。usercontrol 大概14个，分了2个界面库（A与B，其中B是A的重点业务） + 1个界面帮助类库。
业务处理流程：xxxViewModel -> xxService -> xxRepository -> xxx实际处理。
配置数据存取流程：xx实际处理中注入数据处理接口 IDataContext。然后搞个实现类进行 xml 文件读写。
个人想法
业务流程中 "ViewModel -> Service -> Repository -> 实际处理" 这一条线我只保留头尾。实际项目中的 Service 与 Repository 层只是简单的传递数据，并没有做额外的业务处理或者数据转换。
这种仿 DDD 的写法在以前搞 web 的时候经常看到，cs 端我还是第一次看见。
"配置数据存取" 这一条线换了我只会直接在 xx实际处理中直接读写 xml 文件。配置数据要么存入本地文件xml或json，要么存入数据库。如果存入数据库，那么现有的 IDataContext 完全不能用；如果换成 json，那么 Json.NET 也能够很好的处理。
界面类库我觉得应该三合一，2个界面 + 14个用户空间放一个类库中并不多。现在类库B中还要定义事件，触发后再传递给类库A。帮助类库就创建 Converter，Helper 文件夹存放Helper类即可。
好的项目代码应该是可读性，封装性，可变性三者找到一个平衡点。
可读性是第一位。项目除非生命周期完结，不然日常的bug排查，新需求都离不开跟代码打交道。
封装性是第二位。合适的封装可以提升可读性，而且方便单元测试。无意义的封装就是简单问题复杂化，有问题解决问题，没有问题创造问题再解决。
可变性最后考虑。未来的需求谁也说不准。
