@Vnaner 指个路子？

群辉官方的东西配置比较低，可以考虑自己组装。

不过 nas 真的香，主要网络存储过于方便了。

我好奇楼上准备让一年的面什么厂子，动不动出去面源码？

我感觉没问题，熟悉、熟练、了解，都是个人而言的，个人更了解某方面让面试官有个数。

阻止携号转网的说法根本站不住脚，移动早就有了这个，而且阻止携号转网就 3 个月有点说不过去吧。

这个是移动难得的福利，而且本身我就移动大王卡，完全没理由转网

状态不好，老打错字，忽略下五楼

”阻塞和非阻塞是相对的，同步代码下面你还是会被阻塞“ => "同步和异步是相对的，同步代码下面你会被阻塞"

”同步和异步是相对的，同步代码下面你还是会被阻塞“ => "阻塞和非阻塞是相对的，同步代码下面你会被阻塞"

@ruandao 我可能解释错误了，不好意思，阻塞和非阻塞是相对的，同步代码下面你还是会被阻塞，多线程的某个线程你仍然也会被阻塞，但是多线程仍然是异步。而阻塞和非阻塞是因为非阻塞采用了事件队列进行轮询 / event loop，这种非阻塞式 IO 的模型实现的，将事件拆成回调的形式，等辅助用的 IO 线程结束后，才将回调加入队列里面等待执行，最大程度的减少阻塞和线程切换开销。

另外你可以认为 worker thread 就是用户线程，通过队列机制，采用回调机制来安排 worker thread 减少开销。再上面的 协程 就是利用回调链，包装一次回调函数，让回调不用写在回调函数里面而是写成链式或者同步的样子（ async await ）。

@wly19960911 记错单词， 是 worker thread ，工作线程。

阻塞和非阻塞指的是 work thread，如果是异步阻塞的话，需要更多的 work thread 带来的开销更大，而异步非阻塞能使用少量的 work thread 来排队，而 io 线程交给线程池处理，减少开更多线程的切换开销，适合 IO 密集型而非 计算密集型。

@wysnylc 但是我是 rxjs （跑

不过到时候看看 flow 是什么情况，毕竟我也用 Java

@WenhaoWu rxJava 的 catch 和 trycatch 没什么区别，讨论的核心还是要不要 catch。是我 do/tap/map 里面判断掉然后 filter 还是用 throw Error，来进行流程控制。

我感觉会 Rx Java 就没必要参与这个讨论了…Rx Java 本来就是一套流程控制库，充分使用自然知道会使用自己认为更好的策略

@crclz 跟我想法一样。不过 dalao 还是更简练深刻，我讲的废话多…大佬有兴趣看我回复记录就能看见了。


@wysnylc 难怪开了一贴，原来在这里讨论…哈哈哈

@wysnylc 其实我这里也没有聊兼容性和扩展性，这个更多需要依赖业务和经验，可惜我也对这块也不是很熟悉。我工作经验还不是很久。

但是我能充分感受到的是，不用 try catch 最大的原因是因为看了一段代码之后，会开始思考究竟需要再哪个流程 try catch，那个流程怎么进行 try catch。但是往往面临的问题是我自己连 try catch 在哪里都不一定能确定下来

比如 一个 (流程 A) 里面执行了 (方法 B) ，B 执行了 (方法 C) ，A 结束之后执行 (流程 H)，但是这个时候 C 里面 throw 了 error，我需要在 流程 A 里面处理，但是问题是我需要来自 B 的数据。这时候这个代码就写的一塌糊涂。这还是 3 层，如果是 4 层、5 层呢，怎么处理？


@lcdtyph 在运行效率面前我选择工作效率，如果舍弃了 try catch 还出了性能问题，那么已经是无力挽回了。有流程控制还能想办法优化。

@wysnylc 最主要的是问题还是一些人代码写的烂，不懂写过程和重构。（以下只针对不懂怎么写流程的新手）

通俗点说，多少人经历过业务逻辑自己来重构的？比如写一个过程，不少人从开始学习就以自己的角度来定义 interface 或者 private method，然后导致的问题就是自己并不是真正把一套流程看清楚然后编写的，比如一个业务流程被分到两个方法里面（当然，更多的还是流程写一个方法不重构的，偶尔写点 Utils 来处理下重复逻辑）。

再简单点说，一个方法分为业务 /流程代码， 以及数据处理代码。流程代码本来就只需要调用重构后的方法为主和业务判断处理就行了，结果一个方法写的和面条一样。最后连流程都不知道，还祈求这些人能进行流程上的 try catch 这个根本做不到...所以我带人的时候建议他们，别写一些自以为是的封装方法和 interface，写完了流程自己整理一下，然后根据流程重构一下，更别在流程代码里面写一些过长的数据处理。

这点我尤其要批评以 vue 和 angular 的部分前端开发， 一个组件下来连个有 return 都没有，连自己的流程都不清楚，还怎么控制流程，更不可能去做 try catch，做下来根本没法控制，只能引用更多的状态来控制多个方法的操作。本来不需要的东西结果越写越复杂。

所以还是强调我第一句，一些人写代码根本没有流程的概念。没有就多写一些面条方法然后自己多看一眼。怎么重构才对。

前端的话，我建议写方法养成一个习惯，一个只有一个异步调用的代码，分三个阶段，声明主要局部变量和把 this 上的数据 赋值 /浅拷贝 给局部变量，然后中间的所有流程不允许调用 this 上面的 data，然后赋值要等所有的操作再赋值（就像 react ）。
但是比 react 多的步骤是局部变量，原因还是这块的话能对重构友好，首先对 debug 影响少（因为 debug 的时候你总会去看看谁调用了状态），第二是对重构友好，重构瞬间能产生一个没有副作用的 function。这样的话本身写出来的代码能简洁而且极易 debug 和维护。同时如果需要 try catch 也是很容易的。

3. 我并不喜欢。徒增难度而已，很多时候错误处理和 throw 的地方跨了好几个调用栈，你这意味着你每个调用栈都可以需要有处理来自 method 的 response。

我有一个业务是有 http 调用和 sql 调用，还有调用结束之后的 业务报错。 具体是 A -> B -> HTTP, A -> B -> SQL, 这个时候不管是 HTTP 或者 SQL 还是 B 里面业务逻辑，都可能会异常，但是这个异常都必须交给 A 来响应，说实话如果我写了 method response 的话，本身就是给自己增加烦恼，我还要在 B 里面区分 response 然后交给 A，这个流程代码会写的很冗长。

@ps1aniuge 2 年以上难道就没问题？ 2 年以上能找到一个薪资低的也不容易。

@loliyu 然而唤醒率还不咋样...非常智障

@fpure 这个也是为什么我买 jetbrain 全家桶的理由而不是单个 idea ultimate， 有的人问 idea 不是都能做吗... 问题无关插件都怼上来的时候，占空间还占快捷键。

jetbrain 多个语言多种 ide，虽然功能有相互交叉的，但是 workspace 基本都是不一样的。如果 vscode 出了这个功能我感觉会更受欢迎，就像当初 eclipse 各种被魔改成某种特殊 ide 一样，但是 vscode 的插件安装来的更为方便和直观，小工作量开发还是能顶上去的。