docker 装呗，不折腾，开箱即用

如果一个对象在自己的整个生命周期可以不对自身状态做任何限制，那写 getter 、setter 确实没啥意义，全部的属性设置成 public 也没啥问题。但稍微大一点的程序里面的对象或多或少都得对属性的访问域作出限制，setter 和 getter 是其中限制访问的一种方法之一。简单讲就是为了封装。
举个简单的例子，有一个日历对象保存了一个 List<Schedule>，它对外暴露的方法可能就是一个`publlic void addSchedule(String date,ScheduleType type,String description)`，一个`public List<Schedule> getSchedule()`，而且 getter 返回的这个 List<Schedule>还是一个不可变对象——你不能不通过日历对象就去更改代办事项列表，这样可能会跳过很多校验，比方说同一个时间点不能有两个代办事项。
而且日历对象不能每次都让客户端程序直接生成一个 Schedule 插入到 List 中，Schedule 可能还需要保存用户的信息，日历对象可以通过添加依赖资源来在 add 方法中解决这个问题，而不是需要客户端程序每次重复输入一遍用户的信息。客户端只需要提供时间、类型和描述。
getter 和 setter 有它存在的意义，但和其他很多好东西一样，一旦滥用就令人生厌。最后，如果你真不喜欢 getter 和 setter ，而又得在 Java 生态里干活，那我推荐学习一下 kotlin ，它在语法层面支持自动的 getter 和 setter 。

主要问题是人闲活儿少，要是天天一堆活，不用现成解决方案这样折腾早累死了

精通太哈人了

构造器注入啊，写测试多舒服

业务本身就没逻辑可言，代码也就只能 if-else 。如果业务迭代得快的话，代码写出来的时候指不定就已经过时了。

可以用 OpenGL...不过还是找现成的解决方案比较好，自己造轮子是下下选

@TWorldIsNButThis 果然自己还是不够熟悉啊...

@clf 好奇问一下，是因为要拆包？

开发类软件的安装感觉在哪个系统上都很麻烦啊

主要还是方便确定问题所处领域吧，看到报错时不至于两眼摸黑

不说本身下载工具就满天飞，you-get 之类得，在说看番随便找个站不比 B 站好，图个啥

还是 Choco 用得多一点，winget 没法直接设代理

大部分信息感觉是我油管观看记录里整理出来的

学习 Shell ，把工作环境从 windows 切换到 Ubuntu 。写了一堆有得没得脚本玩。
然后就没干啥事了。

IDEA 的 Code With Me 似乎满足一部分需求，而且这个是可以自架服务得。

公司系统的一些状态码是我折腾得，隔离用得 2020 ，分离用得 1991 ，这也算彩蛋了吧。

自用 loki ，感觉还可以