我想请教个问题，自建直播要怎么解决带宽问题？

能发觉自己是无知的，比连自己是无知的这一情况都不了解，是不是姚好很多。


@3dwelcome 你的老师说深入本身没错，但是他少说了一个前提，深入，应该去研究那些基础的，核心的原理，这些东西，很难发生变化——比如整个计算机体系都是架构在冯诺依曼架构上的，这部分东西就很值得深入。但是现在有很多应用层级的东西，今天走明天来，这些就完全没有深入的价值，相反广度优先。而且这类型的东西你多看几个就会发现，他们差不到哪里去，基本原理和限制绕不过去，都是放弃一部分作为代价强化另外一个部分；只是每家选择的代价和强化方向不同而已

@Akiya 不可能，真像你说的钱多不加班，没硬伤，只是知名度低的话，绝对会有人来，大家又不傻，肯定是要么你没说真话，要么就是你的公司存在某些你自己都不知道的黑点，建议去圈子打听一下，或者找之前的爽约者问问情况

为啥现在微软的 C 端产品 bug 多？这就要问一个叫陆奇的人，为啥在微软期间不声不响的把测试部分给拆了，而且提出那个著名的“让用户当测试”的爆论

至少 Win7 时期，微软的 C 端产品的质量可不是这样

楼主营销大成功啊，按通常这种招聘贴很快就淹水了，现在这贴都上热榜了，楼主有自媒体大才，何必干 HR

@BoringTu
TS 本质是一种约束，作为约束，它其实约束的还不够狠，any 仍然能满天飞。

但是约束本质是软件工程的一个大方向，这个前提是不会变的。

高手永远太少，所以需要大量的工具人来写代码，这是软件工程存在的意义。这是历史的车轮，TS 也只是车轮上的一个零件而已。

资本希望把软件行业打造成不需要高手，填充机器零件就能完成的流水线的野心不是一天两天了，这也是个历史趋势，悲观的说，程序员其实在实践这个趋势。

抱怨没有天赋的选手没有意义，让没有天赋的选手也能写代码本身就是历史趋势的一部分。搞技术的本身要能跳出技术的局限性，仅仅自己写代码是没有前途的，你一个人再牛逼一天也就 24 小时啊

楼主的这个疑问，在知乎有几个很经典的问题可以回答：
“为什么 2010 年前后诞生的语言(如 Golang, Rust, Swift)都是强类型 + 静态”
“在大型项目上，Python 是个烂语言吗”，
“在大型项目上，JavaScript 是个烂语言吗”


总结的说，第一代动态语言，仅仅是人类希望获得类型推导时进行的一次尝试，但是很明显，这个尝试失败，没有类型约束的系统天生不适合协作。它带来了额外的心智负担。


楼主说自己写了 11 年，还是认为 js 的动态类型是优势，并觉得自己绝不会在过于灵活的动态系统面前出错，首先我承认，楼主应该是记忆力非常超群的那种人，其次呢，我基本可以肯定，楼主很少和人协作，计算协作估计也是和自己水平差不多的人协作，所以意识不到问题在哪里。


但是我仍然要说，所谓现代软件工程存在的意义，就是把一群实力其实一般的人，拉到一起写代码的。换句话说，楼主这样的人虽然优秀，但是稀少，但是再优秀的人，它的工作时间也就那么多，仍然有大量的代码，必须由不那么优秀的人完成。
当你必须考虑让不那么优秀的人一起协作的时候，你就会意识到过于灵活的类型系统是缺陷了。


楼主写了 11 年，还是停留在“我很优秀，我身边的人也很优秀，所以我不需要约束，不需要严格的类型系统限制我的工作”这个思考层次，其实已经有点滞后了，真诚的建议楼主，跳出技术圈子的约束。
理解电脑不过是工具，信息化的过程本质就是让更多的“傻瓜”也能参与和使用算力的过程。


计算机的世界需要大神，但是计算机发展的历史进程是拉入更多的普通人，作为大神，应该顺应这个历史进程，而不是仗着自己的头脑先天有优势，挡在历史车论前面当螳螂

@gBurnX 想知道你的“有条件”，是指的什么条件，虚拟化对硬件性能要求不低的

当然是根据钱来的，性能只有不够的，问题是钱更不够

@jsq2627 fb 对 rn 是半放弃状态？这是哪里的说法？

@yanlaz 我的手机上一天到晚报美团耗电异常，说真的美团开机体验一点都不好，比支付宝启动都慢

别想了，你保证不了的，就现在互联网项目那种动不动推了重来的模式，你怎么弄都没有用，所谓扩展，是保证原有模块基本不变的情况下，新增功能，可现在的开发需求动不动玩的是“推翻”，还扯淡什么“拥抱变化”。这种换神仙也没用，推了重来是唯一方式

@brader 目前大家说的流程我已经非常清晰了，只是这还是没有解决我说的那个疑问

我在 hotfix 为了修复暂时删除了 A 文件，我肯定需要把 Hotfix 合并到 dev 上去的，此时 dev 上的 A 文件是不是会被删掉?按照顶楼说的那个场景：会，因为 hotfix 对 A 文件做的修改，在版本线路上比 dev 新。那么这就会造成 dev 在合并进来 hotfix 后，不得不重新去找回 A 文件，这个流程总觉得有点别扭

@zhengxiaowai 那篇文章显然是为了故意造成这个效果，才做这样的场景操作的，
不过你提到的场景我也不太理解，为什么：
master 分支比 dev 分支多了一个 commit，再和 main 分支 merge request 的时候就会报冲突？这个冲突的原因是什么？是因为 git 找不到合并需要的 base 节点了吗？

@janus77
正确办法应该是这样的：main 拉一个新分支做 hotfix，该分支删掉 A 文件。然后先合到 dev 分支上去，再从 dev 合到 main
======
我的疑惑在这里，hotfix 删除 A 文件，再合并到 dev 分支上，这么干是否会导致 dev 分支的 A 文件被删掉？我觉得应该是会的，也就是说 dev 分支将不得不在合并后想办法去“找回”A 文件，这个体验似乎，有点糟糕？

@chnyuwen 语言代表了思维方式？这话不对吧，应该是语言的范式代表了思维方式，问题是语言范式就那几种，过程范式，对象范式，函数范式。再特殊一点还有类似 SQL 的这种 4GL 。

语言不代表思维方式，语言的范式代表了思维方式，但是语言的范式的种类远没有语言本身多。同样范式的高级语言的差别没有你们想的那么大

@guyeu 能不能举个同时有 jre 版本和安卓版本库的例子

你 B 越过 A 直接操作 A 业务范围内的数据，那 A 的存在意义在哪里？

@bthulu 这倒是一个新奇的思路，可以保证秘钥只在内存里存在，而且很难拿到，问题是，你司启动一个服务要半个到一个小时？