@abcbuzhiming 功能边界肯定要划分清楚的呀。

我在带团队的过程中一直强调，把代码写对地方比写对代码更重要。代码写错了很快就能发现并修复问题，写错了地方则不然，当时是没问题你好我好大家好，但会让你在后面一直吃屎。。。同时也会在合并分支时产生大量的冲突。

事实上只要在写代码之前稍微思考一下再动手，就很容易解决功能边界的问题，也就能把代码写对地方了。

直接仲裁就是了，稳赢。

无脑选 2 就行。第一种非常容易写着写着就不清不楚地黏糊在一起了

@Acoolda 所以学的时候要多想想怎么用呀，想明白了就学到了，想不明白就是白学，浪费时间。

结果等效，但执行计划不一定相同

我们的文档就基本上是 MD，和代码在一个仓库，这样比较方便。不是 MD 的除了流程图外，都是不会更新的。流程图也是个 xml 文件，所以一点也不影响。

现在买电车，要有两个前提条件：一、有车位；二、车位能装充电桩。

电车平常开开还是很好的，但我这种没车位的就只能望洋兴叹了。

学以致用，效率才会高。学了没用，等于白学。

一、学的时候想明白怎么用，并且去用；二、遇到问题了，想明白学什么能解决问题。

做到这两点，就能学以致用。

目前用 Linux 桌面的都是瞎折腾。。。。。。不接受反驳

互联网已经是最容易上升的行业了……如果做互联网都不能脱颖而出，做教师、医生、公务员的话，也就是底层混一辈子的料。

第一个简单，开销也低，因为只管 insert 就行。第二种就要先读出来，然后拼接，然后 update 。不说数据库操作 select +update(delete+insert)比 insert 开销大得多，业务逻辑也复杂了很多。省那么点存储空间，脑子瓦特了……

数据库要支持 1 万并发写还是很费钱的……别的都是小 case

已入官网丐版 SE2，24 期免息真香警告。

6S 真是太卡了，11 太重，又太大，还有点贵，有这 3 个缺点我还你继续忍。现在 SE2 出来，不能忍了。

楼主这种情况我们开发过程中也遇到很多，这其实是一个代码规范的问题，如果像我们这种代码都是套同一个模板的话。复制粘贴改一改就是一个新服务了呀……

服务拆细本身没有问题，只要服务能够独立，不过度依赖其他服务就行。数据库我的建议是按领域拆分，不一定要一个服务一个库，可以多个相同领域的服务使用同一个库。

为什么同一个领域还要拆分服务，我的经验是为了平衡稳定性和灵活性。基本上是领域服务和管理服务拆开，领域服务负责稳定，发布后基本不动，管理服务负责灵活，可以随时迭代。而且这两个服务本来就是同一个业务，用的是相同的数据，你数据库怎么能不一样呢。

搞微服务不能教条主义，要按业务的实际需求来。

距离远为啥不搬家，我相信你搬过去房租也不会比现在多多少。搬到公司附近，上下班 10 分钟的距离，每天你的生命就多了 4 小时，还有比这更划算的买卖吗？时间是一个人最宝贵的资源，没了就再也找不回来了。

楼主可以打开活动监视器，看一下哪些东西在消耗电力，能耗大户能关掉的关掉几个就好了。