不是很能理解为什么 ban 仓库之余还要 ban 账号，不过联想想之前那位破坏了自己仓库结果呗 ban 号的人，也不意外了

不同软件对这几个环境变量的支持程度不一样，有的吃 all ，有的不吃；有的大小写不敏感，有的很敏感······所以保险的方法是同时设定 http_proxy, https_proxy, all_proxy ，如果你有觉得不够可靠，对应的大写也设定一份，我观察的：吃 all 的不是很多

sql 只做数据层面的更基础和通用的业务逻辑就没啥问题

这 sql 没什么问题，你是没见过把文案塞 sql 里，在 SQL 里格式化时间日期的，这才是真的滥用。

别说了，一会儿又打起来了···

完，到现在不会这样吐痰，只能不停的用力咳，把痰咳出来

看了下你的附言，正确的做法大概是直接集成类 A ，自己实现一部分功能。出这种问题要么是你对这俩类的使用方法不恰当，要么就是这俩类本身封装的不好，才会让你需要做这么奇怪的事。
C++下方法可以是虚的也可以不是，Java 都是虚的就没正常办法了…

这…确定关系花十几万定亲…这怎么一种做生意签合同交定金的感觉…

@zxjunz 其实就是不太理解，如何喜欢 /利益相关能到这个程度，对于大部分程序员来说，语言应该只是个工具吧～～～

没必要，提一下是在说服不了，就努力换团队好了

总有人会选择无视自己的现实状况，盲目跟从某些大厂根据自己的实际状况制定的最佳实践，却忽视了所谓最佳实践总是有其特定上下文的

@dcoder 是啊，这一切都需要在特定的上下文中进行权衡，也就是我上文说的脱离具体上下文很难讲该如何做，性价比到底是高还是低。

@dcoder 解释一下我的上条发言，就是说有人可能不愿意学习某个特定的 DSL ，导致本来一行代码完成的内容需要他额外写一百行来实现。脱离具体的上下文很难说谁更“高效”，只不过是个人的选择而已，我所谓的“正确”也是在其中夹杂了我的个人偏见。

@dcoder 认真设计 schema 和 index 是最基本的要求，这和“正确地”使用工具并不冲突。当然这里我对“正确”的定义可能有些狭隘。

@iseki #2 最神奇的是，他直接要求删掉外键的理由是，外键耽误他无视逻辑关系的 delete 删数据了……