B 站“先看测评”号做过吹风机横评，可以看看，我老婆看完后决定买松下的了。

有定型需求可以选高速吹风机，但不一定非要买戴森的，只不过戴森外形确实很好看；虽然戴森技术确实很强，但吹风机的溢价程度也是较高。

这个得团队达成一致，并有技术经理通过 Code Review 等手段巩固执行，你可以向团队或者技术经理反馈这个问题。

我们每天会抽出一个小时左右团队成员所有开发人员进行快速 Review，有的代码可读性低技术经理会提出来，要么改写法，要么加注释，做得多了团队成员会逐渐养成注意代码可读性的习惯。

程序员的产能是难以由硬性指标衡量的，之前看过一个漫画，就是以代码行数来评估绩效，结果 IT 和程序员开始进行对抗，程序员写了各种工具来处理源代码生成行数更多的代码，IT 写了各种工具来消化这些无意义的行数来提高绩效精度，最终浪费了大量产能。

建议以任务作为单位进行工作量评估。我觉得和投篮一样，凭借不断尝试、反馈、修正来成为一种感性经验。
敏捷方法论里有一个 Story Point 的方法论也可以借鉴，可以衡量任务难度、个人能力、项目健康程度等。

规划工作时间分配工作任务是有挺多技巧的，关键的一点是重要任务不要填满工作时长，留出一定比例的工作时长给不那么重要的任务，这样当重要任务遇到突发情况需要延长的时候，挤掉不重要的任务就不会对整体项目计划和关键结果造成太大影响。

你想精准控制内存，就得直接控制内存芯片，最接近这个目标的可能是单片机。

JS 的内存管理被抽象出了几层，比如 JS 引擎有自己的“内存”管理机制，运行引擎的操作系统也有自己的“内存”管理机制，操作系统运行的硬件系统也有自己的内存管理机制。你在 JS 层去看内存情况只能看到 JS 引擎抽象出来的内存情况，在 JS 引擎层看也只能看到操作系统给 JS 引擎抽象出来的内存空间情况。

CPU 通常不会直接用内存数据进行计算，而是会经过有多级缓存，最终到达 CPU 的寄存器再真正执行计算，而多级缓存、寄存器的情况和使用方式也都影响计算效率。

JS 是一种抽象程度很高的语言，不同 JS 引擎的底层实现有差别，可能会为了优化执行效率、内存占用量玩各种内存优化，而且现代 JS 引擎的执行效率极高，完全能满足绝大多数业务场景，而且如今做极致性能优化的成本可能会高于性能浪费的成本，所以有时候加硬件是更经济的方案。

在操作系统级别有对计算和存储性能较高的要求，可以考虑使用 WebAssembly 方案，使用 C\C++\Rust 等系统开发语言写高性能程序，然后通过 WebAssembly 技术与 JS 程序交互。如果使用 Node.js 还可以考虑 N-API 方案。

这，是不是要先看看是不是小米的问题，毕竟安卓机品牌型号那么多，小米也绝不是安卓机里面各方面都做得最好的。

我算是安卓老用户了，Nexus5=》 Nexus6=》 Nexus5X=》 Pixel1=》三星 GalaxyS9
以前都是 Google 全家桶，国产应用都扔冰箱，体验很棒，用了三星之后感觉三星的系统做得也挺贴心的。

