开始以为是打算收点认证税
一看列表，这特么是打算强卖自家硬盘呗

x200s 不是强调自己“果”味儿十足吗？你都用果子了还换个啥劲儿？

这玩意不就是 git bash here 吗？
具体实现还是有点繁琐，要你在大模型上问一下这个 “如何实现类似 git bash here 的功能”
大概流程就是你要写个 bat 脚本来进行判断分析，路径可以在脚本中获取到，然后把这个脚本通过注册表注册到右键菜单

小文件还能碰碰运气，10G……

@0576architect #13 我是基于 "IntelliJ IDEA Classic" 这个自定义的，"macOS" 和 "macOS System Shortcuts" 跟习惯差异太大
但即使 "IntelliJ IDEA Classic" 这个，跟 windows 的快捷键差异也是非常大的，用它只是好多年前长时间用了一阵子 mbp ，从这个改改能够找到点过去习惯的手感

将就着用吧
个人目前用到逻辑性最强的快捷键是 IDEA 系列，以 ctrl 为底，功能稍微不同就加 alt ，对全部执行就加 shift ，很多时候快捷键能猜得出来
但就是这么明显的一套东西，到了 MacOS 上，默认的还是抓瞎，改回经典快捷键才能勉强用用

深色模式是给苹果手机用的
因为电池小

我觉得吧，找个快递盒子盖上应该不影响信号强度吧

机器挺好，游戏劝退
特么的一个马车将近六百！六百啊！！
我还是滚去玩 steam 吧

python
这个活肯定是 java 合适
但是
1. 你 java 不太熟
2. 有人会，这个会基本可以默认不会
会 java 语法跟会用 spring 生态完全是两码事，甚至可以认为是两种语言都不为过
所以，用 java 你们一定搞不定，用 python ，别管适合不适合，至少还有继续进行下去的可能性

是的，没错，不用学了

这样我的工作机会会多一点

标准的 TDD ，没毛病！

没看，仅凭你描述
同名文件的相同行数没啥毛病啊，这能匹配上的几率得有特么多低啊

北半球，16 发布到现在还没经历过完整的夏天，要不你问问南半球的

@shawyeok #19 UML 不是拘泥于形式的条条框框诶

这个的价值是定义了一套规范，大家都遵守的情况下减少沟通成本

如同设计模式，并不是死规定了一套方法来处理问题，而是将大家处理这类问题的最佳实践总结出来给一个特定的名称来代表，这样以后一说名字就知道如何处理

再举个前端例子，prettier 第一句话就是：这是个 opinionated 的格式化工具，大家都认可这种特定词的情况下，仅凭这个 opinionated 就可以决定是否继续使用，后面配置文档看不看都无所谓的，基调已经定下来了

再比如 spring boot 框架，convention over configuration ，这就是它的开发准则，在这个基础上非得按自己意愿乱改配置就是瞎搞

UML 的图并不仅仅是一个图形，它代表了一个词法单元，等同于语言中关键字一样的东西，如果随便乱画，那别人看的时候就得去猜想你在这个图中用这个图例表示什么意思，因为很大几率下一个你所画的图，同样图例表示不同意思，或者用另一个图来表达这个意思，随意性太高大家就没法沟通了
这是没有做过开发的项目经理的做法，不是开发人员应有的素养

真照片万一被告得不偿失
也生成呗，规避一下容易一眼假的部位
你看那种网站上生成的不是挺逼真的嘛

你这玩意直接张大妈写假评测帖子就行了啊，那边所有（所有！）帖子都是这种
小红书不了解，没用过

一图胜千言，有时候业务复杂度上来之后，文档并不能做到像图片一样，一眼扫过去就明白个大概
而且，状态图对于比文字更能表达清晰逻辑，可以帮助规避不容易发现的 bug

不知道你为什么会觉得这东西没用，但 UML 并不是所谓“八股文”，不同的图有着其不同的适用环境
有些图可能已经不适合现代的软件开发方式，但因为这个就说 UML 无用就如同有人不喜欢吃香菜就骂蔬菜一样

至于觉得业务变了之后图片就没用了，那是你们没有经历过那种整合的开发方式而已
以前用的比较多的 rational rose （这个我们不用，因为跟 IDE 不太搭，我们主用 mmm ），类图跟代码是双向绑定的，你画好类图，代码会自动生成，反之改了代码类图也会自动更新