odirus

刚好做过类似的事情，我们通过 Checkstyle 来实现格式检查，但如果格式不正确怎么快速格式化呢？因为我们这边基本用的 IDEA 社区版，经过调研最终我用的 editorconfig 配置文件来实现，下面细说：
1 ）将统一的 IDEA 风格导出到 editorconfig 配置里面去（不要怀疑，可以这样玩的，是以 "ij_java" 开头的配置）；
2 ）然后想办法写入到大家的项目目录下，当打开项目时 IDEA 会优先使用当前项目 editorconfig 里面的配置，IDEA 下面也会提示 "one or more code style options are overriden by By EditorConfig"，这样就生效了；
3 ）那怎么让这个配置文件写入到大家的项目目录下呢，我们开发了一个 IDEA 插件，只要大家安装了，启动项目时一旦检测到公司的项目就自动写入配置文件或者更新配置文件；
综上，需要用到两款插件（ Checkstyle + 自研）、editorconfig 就可以实现了，如果喜欢折腾的话就在自研插件里面集成 Checkstyle 代码，代码是开源的。

@odirus

很多时候很多事情不是自己能够决定的，那就尽量让这件事情朝着自己利益最大化的方向发展，以前我也不愿意填，但养成这个习惯之后每天都会沉淀内容，整理知识体系，避免碎片化。

我就发现有些同学一件事情讲不清楚，写的东西别人也看不懂，必须当面沟通（ Battle ）才行，但以后如果去了一家远程办公的公司，那就完蛋了，所以逐步培养自己吧。

我们也要填，但我觉得填的意义还是蛮大的，确保任务要能够追溯：
1 ）开发前记录这个任务的需求来源以及会议结论（撕 B 结论）；
2 ）开发中记录遇到的一些重难点、可能的潜在隐患等，同时将 git commit message 与 issue id 关联起来，方便 Review 的时候让对方了解背景和想法；
3 ）开发完成后可以沉淀一些心得体会，可以用于后期的分享和自己的笔记沉淀；
我们是在记录工时的同时顺便记录上述信息（用的 Redmine ），可以让自己或者组长了解为此付出的精力以及这中间的过程，以后再追溯这个问题的时候可以了解当时的一些决策过程（需求上或者技术上）。

感谢各位，这个帖子可以关闭了，是我自己填了路由器规则后没点击保存，所以没生效。。。抱歉，我的疏忽

@Lunatic1 我这边只映射 3389 就是不行，不知道是不是网络本身的问题

要不每个微服务打包成两种？一种是 jar 、一种是 war，需要合并的话就把多个 war 包丢到一个 Tomcat 里面