1. 我是三星自带相册和 Google Photos 一起用，Google 产品就不多说了，三星相册有隐藏或者取消隐藏相册的功能，还可以排序。很多 App 开发不规范，硬要把资源图片塞到公共存储区域，这个问题下一代 Android 据说会从系统机制上避免。
2. 我每次拍完照或截完图，进入微信都会自动显示是否要发送新的图片，没遇到找不到图的问题。
3. 不怎么用微信语音，主要是质量很差，很多时候断了直接换打电话。
4. 三星和 AKG 有合作，而且有杜比全景声，所以……
5. 要说安卓和苹果 PK 拍照，那 Pixel 基本上是王者，我 2016 年的 Pixel1 都吊打 2018 年的三星 GalaxyS9，国产手机拍照以美颜为主，相机真正核心的技术还是得看技术积累，要不然相机厂商都垮了不是。
6. 我用联通，高铁上基本没信号，所以没连续通话过，再加上微信本身通话也不好用。但我在高铁上会看离线视频和玩一些益智游戏，如果是高性能模式也绝不会两个小时没电那么夸张，预期长时间使用我一般会跳到优化电量的模式，撑一天没问题。要不你看看小米有没有调用电模式的功能，一般不打游戏不看高分 HDR 视频用不着高性能模式。
7. 同 5，小米的手机从来都没有在国内外都受到认可过，连华为都没有过。

银行 App 我只认为招行做得合格，其他各银行都做得很糟糕，但这个不是 Android 自己的问题，顶多算是生态问题。

要是潜意识里真的不任何 Android，有可能说明确实不适合自己，可以考虑换苹果。

壹目设计，我们去年装的，8 、9 月份设计，10 月份买材料同时拆除旧装修，年底装完（后来赶上疫情有半年家具电器进不了）。
因为自己预算没控制好以及对材料要求较高，所以最终花了大概 30W ；包含设计+施工+材料+家具+电器，设计和施工费用也就几万，后几项选得超预算了。

装的现代简约风。

他们的模式是只管设计和施工，材料基本全都客户自己买，坏处是得投入大量精力做功课、到处挑主材，好处是最终成本主要取决于客户买了多少钱的材料。有第三方监理。个人感觉还挺靠谱的。

设计阶段设计师按不同等级有不同的价格档位，按平米收，但有个 80 平的最低消费，我们找的设计师在做完我们项目后就升级了，算是比较幸运。
施工阶段又分几个子阶段，整体款分几期收取，有一些量比较大的辅材在用之前会给客户出预算，客户可以选择用施工队的还是自己买。

当时图省事材料基本上都是从北居然买的，居然之家的东西保障比较好，但是价格比较高，有精力可以自己找找其他性价比更高的渠道。
关于挑材料有个问题需要注意一下，去一个商城转一圈可以看到各种厂商的材料，能比较出优劣，但人就是看到了更好的东西之后就对品质稍次的东西失去兴趣了，这时候意志力不强可能就会导致超预算。

现在这个时间装修比较尴尬，因为北京集中供暖都基本上水了，除非你是自采暖或者家里有阀门可以拆暖气，否则可能对施工有影响。

想节省一些硬盘空间，昨天换了 pnpm，但后来发现不支持 npm 的 package-lock 标准，于是又用回了 npm……

可以研究一下 path 环境变量的覆盖顺序，让 yarn 的 bin 路径优先级高于 npm 的，这样就会优先执行 yarn 下的程序，yarn 下没有才回去 npm 下找。

除非是进核心研发团队攻克技术问题，比如芯片、AI 、区块链、底层系统开发等，未来换工作还是要技术、业务对半看的，你在你所应聘的业务方向有过比较好的行业经验，会更有胜算。

所以最好研究一下各个行业的发展趋势，然后制定一个职业规划，最终按照规划选择岗位。

腾讯和微软要是内部未来有转岗的机会的话也挺好的（但最好不好直接问招聘方，会让人认为你不稳定，可以私下找些在这些公司工作的人打听一下），我有个朋友一直想做 Kernel 开发，一开始以系统开发进的阿里（做些技术难度有限的内部系统），转岗开放后就转了 Kernel 开发岗。

字节喜欢的人很喜欢，讨厌的人也很讨厌，内部工作效率很高，副作用可能就是累，能不能有成长得看实际做什么业务，因为字节有很多新业务，也有成熟的业务，入职后技术和业务起点不一样。

海外不了解，但如果未来长期规划有移居海外的打算，可以考虑。

三星+联通 4g，望京信号很差。

打 10010 投诉吧，他们会解决的，公司换新办公室的时候信号就不好，打了几次投诉电话就过来人装设备了。

