近来在改造一个同事的数据入库项目，发现了一些问题，其中就因为数据库联合主键的缘故导入新增的数据不能入库(这个新增的入库数据，其实对应的数据表就存在这样的数据，她那边没有针对此进行判断有则更新，仅仅是无则插入)。
基于这个问题，我不想写太多的代码(查这条数据是否存在，存在则更新这样的)，只想用最少的代码量解决这个问题，通过搜索我找到了这样的方法，无需写很多代码，就是一条SQL就能搞定。

这套分布式微服务体系建设到现在，已经有半年以上了。前段时间因为技术顾问和项目经理的一些提问，我有些质疑我的设计是不是合理的。

写好对外API和对内API本质上是一样的，都需要考虑这几个方面？

• API文档；
• API安全性；
• API日志；
• API性能。

常量，可以理解为一种特殊的变量，通常用static final来修饰，它的值一旦设定，在程序运行过程中不允许改变。
常量在实际开发中使用非常多，这里以我博客为例，我的博客系统主要以WordPress作为模仿对象，我的常量类如下：

最近在做数据库设计的时候(以MySQL为主)，遇到不少困惑，因为之前做数据库表设计，基本上主键都是使用自增的形式，最近因为这种做法，被领导指出存在一些不足，于是我想搞明白哪里不足。

for循环内外创建对象的区别，哪个性能更优？

最近因为如下几个问题，有些疑惑，于是展开研究。

• 变量尽量不要使用包装类型，强烈建议使用基本数据类型，是出于哪些考虑？
• ORM映射的实体类为何建议使用包装数据类型，是出于哪些考虑？

有人说，代码即注释，也就是通过你的代码就能看得懂你的代码逻辑是什么。但是对于大多数人来说，这有些不切实际，每个公司的研发团队成员的能力是不一样的，有的能力强，有的能力弱，能力强的体现在能解决若干问题，但是在编码规范方面却有待提高，能力弱的，有的能力弱的在代码规范方面却比所谓的能力强的要好得多，这里的”能力强”并不是指两个人的聪明才智差异很大，而是指特定领域的积累，有的积累得多，经验丰富，有的积累的少，经验不那么丰富。但因为是一个团队，就必须要有一定的约束，不仅仅是对能力强的，能力差也一样，一视同仁，团队不能搞单兵作战，那样就失去了团队的意义。

应该说是最近，因为代码格式的问题被同事指出，虽然说我主观上不是很乐意接受，但是以后如果我要带徒弟的话，首先自己要做到不好的地方，有则改之，否则怎能服人。

代码格式问题主要体现是代码空行太多，一个类的代码行一千多行，其中不必要的空行就多了三四百行。

一、当前年的上一年