写范例的，自己的基础知识也要抓住一点。

[weixincloud]

写范例的，自己的基础知识也要抓住一点。

[Cubelrti]

您好，

首先感谢您的反馈，本示例代码部分的确存在一些可以精简的写法，在代码规范方面，我们会持续改进。但本项目仅作为最基础的部署示例，演示简单的计数器功能，大部分使用场景不会沿用本仓库的代码进行二次开发，所以对于一些 Java 语法不会全部使用最精简的写法。

Dockerfile 的 mirror 部分，在实际一键部署过程中，已经预打包为镜像，不会影响部署速度。但后续二次开发时确实会产生影响和误解，我们已经调整了 Dockerfile 的部分，十分感谢反馈。

遇到工单问题没有及时回复非常抱歉，可以尝试重开一个工单，我们会有专人回复。或者可以留下一个联系方式，我这边加下您。

镜像服务问题，控制台最近新增了拉取公开镜像地址部署的能力，如有需要可以使用。

最后再次感谢反馈，十分抱歉给您带来使用上的不便，我们会在将来继续优化产品体验和相关能力。

[chinafzy]

您好，

首先感谢您的反馈，本示例代码部分的确存在一些可以精简的写法，在代码规范方面，我们会持续改进。但本项目仅作为最基础的部署示例，演示简单的计数器功能，大部分使用场景不会沿用本仓库的代码进行二次开发，所以对于一些 Java 语法不会全部使用最精简的写法。

Dockerfile 的 mirror 部分，在实际一键部署过程中，已经预打包为镜像，不会影响部署速度。但后续二次开发时确实会产生影响和误解，我们已经调整了 Dockerfile 的部分，十分感谢反馈。

遇到工单问题没有及时回复非常抱歉，可以尝试重开一个工单，我们会有专人回复。或者可以留下一个联系方式，我这边加下您。

镜像服务问题，控制台最近新增了拉取公开镜像地址部署的能力，如有需要可以使用。

最后再次感谢反馈，十分抱歉给您带来使用上的不便，我们会在将来继续优化产品体验和相关能力。

从你的答复看，充满了“得过且过”的培训学校**。这样我就更加明白，为什么代码和产品是这个水平。

我们首先同步一个共识：demo是不是应该简练简单，让别人更容易跟进？
或者，贵组的做事习惯是：把简单事情复杂化，好浑水摸鱼，方便糊弄客户和领导？

既然你要用了，就要用好，至少要把基础的东西用好。这个没问题吧？
我之前说的问题，有哪一个是稍微有点技术难度的，或者增加复杂度？如果是，那就是我把入门demo讨论难度化、复杂化。你指出来，我道歉。
用spring data会让这个demo简练清晰很多。但是我之前没提，因为你们用了ibatis。我所有的讨论，都是基于当前demo使用的技术和工具。

既然用了lombok，那根据它的基础用法，代码就可以更省事。不那么做，我想无非俩个情况：一个是半懂不懂，lombok的最常用最基础的东西都不会；一个是懂，但是就喜欢多写无意义的代码。
请问是哪一种？或者你还有别的分支理由？借口？

Dockerfile的问题，既然你们已经认错了，为什么还要补一句话【不会影响部署速度】？
这个话有什么意义？？？部署速度跟build速度有关系吗？
你们是不是太习惯于找说辞，喜欢东拉西扯，把水搅浑，好逃避责任？

镜像的问题，你们的答复根本不能解决，因为走公共镜像，那就是public的。商业化的部署，会有代码（可反编译）和账号+秘钥，然后public了，你这个不是开玩笑？
我真的不知道怎么评价这个解决方案，因为太容易触发敏感词。

为什么人不能正面自己的不足、失误、错误，然后改正，而是不断的找说辞？
你们憋俩周，就整出来这么点借口，然后马上把帖子封闭了。这个就是做开源和商业产品的心态？
鸵鸟般的逃避有意义么？即使你关闭了这个帖子，还有这个项目；关闭了这个项目，还有关联项目；你总不能把全部的腾讯开源项目都关闭吧？