把 new 改成 spring 注入不就可以用 conditional 的方式了吗，你提供默认的，使用方也可以自定义

Keycloak ，自己做感觉很难超越这个，不过由于这个国内社区内容不多，和国内的很多东西适配不是很好，可以做一些相关的插件，定制下主题啥的感觉也不错

可以试试导入时把要导入的数据缓存起来，手动新增的时候查一下，但是如果真是 0 容忍的话还得加锁或者数据库设置唯一约束

“主流”（也许仅是我眼里的）方式就是环境变量 /挂载配置文件 /配置中心，
单体应用一般环境变量或者配置文件就行了，根据需要镜像使用者自定义的配置项数目来决定。
分布式项目一般都会有配置中心，或者使用 k8s 的 configmap 挂载。
但是无论哪一种，都应该以部署脚本的方式交接，脚本放在代码仓库中，应避免人手动去操作修改参数，同时方便做自动化

能进新项目肯定要进的。
我刚毕业的时候进公司是只会 java 基础，甚至 java web 都不会，我记得组长给的第一个任务根据 app 下载地址返回二维码，就靠百度完成了，后面让我写其他的接口，那也都是从项目别的地方抄，遇到不懂的就看看 spring on action 查下相关内容的大概原理，几个月后基本就没啥问题了。
新人不要害怕提问，也不要觉得自己不会的低级问题问别人会显得很蠢，其实别人在回答你的时候他也会获得一定成就感。
当然提问也是门技巧，这种东西就自己把握了。
啥都不会不可怕，可怕的是一年之后还是啥都不会

我是通过别人的代码去体会到的设计模式的好处，第一次惊为天人，然后自然就想着怎么往自己的代码里套
说实话，如果你觉得这段代码用上设计模式是生搬硬套，那说明这段代码逻辑很简单，不需要设计模式，强行使用反而增加复杂度

今天刚下了一个正在试用
https://github.com/liaoliao666/v2ex

想深入学习前端的话 React Native ，不然 uniapp 快速出产品，赚钱了再招人换呗

服务部署是有另外的服务器吗，不然 16g 干脆直接拿来部署服务给前端调试算了，或者装一些开发用的服务，比如日志工具，还有禅道或者 jira 等

CDN 不是有用量封顶配置吗，不懂为啥会卖房子

@november 哈哈，刚想说提供信息的时候贴一下要经过几次转换

楼上说的非常好了，针对`让 OO 回到他本来的面目`做一点具体化的补充，`多个实现类都要抽一套 domain 出来`，除了继承实现还有包含成员变量的形式，这个完全看实际的业务定义，木工和钳工都会用锤子敲，这是因为他们都是工人呢，还是因为他们工具里都有锤子呢

从第一点描述看，这也不是效率高低的问题呀，效率和工作量并没有什么关系吧，也许你是觉得平时没项目交付的时候属于开发空白期不知道该怎么组织大家的工作？

如果真的比较空，领导又支持搞研发氛围的话，可以让组员们选一些前沿的东西进行研究，之后开分享会将各自研究的成果做个分享，文档归档，这对公司来说也是技术积累。前期大家可能不知道怎么下手，你可以跟他们沟通讨论给他们几个选题，后面就可以让他们自己找了。不过前期对你来说可能需要花费较大的时间和精力。

codereview ，`组内有刚毕业的小朋友比较热情老是提建议`，这种情况他可能是工作感觉不到提升，如果真的工作就是很简单也不需要大家有很深的技术那就没啥办法了

`行业性质的原因，基本上一人一项目除非有相关项目经验，否则几乎参与不进来`，这个其实应该就是没有深度工程化的问题，看看这几年的前端的发展就知道了，举个不太恰当的例子，就好比螺丝刀，有那种一把把卖的，也有头部可更换的那种，个东西如果不是对行业有深度了解或者行业里有成熟方案参考的话确实会没什么方向，但是也确实是大有作为的东西

中台能带来看的见的好处：
1. 引用 6 楼 `某个大佬觉得相似的业务功能为什么要两个团队单独维护`,同样功能的代码只写一次并由同一个团队维护
2. 针对公司的编码规范可以出台对应的编码方案，以 spring 为例，rest 接口的请求参数、返回对象和异常码返回等可以通过提供 starter 的方式统一起来，当公司内部人员发生调动时，能快速适应代码
中台的困难：
1. 很多功能可能广泛存在于不同系统，例如用户管理等，但具体到每个不同系统中他们可能又有些许差异，而中台在编码时不可能完全考虑到所有情况，而业务侧一旦产生需求，可能没有时间等待中台去做升级
2. 中台对于企业有个很严重的问题就是产出很难量化，即使你做了很多工作但是没办法表示你的产出，做的再好业务端没有产出也没用，当业务端有产出时也很难量化中台在其中的作用，因此对于大多数公司而言中台是一个纯投入型的项目
针对困难 1 ，比较好的方式是，中台在提供功能时同时提供扩展性，例如使用 SPI 或 spring factory 这种机制，业务侧在对现有功能提出需求时，优先向中台发起请求，中台评估该新功能或增强是否应该由中台完成，以及给出相应时间计划，时间不允许的情况下，业务侧再自行完成需求，后续看情况将代码合进中台。
显然这种方式也会带来困难 2 ，业务侧觉得，功能都是我提交上去的，我做了中台的事，要你中台干嘛，在特别极端的情况下甚至会出现由于某个项目的领域特别新，使用的技术要求较高，一段时间内长期向中台提供内容而并未从中台获利，从公司整体而言这部分功能只要有其他业务也在使用当然是赚的，但对于这个项目组而言就不一样了。
中台的管理问题更大于技术问题。

1. logback 有 DBAppender
2. 如果需要自定义日志内容请参考[美团的这篇文章]( https://tech.meituan.com/2021/09/16/operational-logbook.html)
3. 如果有条件建议上 loki ，有 docker-plugin ，集成方便。

聊天的话无所谓，一般不会聊天打字还校验几遍，正式文档那又是另一回事了，出现错字是 0 容忍的

文件本身应该是都会读取的吧，重复的按优先级取值？我是这么理解的，另外好像有个 bootstrap 是预先读取，在 application 之前

LG 27UL650-W +1