@chenpingan 魔兽世界、剑网 3 啥的这些传统概念上的网游都是 RPG 。

Untitled Goose Game
两人玩不错，不知道算不算“刷副本”类的游戏。

自己买的索尼 OLED，很香，如果对 HDR 没有极致追求或者担心烧屏问题也可以考虑非 OLED 的版本。
无广告，近乎原生的 Android TV 系统。

国行想看油管可以用 https://github.com/yuliskov/SmartYouTubeTV
没折腾过网飞。
当然机场要给力。

另外国内腾讯（极光）有不少 HDR 和杜比片源。

虚拟机和 idea(JVM 进程)吃内存比较多，虚拟机开得多的话最好核心数多一些，网游吃显卡性能可高可低，看你开多少画质。

这个节点装机有点尴尬，AMD 前几天刚发布了 5000 系列 CPU，新显卡发布会就在路上，NVIDIA 也刚发布 30 系显卡，性价比比以往要高很多，要不再等等？

@zc1249274251 没大看懂问题。

假设像楼主例子描述一样，因为各种原因最终这几部分确实拆成了几个独立的微服务，那么微服务之间的关系也是需要根据实际情况考虑的，比如你可以让 BFF 分别去调用订单服务、用户服务、商品服务，也可以让 BFF 去调用订单服务、让订单服务去调用商品服务、让商品服务去调用用户服务，一个微服务可能内部是由多个更小的微服务组成，调用链路可以根据需求优化缩短，总之一切都是要按照实际需求来权衡。

国内很多人都不理解开源究竟意味着什么，而且很多人连线上交流的基本礼节都没有，GitHub 上很多中文项目经常会遇到乱七八糟的 Issues，还记得那个“求不要更新了，学不动了”的 Issues 嘛，现实就是这样的。

如果不想经营赚钱的话，建议关闭一切公共讨论渠道，设置 Issues 也都关掉，只留 Pull Request，要是真的感兴趣就提 Pull Request 贡献代码，没有任何入口水（可以用机器人清理明显是水的 PR ）。贡献较多的人可以拉一个开发者小群，不那么乌烟瘴气。

可以给用户提供支持方式，比如邮箱，或者问卷啥的。

尽量用大开源项目背书的开源协议，如 MPL-2.0 （类似 GPL 但兼容“脚本及程序”的语言较好）、Apache 2.0 、MIT （可能对贡献者不大友好）等等，这些协议国际上有胜诉案例，有案例背书法律上有保障，当然有条件也可以针对国内法律咨询律师。

最后我对“国产 Metlab”无感，你要是有个愿景，而且坚信这个愿景是靠谱的，就勇敢做下去就行了，喜欢你的产品的人自然会来用并支持你的工作，不喜欢的人就让他另请高明就好了。

@zarte 我用微服务的方式跟用数据库表的方式是一样的，宏服务提供数据要聚合多个表的数据，那么微服务提供数据也要聚合多个服务的数据。

从例子上看，查询的主体是订单，订单里会存商品 ID，商品里会存卖家用户的 ID，所以首先是查订单，查出订单后根据订单里的商品 ID 去商品服务查商品信息，然后再根据商品信息里的卖家用户 ID 来查用户信息，因为商品、用户数据可能有重复，所以每一步查询条件可以去重，查出来的数据可以重用。
乍一看可能会觉得这样比较麻烦，这就是微服务拆分需要权衡的事情，我自己做订单业务的时候是把订单、商品、SKU 、活动优惠等放在一个支付微服务中，用户数据集中放在用户微服务上，相应的订单成交后发货和产生的权益又有各自的微服务，这样能做到既不会有过于繁重的跨服务调用，又能做好微服务之间的开发、性能、故障的隔离以及复用。
整体上建议微服务设计以加法为主（服务由少逐渐变多），一开始业务简单的时候可以做宏服务，等某一功能模块具备一定的规模和独立性后再考虑拆成微服务。