兄弟你醒醒，除非你在地面干活（当然地面干活也很苦），你要是下井当掘进工那是苦上加苦，那可不是说 8 小时工作制，是夜班和白班两班倒的。如果你是掘进工是有尘肺风险的，如果你是修巷道的其实还好，但是跟掘进工差不多一样累。你爸肯定不是煤矿的，我爸是煤矿的，他之前就说干啥都别来煤矿。。。。。

设计先行，设计必须从长远的目光来看。如果有些业务属性加入注定会对代码造成质量影响的建议 battle 一下，尽量保证代码的优雅。有些业务加进来后，新的设计会对老的设计进行优化，这个时候要记得进行老模块的重构，这样才会保证代码的整洁优雅。如果团队的其他开发进行代码提交的时候一定要 review ，不注意的话 shit 会越加越多

@cmdOptionKana #140 对啊，我的意思就是在外面算命的都是假的，当然通过算命来听好听的话获取情绪价值这种行为我是不做评价的，因为每个人都有自己的自由。我只是说，来算命的人一般都是渴望得到，或者害怕失去的两类人，这些人在某些方面很极端，如果真的要通过算命来获取未来的情报，那就是纯纯的痴人说梦，因为当你觉得未来可以改变的时候，你又知道了未来的情报，那未来会因为你的提前布局和规划又改变了。所以还不如去干自己想干的就完事儿了，想那么多都没啥用：）

@cmdOptionKana #135 一点都不无力，既然命是不容易改的，那就没有必要算了，因为你算了也改变不了，还能徒增烦恼何必呢？算命最大的弱点就是觉得知道之后的事情走向就能够先一步进行布局和处理，殊不知如果命是不容易改的，你怎么折腾都没用，算命的自己就把自己搞失业了。

算命的如果真的能算命，他就不会在那里算命了，早就闷声发大财了，还用得着给别人算命

@shm7 #57 嗯，应该是没有钢板，毕竟很轻

我的宁芝的静电容键盘就被我家猫把案件给踩失灵了:)，键盘不坏的，家里养猫的让他踩踩键盘就完事儿了，也不需要多重的猫，六斤的就够了:)，我现在看着家里的坏键盘就想把猫炖了:)

处事不求无难，事无难则骄奢必起；谋事不求易成，事易成则志存轻慢。

在 service 里面，第一是可以复用，并且一旦需要把查询出来的数据做一些逻辑处理的话可以直接在 service 的那个方法里面做，第二 controller 层按道理是不应该有任何业务逻辑的，这样能在 controller 层保持干净，如果项目规模不大你在 controller 层直接注入 mapper 看似没什么，但是一旦代码规模起来会变得很丑陋，你在 controller 的代码会变的越来越长，最后 service 层形同虚设，又要重构。

我们组是如果不写接口文档的话，前端直接就开操了，所以所有人对接的时候，先出文档，再说对接的事情，而且请求参数和返回参数分有必须参数和非必须参数两种，反正开发之前，先写文档都得一天多。。。。。（然后如果接口改了，还得同步去改文档）

那个架构师真的不尊重人，不就是看不起楼主是大专么，还喜欢装大的

@alexapollo 确实，p 社游戏全靠 dlc 赚钱，尤其是新 dlc 是需要卖很久才开始促销的

维多利亚 3 ，p 社的游戏我都推荐

我看了一下，其实很多泛型都是顶层抽象类的，我不理解的地方在于，为什么顶层的抽象类要写这么多的泛型，如果是需要在抽象类中定义抽象方法的返回参数就用 extends 的那些类型就好了，反正你的参数一定是这些类型或者这些类型的子类

一楼说的没错，还有搜狗和阿里都有类似的数字人，就是把一段文字发过去，然后他们生成视频或者就直接数字人说出来，我们之前做的就是先从机器人搞到回复，然后再给数字人生成

而且如果 test 分支就算被占住了，你从 test 再拉一个分支不就行了，你们新开发的代码最后合到新拉的分支，然后那个 test 的功能 ok 了，直接把这个分支合到 test 就可以了，这样也不会阻塞，git 可以灵活的来搞啊

@my1103 我知道啊，prod 是生产在跑的代码么，pre 是验证分支代码，你这个功能已经开始测试介入了，说明开发自测是 ok 的，那说明如果 ok 的话，如果测试没问题，下次上线是会上掉的，那就在 pre 验证啊，如果有问题，pre 分支开修复分支修复啊，这样也不会阻塞你们的 test 分支