“我林家满门忠烈，你懂个屁的 Windows”

有可能你的洁癖只是别人的规范，人家已经把按规范做导致的出码速率“降低”作为规范化管理和质控的成本考虑进去了，也有可能人家出码过程的局部低效率换来的是程序质量提升带来的整体高效益。

群众理解的“高通进军 PC 市场”：培育 ARM PC 生态，从 X86 手里抢份额
资本理解的“高通进军 PC 市场”：买一个遭遇打击但市场份额还在的 X86 CPU 领袖

TS 的定位是为大型项目的工程化开发而创造出来的，JS 的超集。所以以你的情况学 TS 会增加明显的学习负担而没有明显的收益。
至于不同语言之间的配合，所谓的不同语言有两种情况，一是在同一个 scope ，比如都是后端的业务逻辑，那么一般在一个项目里会统一，比如约好都用 Java 或者都用 Python 或者都用 JS/TS ，或者再宽限一些，都用 JVM 的语言，比如 Java 、Scala 、Kotlin 都用，但是划分好不同人开发的模块边界；另一种情况是在不同的 scope ，比如前端用 JS/TS （目前的情况，前端基本上就是 JS 及其衍生语言，别的语言从项目运作角度不现实），后端用 Java ，这样其实是没关系的，因为前后端的代码并不直接互操作，而是通过 HTTP 协议传输数据。另外，如果一个项目的后端涉及不同语言的强势生态，或者要跟存量系统的代码对接，那其实可以解耦成第二种情况，并不写在一个大程序里，而是通过网络调用（说法不是很严谨，大致可以这么理解）对方接口来传数据的方式来集成，那其实跟是不是一种语言就没关系了。

@wxw752 中间件……用老版本呗。去年还帮人验收了一个 CentOS 6 + Java 6 + Tomcat 6 的 666 项目。主要是很多地方性、行业性的信息化小公司对 infrastructure 的更新不当回事，而没有技术力量的甲方单位则毫无概念，从来不会提要求。

警告往往是隐患。

过公网的大量数据传输，只建议针对具体业务场景做整体方案设计（至少包含网络拓扑等基础设施建设），而不是纠结传输协议的比较。

仿佛穿越回 20 年前

@adoal 喷完之后再正经说一下，架构设计能力是 [全局] 性地解决 [复杂问题] 并形成 [积累] 的能力。

经典的 Plug and Play Monitor 插头和播放监视器
（咋不翻译成插入和玩弄班长）

很多架构师都是夹狗屎

“不要相信 walk in 直接秒开，人很多，预约减少排队时间”……你以为是不想预约吗？很多人没条件留足够的提前量安排好过港日程，只能 walk in 排队。

@ty29022 运维人表示 / 显然是路径分割符……话说回来，数学课本里除法写一行用除号 ÷ ，写多行用分数线，斜线并不是主流啊。

@FreedomUCK SPDIF 输出的是数字信号，由音箱做 DAC ，不受机箱里的电磁干扰影响

担心主板音频的模拟输出部分受干扰，可以试试 SPDIF 光纤输出到音箱。

当你的精力超过半数要花在原来预想的岗位职能外的时候，就该想办法当管理角色了。

这卡还有个神奇的用法，通过 apple pay 给云闪付里添加的信用卡还款。招行的信用卡当期账单满 2000 就可以用。

@ilvsxk 对于写这段业务代码的单个程序员以及这个具体项目来说是如此。但是如果公司在行业有足够的底蕴，做的项目多，以及有真正的技术功底好又能把握业务的架构师，那么应该针对每个项目里都会出现的类似场景做抽象设计，做成库或者框架，甚至用流程引擎、DSL ，解耦易变的业务规则和不易变的基础代码。就像 #172 说的，重构的目的并不是直接的“让代码量更少”，这里我补充的是，通过这种逻辑抽象的重构，单个项目里的代码量可能反而增加很多，但是提炼出的公用代码可以作为基础设施重用到不同项目，这样写业务逻辑的人就可以更多把精力集中到业务逻辑代码的编写和质量控制，而不是在跟混杂着业务逻辑和底层功能的几百几千个分支的条件语句搏斗。