@fhsan
@751327

基本上问这个问题就不是代码的问题，或者说技术问题，而更多的是管理问题。用技术的方式解决管理问题其实很糟糕。
真如楼主说的，团队强制让人写注释了，谁对注释负责，谁对代码负责。

还记得《让子弹飞》中的六子么？当你真的遇到了问题哭着说：“你们看看看啊，我支持了一碗凉粉”。你会发现周边根本没人听你的。

代码不会说谎，注释会。

@mightofcode 赞同。距离相当长，这些原则如果不加思考的使用，可能还不如把精力集中在问题本身来的更直接。

哈哈，学习了~

我已经常有这样的情况了，上车系安全带的时候手往后一拉，然后就不敢动了，休息好久手才能动，给我的感觉也是疼的要死，好像肌肉断了似得。

> 为什么我们的接口很少被多个类实现
这也是我一直思考的，是我们的问题，还是接口的问题。依赖倒置是一种手段，这种手段有着将代码变复杂的代价。为什么要一开始就引入这个代价？为什么不在开始的时候做一些模块化，通过这些轻量级的手段将未来的改动做一定程度的限制。在：1，需要用到 DIP 的时候在引入 DIP 。2，除非已开始你就知道这个地方就需要 DIP 。

我们在看这些讲架构书的时候，很多时候为了讨论问题的简单，会做一些前置假设。我们有时候需要看看这些前置假设是否真的成立，是否也是你的问题。别强行将别人项目的问题变成自己项目的问题。

@rapperx2 好像换个频道就可以了，我换到“编程”频道了。

@rapperx2 我也觉得，我发布到“阅读”频道就这样了，没有找地方调整呢。

让我一度怀疑这不是丑，而是艺术。怎么就能做丑的这么明显呢？大神。

其实这个是楼主一个人的说话，不一定反应的全部。或者说同一个情节，不同的导演会拍出完全不同的效果。

不用这么纠结了，找个工作，回归早上出门，晚上回家。不用在乎太多，28K 跟 40K 其实没有区别。如果这样能回来，那是最好，如果不能回来，表示这跟你本身也没有多大关系了——即使你 200W 一年，事情也不能解决，就随缘吧。

2017 的，已经换过一次，半年左右了，现在左边 shift 键又谈不起来了。准备找个时间再去换一次。

协程-主要还是保持状态，像你这种还是需要异步 IO，asyncio 。
在应用上，主要还是生成器，比如你处理未知网络数据，你可以使用协程去迭代处理。
https://www.imzjy.com/blog/2015-01-01-coroutine

这个是个好问题，我在自己的一篇博客中总结过： https://www.imzjy.com/blog/2018-07-06-writing-good-log

通常下面的情况可以考虑加一行日志：

- 程序的参数检查一下，函数输入决定输出，输入都不对，输出怎么可能对呢？
- 第三方回传的时候检查一下，返回数据了么，返回大小是多少，调用时间用了多少？
- 关键业务点，留下点脚印，打一些 Info 类的日志。
- 有副作用的函数，比如操作网络，操作磁盘，数据库操作，有时候越是难的 bug，越是这些觉得不可能出错的地方出错。
- 应用程序启动相关的，比如加载的模块，影响行为的配置文件，环境变量，等等。
- 数据驱动着应用，常常 bug 在数据中。加一些日志在已有的数据上，即使不记录具体内容，也要记一下大小。
- 别在同一个地方跌倒两次。抓到一个 bug，或者业务漏洞修复，写个测试区覆盖或许很难，但是记一行日志不费多少电。

Finder 的问题，把 Finder 杀了再启动一下就好了。

@goophy

人艰不拆啊。不算上学校写的考试代码，2005 年时候是我刚真正接触开发的时候。

我自己更多的感受是说，在我进入编程的时候，听到好多言论。比如：一切都是对象。比如算法就是时间换空间，或者空间换时间，比如什么 SOLID。很多*名言*我在当时压根不知道为什么，没人跟我解释——听着照做就行了。以现在眼光看，有些压根就是瞎说，有些需要时间去理解，有些你听到的跟你理解的不在一个层次上。

Linus 本身想法很简单，debugger 太细节了，你要用的时候自然会用。但是解决问题需要看到问题本质。好像同事告诉你，把这里往左调 5px，其实真正的问题不在那 5px 上。