@InkAndBanner #15
一，性能上的，数据完整上的哪些问题？ 你有没有实际经历或者遇到过这些问题？还是只是在 JD 接受到的教育或者是搜索引擎搜出来的问题？
二，这可能不叫厌恶感，这跟每个人的性格有关，也是每一个成熟的职场人必须要学会接受和解决的问题。
三，我承认搜索引擎很伟大，谷歌百度能搜到的一些问题和分析都是前人经过大量的实践猜出来的各种坑。这些搜出来的内容在大部分的情况下是正确答案，但是在很多业务场景下又是不那么“正确”的答案。说白了，就是两面性的问题。

https://stackoverflow.com/questions/2557512/pros-and-cons-of-programmatically-enforcing-foreign-key-than-in-database 是我以 DB foreign Key pros and cons 作为关键字，在谷歌搜出来的排名第一的 StackOverflow 上的结果，你会发现最佳答案是推荐使用外键的。
那么这是不是跟你从百度搜出来的或者 JD 接受的教育是不一样的呢？
我不好说谁对谁错，只是使用场景不一样，就像 SO 上那位说的那用，很多时候我们觉得数据库性能有问题，大部分的情况下是因为我们对数据库了解得还不够深入。

你或者再可以往这方面去想，JD 可以不用外键而用代码去控制，是因为他们的程序猿的能力很强，可以 100%确保代码不会有 bug （外键相关的 bug ），也不会有脏数据的产生，但是你现在所在的公司，程序猿的整体能力可以达到这样嘛？

回答你的问题：
1. 你不能武断的觉得 JD 就是对的，你 Leader 就是错的。
2. 职场玻璃心需要自己去克服和调节。 （这里玻璃心不是贬义的意思，就是描述一种现象）

楼主你需要更深入的去思考你所遇到的每一个问题（不仅仅是技术问题）。

很好奇，为什么 JD 不允许使用外键，你就认为所有的公司都不应该使用外键？（或者是我理解错了你的意思？）
还有这种“厌恶感”从何而来？

在 JD 接受的教育是不使用外键，那么你有没有深思过 JD 为什么不允许使用外键？
在当前公司要使用外键，那么你有没有想过（或者直接问 Leader ）为什么要使用外键？（除了避免脏数据之外的理由）
使用和不使用外键的优缺点是什么？适用场景分别是什么？

如果只是一味的接受 JD 给的教育，觉得外键是没有必要的，那么当初数据库的设计者又为什么要设计出外键这么一个东西呢？

@mikewoo #75 我也是，Lindberg 的镜架，真贵。。。。

各位有没有在 Tapole 配过的？

在我厂，如果代码格式化不标准，build 都没法 build。
我们写了一大堆 Code Rules 放在预编译阶段去检查代码规范。

提问真的需要技巧，这一点楼上已经说了很多了。

我想说的是一个新人刚进一家公司慢慢的成长节奏。
如果这家公司的代码库非常的庞大，让一个刚来的新人去闷头看代码显然是不现实的做法。
正确的节奏应该是分一些重要性不是很高的 issue 给他，让他去慢慢的 Debug。 （ PS.我一直觉得 Debug 是理解一个庞大代码库最有效的手段）
Debug 多了，对代码自然就了解多了。

回到楼主的疑惑，你的这个新师傅回答问题的方式不太好，即便是要你去看代码，也应该给一些方向，比如告诉你去哪个 solution，或者在哪个文件里打个断点，诸如此类。

所以楼主也别太困惑，说不定就是他懒，不知道怎么做一个好的 Mentor。

我厂不加班。

@followyourheart @songjiaxin2008 支持现学啊。

试试我厂，不算互联网，但是技术氛围还算浓厚。

Azure 香港，又快又稳。

@deepdark #17 招行 ETC 在哪里办理？
另外求教楼上各位，ETC 注销的时候麻烦不麻烦？

成本最低的创业就是找一份 955 的工作，用你的业余时间去尝试你的 idea。
因为工作时间之外的创业的试错成本是最低的。

@JerryCha 招啊，前段时间还有一个在上海的哥们直接面试悉尼的岗，然后去悉尼 Office 了呀。

@jsnjfz 是的是的，不过测试用机还是两台显示器。
@seki @exonuclease 哈哈哈，是你们的 Gold Partner, Azure Devops 我们暂时没没有用。
@EricLeo 啥公司呀？
@wu6694449 其实国外.NET 用得还挺多的。

我觉得当前帖子下，楼主说的这些都是楼主自己的主观感受，没有实际的案例。
楼主说 Leader 的方法烂，但是没有说出烂在哪里，如果能举出一个例子，也好让大家知道到底是谁的方法更优。而且很多时候方法的优劣，并不好通过一个人的单方面说辞去判断，要放在一个具体的产品的样本中去判断。

当一个产品足够大的时候，Leader 必然是对产品的了解比你更多的，他在做一个决定的时候，必然是从全局去考虑。

举个简单例子（只是例子），你深谙 SOLID 之道，在做一个简单的 issue fixing 的 work item 的时候，你觉得有几个文件的代码看着非常的繁冗，完全背离了 SOLID 原则，你想去做一下重构。 如果是我，我可能不会允许你在当前这个 work item 下去做这个事情，而会建议你新建一个 WI，专门去搞这个重构。
你可能不会同意，觉得是顺带手的事情，但是从大局来看，每一个 WI 拆分得越细，目标越单一，出错的概率就越小, Reviewer 审查代码的时候也越容易。
Fix Issue 就是 Fix Issue, 重构就是重构，New Feature 就是 New Feature.

综上来看，我无法判断你和你的 Leader 两个人的方法和观点谁对谁错，但是有一点他没有做好，就是他否决你的方案的时候，没有给你一个非常合理的解释，也没有照顾到你的情绪，所以才会让你觉得他的方法烂，和觉得他固执。

以上是我作为 Leader 的一些感觉和判断，不一定对，但是希望可以给楼主一个从另外一个角度去看待这个问题的可能性。

台式机，i9, 64g,3 显示器。

可以把房子租在 Mascot，离 CT 近一点，不过最近公寓断裂的消息也是够吓人的。