吃瓜路过，我自己虽然不用小米，但我给不少人推荐过小米。
整个帖子看下来还有有点用的，看来小米电视 性价比低 确实是没跑了。


至于炒热这个“挂着小米牌子但性价比低” 事的人，是路人还是海军或者其他友商 都是好事。

品牌之间互相攻击，只要不是无中生有，坑蒙拐骗的假消息对消费者来说都是好消息，我们可以有更大的知情权和自主选择权。

看来这个所谓分享学习就是个应付领导的表面工程啊...

我还以为真的是老大组织大家互相学习，提高自己的编码水平呢。

我们之前分享，是技术领导推的，没有跟上层的要求。
所以我那时候个人倾向于讲低端但我们项目却根本没有使用到的技术。

最一开始的
git 的使用 ，几种 3 种人们推荐的 git flow。
到
测试覆盖流程的简单实践，Log 输出格式和如何打印有价值的 log。
微服务和传统单机 /负载均衡集群 各自的优缺点， 微服务的基本实现。
docker 的优点和使用。


-----
然而即便如此低端最后出了基础几个，剩下的依旧只是让别人知道有这么一回事而已，并没有人听完分享能有多少收获。

再之后，项目黄了...
我们技术领导离职了....

你就是机器不换只换卡呗？
那大概率应该是可以的，一般存档不至于专门分区吧。
网上能搜到 问日版欧版不同卡带存档通用不通用的问题，有人测试是可以的，那国行的也大概率可以吧。

说个与主体内容无关的。

markdown，默认一个换行就是不显示换行的。
行尾加俩空格 才是显示出来的换行，相当于<br>
两个换行，也就是空一行，代表段落分隔， 相当于<p>

https://wx4.sinaimg.cn/large/960b5f2cly1gac684lgvcj206y05n752.jpg

人还是无法百分百站在别人的立场的...

换个角度想，楼主你其实只要家具没坏，可以坚持到回本嘛， 像北京除了少部分城中村，没空调的房租会比有空调的便宜至少 200，按个空调一年就赚回来了。
我目前租的好些房子 冰箱空调白壳子都严重泛黄了，我也不介意，能用就行嘛...费电一点也没办法

@jzq526 #11 来看， 你理解成 classpath 不能用了。

但实际上只是 不需要通过指定 classpath 才能使用*java 标准类库*而已， 如果还有其他第三方类库，依然可以使用 classpath 环境变量指定位置。

并且我试了一下，发现 classpath 还是如当初一样蠢，如果你要用 ClASSPATH 环境变量添加其他第三方类库，记得先把当前目录(.)加进去，否则和当年一样，java 命令并不会加载${PWD}的文件

Java 工具框架用多了， 我也向楼上一样 以为预编译的 sql 就能防御 mysql 的通配符。

不过 Mybatis 确实提供了 通配符的处理， 采用#{} 传的值已经被处理了，只有${} 才会出问题。

“classpath 只是简化” -> “配置 classpath 环境变量 只是简化”

在早期版本中，java 命令就是 java 命令，classpath 默认就是.，运行的时候不加载任何其他地方的类库，包括 java 本身的系统类库。
除非你的项目除了基本类型啥 Java 类库都没用到，否则每次执行命令都需要告诉 java 命令去哪里加载 java 本身的 dt.jar ，classpath 只是简化每次传值的一种方式，所以 classpath 是必须的。


而大概是 1.5 开始，java 终于开窍了，发现好像没有人写代码会不用 Java 的标准类库，所以在那之后，java 命令执行时会自动加载${JAVA_HOME}下的 Java 系统级 lib 了。

应该说现在就一趟列车在运行，现在根本就没车可抢，更不用说票的问题。

北漂的内蒙古中西部人士毫无波澜，反正也没车票可抢。

@hakono 你的理解是你个人的理解，不是程序员的理解，不是程序员都会觉得 3.11 和 3.1 有关联的。

3 段式版本号算是最常见最普遍的一种命名方式了，多接触几种语言或者几个项目都不会有你这总想法。

linux 4.1.x 和 4.19.x
nginx 1.1.x 和 1.16.x
docker 1.1.x 和 docker 1.17.x

@darmau 我很羡慕别人可以要到高工资的，既然吹破了， 那就换下一家，薪资要求按照这家能谈妥的这个水平要，上家公司薪资待遇照实说。

只要不是之前工资吹逼吹过了，有什么怕他知道的么，随他查去呗。

@U87
@Vegetable

我忘了是从数据库自动生成 dao 叫反向了，还是从 dao 到数据库是反向，反正一个当时叫正向一个叫反向。反正是 Struts hibernate 火爆的时候流行的一个说法。主要是说设计阶段是设计数据库还是设计 JavaBean，两种之间哪个是设计创建出来的哪个是根据另一个通过代码自动生成的。

对于外键影响性能这点我一直持保留态度，如今的传统互联网项目的结构性数据都不一定有 20 年前的银行这类传统大型企业数据量大。
而当年那些企业哪个不用外键？ 如果性能影响真的大，当年计算性能比现在低那么多肯定早就有公司和产品将不用外键推广出来了。


外键对于如今而言最大的缺点其实是灵活性，曾经许多方法和算法为了高性能都用存储过程写到了数据库里，而这些年在互联网企业的示范下我们将这些都挪到了后端代码里，并且从前几年就开始流行将代码再向前挪——GraphQL，因为性能其实没那么吃紧了， 大不了找方法做横向扩展加机器嘛。
而这个时候对于业务层而言，后面那些层就仅仅是提供数据的，只要准确快速即可，业务层自己是就是全功能的，自己来给用户做约束，而不希望后面那些层再额外限制约束业务层影响业务层的功能。
在这种思考方式下，如果他是后端代码实现逻辑的，那么它就不希望数据库来存在存储过程，外键，等在后端代码控制范围外的约束来干扰它。
如果是 GraphQL 的那则是希望连后端代码都别做太多约束限制影响它的查询。

@gz911122
不知道是不是只有 JAVA 的 ORM 有这个说法。
逆向工程指的就是 在没有库表的情况下，通过代码可以生成项目的库表。