阅读.NET源代码那些事
这篇讲的是如何通过直接阅读.NET框架源代码，来深入理解其内部实现机制。作者以自己在项目“Tmc”中借鉴BCL代码的经历为例，指出虽然.NET大部分组件不开源，但微软已公开了参考源代码库，并保持与版本的同步更新。 文章重点对比了反编译工具（如.NET Reflector）与直接阅读源代码的差异。作者指出，反编译会丢失变量名、注释等关键信息，而源代码中保留的详细注释，例如Hashtable实现中关于哈希算法选择的说明，更能清晰揭示设计思路和实现背景。 作者还通过Dictionary类的代码实例，揭示了一个巧妙的实现细节：在特定编译条件下，当插入操作的哈希碰撞次数超过阈值，Dictionary会随机化其比较器。这一机制正是为了应对曾引发安全关注的哈希碰撞DoS攻击，展现了框架在安全与性能上的权衡。 最终，作者将这些源于阅读源代码的经验应用到自己的项目中，通过参考和修改BCL代码来构建自定义的HashDictionary，证明了这种方法在提升代码质量与理解深度上的直接价值。
讨论：一则并行聚合计算方案的设计
这篇讲的是作者在构建一个实时数据看板时遇到的并行聚合计算难题。场景很具体：一个最多10万元素的数据集，每秒会收到数百到数千次字段修改（远多于增删操作），系统需要实时计算并维护多达50条聚合规则（如求和、平均、加权平均）在最多5层分组下的完整结果树。所有数据都在内存中，要求能立刻响应任何滚动查看。 作者首先实现了一个高效的串行方案：让聚合器监听集合变动，利用更新前后的值进行差值计算，避免全量重算。但面对更高的性能需求，他开始探索并行化。简单的“每次变动后并行计算”不可行，会导致持续高负载和并发错误。他尝试借鉴Erlang的Actor模型，将每个聚合器独立为消息驱动单元，但随之带来了新问题：在传递元素属性更新消息时，是否需要携带整个元素“快照”？直接携带开销太大，不携带则可能因并发修改导致聚合计算拿到中间状态的数据。作者发现，或许只有分组字段变更时才需要快照，这大幅降低了开销。 文章详细剖析了一个从串行到并行演进中的经典权衡：如何在保证实时性的同时，平衡计算延迟、系统负载与数据一致性。作者不仅给出了清晰的问题定义，更分享了思考路径与初步尝试，为面临类似挑战的读者提供了宝贵的讨论起点。
尾递归与Continuation
这篇文章从一个常见的编程痛点——递归深度受限——出发，引出了两个紧密相关又层次不同的概念：尾递归与 Continuation。作者清晰地解释道，尾递归本质上是一种针对特定代码模式的编译器优化，它能将递归调用在尾部位置时转化为循环，从而避免栈溢出，常用于函数式编程语言中处理深层递归。但其优化范围仅限于尾调用位置，控制流的延续仍然是隐式的。 文章更核心的部分在于探讨 Continuation。通过 CPS（Continuation-Passing Style）转换，作者展示了如何将“程序接下来要做什么”这个隐含的控制流，显式地表示为一个可传递、可存储的“一等对象”。Continuation 能统一表达顺序执行、循环、异常甚至跳转，它将控制权交给了程序员。 两者的根本差异随之浮现：尾递归是对线性控制流的一种实现层优化，而 Continuation 则是对程序控制流本身进行建模的一种强大语言原语。文章用具体的代码示例对比了它们的表达能力，最终让读者理解，Continuation 提供了一种更根本、更灵活的控制流操控视角。这对于理解程序如何“执行”、如何管理流程至关重要。
尾递归对时间与空间复杂度的影响
这篇讲的是尾递归在实际应用中那些理论之外的复杂性。文章从一位同学的提问出发：是否所有递归算法都能改写为尾递归？改写后，时间和空间复杂度就一定能得到优化吗？以斐波那契数列为例，表面上似乎验证了这一结论。 作者深入剖析后发现，事情并非如此简单。虽然尾递归确实能通过消除调用栈来优化空间复杂度，但其对时间复杂度的提升是有条件的。文章具体展示了，即使将斐波那契递归改写为尾递归形式（借助累加器参数），若仅仅进行机械转换，得到的依然是一个时间复杂度为 O(2^n) 的低效算法，需要进一步结合动态规划思想才能优化到 O(n)。 文章进而探讨了将一般递归转换为尾递归或迭代的通用方法，分析了转换过程中可能遇到的困难与权衡。结论是，尾递归是一个强大的性能优化工具，但它不是将递归问题转化为高效迭代代码的“万能钥匙”。理解其原理与局限，才能在合适的场景下有效运用它。
C#的设计缺陷（2）：不能以void作为泛型参数
这篇文章从C#与Java泛型的对比切入，探讨了C#作为“真泛型”语言在语言设计层面的另一项限制：不允许将void作为泛型类型参数。作者指出，.NET的真泛型本是一大优势，但具体到C#编译器的实现与运行时约束，却衍生出这一设计缺口。 文章并未深入剖析其技术成因，而是将C#视为一个既成“产品”，着重分析了这一限制所带来的实际编程后果。它揭示了在试图用泛型统一处理值类型与引用类型（包括表示“无返回值”的void）时，开发者可能遇到的设计困境与代码冗余。 对于关注语言设计权衡与.NET生态实际特性的开发者而言，这提供了一个理解C#泛型边界与当前编程模型局限性的具体案例。
C#的设计缺陷（1）：显式实现接口内的事件
这篇讲的是C#语言里一个长期存在的“遗憾设计”：当我们试图在一个类中显式实现接口定义的事件时，编译器会强制要求我们手动提供add和remove访问器的完整实现。 这打破了C#事件最常用的、便捷的`event`自动实现模式。作者从自己多年的编码体验出发，指出这种限制虽然无伤大雅，却显得多余，因为它并没有带来任何实质性的安全或功能增益，反而徒增了繁琐的样板代码。这种“细枝末节”的设计决策，也侧面反映了语言在演进过程中，某些早期设定可能成为后续难以改变的“路径依赖”。
Jscex与Promise/A那些事
这篇讲的是Jscex在异步编程模型统一上的策略，以及它与Promise/A的对比。作者从异步库的核心需求切入，指出任何异步类库首先需要统一模型，Jscex的异步模块借鉴了.NET的异步任务模型，并提供了whenAll、whenAny等增强功能，方便开发者处理并发操作。 当需要混用不同异步模型时，Jscex通过fromCallback和fromStandard等辅助工具，轻松适配Node.js中常见的回调式接口，将简单函数绑定为任务。这展示了Jscex在兼容性上的灵活性。 对于Promise/A——一种广泛使用的异步模型，文章强调Jscex的支持方式不同，更为直接。Promise/A以其链式调用和错误处理机制著称，Jscex没有采用适配层，而是集成了原生支持，让开发者能更无缝地结合两种模型。 整体上，文章对比了Jscex的原生任务模型和Promise/A，分析了它们的关键差异：Jscex提供了更丰富的扩展和适配工具，适合需要深度定制异步流程的场景；而Promise/A的标准化设计则更便于跨平台协作。通过这种对比，帮助读者理解不同异步方案的设计哲学，在选择技术栈时做出更合适的决策。
谈谈年度最佳代码“不管你们信不信，反正我信了”
这篇文章从一段在网络上广泛传播的代码入手，其灵感源于前铁道部发言人王勇平的一句经典名言：“不管你们信不信，反正我信了……这是生命的奇迹……它就是发生了”。尽管这段代码带有明显的调侃和幽默色彩，但它在技术圈内引发了一场关于代码风格和编程规范的实质性讨论。作者详细记录了这些讨论，深入探讨了代码的可读性、
由eval生成的代码效率真的很差吗？
这篇讲的是作者从一次技术争论出发，深入探讨了eval生成的代码效率问题。争论的另一方是Node.js专家，他认为eval存在性能缺陷，开发时应当避免使用，并举例CoffeeScript采用额外进程监听改变的做法更优。作者则指出，Wind.js借助eval实现运行时动态转化，且生产环境中不会出现eval，而CoffeeScript是在构建时处理。争论的核心在于eval是否真的效率低下，甚至影响到开发实践。 为了验证这一点，作者设计了实验来量化eval生成代码的性能表现。对比对象主要是eval与其他编译或转化方式的代码效率。关键差异在于eval在运行时进行动态代码生成，可能带来额外开销，而像CoffeeScript这样的工具在构建阶段完成转化，避免了运行时开销。各自适合的场景也不同：eval适合需要高度动态性的场景，而预编译更适合性能敏感的生产环境。 通过试验，作者试图揭示eval效率的真实情况，而不是仅凭经验论断。文章不仅回顾了Wind.js和Jscex的历史背景，还聚焦于性能对比的实证分析。这为开发者提供了客观数据，帮助他们在选择技术方案时权衡动态灵活性与执行效率，而不是一味避开eval。
我对“语言之争”的看法：别随便拉我入场
这篇文章从近期围绕C++复杂度的新一轮“语言之争”切入，探讨了一个老话题却常被忽视的侧面。作者并未纠缠于技术细节的优劣辩论，而是借酷壳上一位同行对C++“又爱又恨”的感叹，折射出自己的核心感受：这场争论早已偏离了技术理性的探讨，沦为太多“不合格的人”宣泄情绪、滥用和凌辱语言本身的名利场。 作者指出，许多人对技术的“爱”与“恨”往往源于自身的认知局限或偏见，而非语言客观的能力边界。这种个人化的体验被放大后，就形成了充满偏见与攻击的“语言之争”，反而遮蔽了技术讨论的真正价值。文章并非要评判C++或其他语言的对错，而是呼吁技术人看清这场“争执”背后的情绪化本质，保持独立思考，别轻易被裹挟进无意义的口水战中。它提醒我们，技术讨论应当回归解决问题本身，而非成为证明自己正确或攻击他人的工具。
我看面试时出（纯）算法题
作者读到左耳朵耗子关于反对纯算法面试题的新文章后，结合自身经验写下了回应。他认同面试不应只考察与实际工作脱节的纯算法题这一大方向，但也希望为这个讨论补上一些更细腻的视角。 文章首先温和地指出，原文对学术研究者的描述略有偏颇，但这不是重点。真正的核心在于，如何更准确地通过面试问题，来评估一个候选人在实际工程中解决问题的能力。作者认为，纯粹的算法题容易忽略工程实践中的权衡、沟通与协作，而一个更有效的面试环节，或许应当模拟真实场景，考察候选人分析需求、拆解问题、并在约束条件下做出合理技术选择的能力。 这篇短文像是一个冷静的“补丁”，将一场热门的技术讨论引向了更具体的实践层面，提醒我们在设计面试时，别忘了技术能力最终是为解决真实业务问题服务的。
受禁锢的异步编程思维
这篇讲的是，作者在力推Jscex（一个JavaScript异步编程工具）的过程中，敏锐地观察到一个思维定式的问题。 许多JS开发者已经深陷在传统的回调、Promise等异步模式中，甚至将其视为一种“美”。但作者从GoF设计模式修补OO语言不足的角度类比指出，当前这些流行的异步模式，本质上是由于JavaScript语言本身（在早期版本中）缺乏原生的、优雅的异步处理能力，而被迫设计出来的“权宜之计”。在别无选择的环境下，人们会将习惯误认为美。 文章的核心观点并非否定现有模式的价值，而是呼吁一种思维的解放：当语言特性（如通过Jscex）已经提供了更简洁、更符合直觉的解决方案时，我们不应再被旧有的、为弥补缺陷而生的复杂范式所禁锢。它促使开发者反思，我们所推崇的“最佳实践”，究竟是真正的优雅，还是仅仅是对工具局限性的妥协与适应。
Node.js中相同模块是否会被加载多次？
这篇讲的是Node.js模块加载机制中一个容易被忽略的细节：当你用require()引入同一个模块时，它真的会重复执行代码吗？作者从require函数的执行流程切入，逐步拆解了模块缓存机制的工作原理。 文章首先澄清了一个常见误区——Node.js其实内置了缓存机制。首次require时，模块代码会被执行，其导出结果会被存入一个缓存对象；后续再require同一模块时，会直接返回缓存内容而不会重复执行。作者通过示例代码演示了这一过程，验证了模块内的全局变量状态确实会被保留。 更值得细看的是对循环依赖的处理。当模块A和B互相引用时，Node.js并不会陷入死循环，而是返回一个尚未完成的“半成品”exports对象。文章用流程图梳理了这个微妙的加载顺序，解释了为什么某些变量在此时可能还是undefined。 最后，作者还提到了开发者可以利用require.cache手动操作缓存，比如在开发时热更新模块。不过也提醒了直接修改缓存可能带来的风险。整篇文章把看似简单的require()背后的完整逻辑讲透了，从原理到实践都有覆盖。
匿名类型的硬伤：围绕this的成员捕获策略
这篇讲的是C#程序员常憧憬的Java式匿名类特性，但作者在深究Java语言规范后，却发现了其中围绕 `this` 的成员捕获策略存在难以回避的“硬伤”。这并非关乎设计品位，而是一个根本性的实现难题。 文章的核心对比在于，Java的匿名类（作为内部类的一种）在捕获外部成员时，必须隐式或显式地通过一个外部类引用来访问 `this`。这导致了代码意图与实际执行之间的微妙错位：你在匿名类里写的 `this` 指向的是匿名类自身，而要访问外部成员则需要借助外部类实例。相比之下，C#的lambda表达式捕获的是变量副本或引用，其行为更直接、一致。 作者从实际编码体验出发，剖析了这种差异带来的后果。Java的这种方式可能导致非预期的内存持有和更复杂的生命周期问题，使得某些场景下的代码既不直观也不安全。最终的结论颇具启发性：一个语言特性的引入，不能只看表面的便捷，其底层对核心概念（如 `this`）的处理方式，才决定了它是否是一个“干净”的设计。如果C#无法用更优雅的方式解决这个捕获策略，那么保持现状反而是更负责任的选择。
匿名类型的硬伤：围绕this的成员捕获策略
这篇讲的是一个关于编程语言特性的深层观察。作者从C#程序员对Java匿名类特性的向往谈起，但随后话锋一转，带我们深入Java语言规范，揭示了其中关于`this`引用的一个根本性矛盾。 文章的核心观点犀利：Java匿名类（及内部类）中的`this`关键字，其作用域被“向外”指到了外部类的实例上，而非匿名类自身。这种设计会导致作用域混淆和意外的成员捕获行为，作者称之为难以避免的“硬伤”。相比之下，C#通过匿名类型与lambda表达式结合，其捕获局部变量形成闭包的策略则清晰得多，变量归属一目了然。 通过这个具体的`this`捕获问题，文章揭示了语言特性设计中一个重要的权衡：便捷性与可预测性之间的取舍。它让读者意识到，一些看似“缺失”的语法糖，背后可能隐藏着避免更深复杂性的深思熟虑。理解这一点，或许能让我们对所用语言的特性选择有更清醒的认识。
IBM面试记
这篇讲的是作者一次久违的正式面试经历。作者回顾了从微软实习、加入创业公司到被盛大创新院招聘的过往，指出自己经历的“非典型”求职路径：面试较少，更多依赖推荐或内部沟通。正因如此，面对“正经渠道”时，他对自身竞争力产生了些许不确定。 这次IBM的面试，对他而言更像是一次“补考”，旨在重新检验在传统且严谨的招聘流程下的应对能力。文章记录了他从最初的一丝忐忑，到逐步适应并享受整个深度交流过程的心路变化。对他而言，这不仅仅是争取一个职位，更像是一次职业能力的“校准”和心态上的“健身”。 文章的核心并不在于分享面试题库或具体技术点，而是透过个人视角，呈现了一位技术人在职业过渡期，主动选择走进传统大厂面试场，进行自我评估与重塑的经历。这种对自身舒适区的主动突破，以及在标准化流程中重新定位的思考，或许能给同样面临职业转换或自我怀疑的技术同行带来一些共鸣与启发。
JavaScript：假如default不是switch的最后一项
这篇讲的是JavaScript中一个很少被深究但可能让人困惑的细节：当`switch`语句的`default`分支出现在中间而非末尾时，执行流程会如何变化。作者从一个简单的代码示例出发，揭示了即使`default`内部没有`break`，在JavaScript中程序依然会继续向下执行后续`case`的代码，产生一连串意想不到的“穿透”执行。这与许多程序员习惯的C#等语言的行为（要求明确`break`或控制流）形成了鲜明对比。 文章的核心在于展示JavaScript作为一门灵活（有时甚至是“宽松”）的语言，在流程控制上保留的这种底层特性。这种设计虽然带来了自由度，但也极易在维护时引发隐蔽的逻辑错误。通过这个小知识点的剖析，文章提醒开发者注意语言细节的差异，在编写或阅读跨语言代码时保持一份清醒。理解这种机制，能帮助开发者避免一些典型的陷阱。
使用Jscex实现排序算法动画
用动画演示排序算法直观又有趣，但原生JavaScript的单线程特性让实现“每一步暂停”的效果变得繁琐——通常需要依赖`setTimeout`进行回调，把连续的逻辑拆散。这篇文章展示了一种更优雅的方案。 作者从“让排序过程可视化”这个常见需求出发，点明了用JS实现动画的痛点。核心思路是借助Jscex这个异步流程库，将原本需要回调的代码，改写成包含`sleep`异步调用的顺序写法。这样一来，绘制一帧后调用`sleep`，程序便会“暂停”指定时间，等待下一次循环，逻辑清晰且易于维护。 文章没有停留在理论层面，而是提供了可直接运行的代码示例。这种“用暂停来控制节奏”的技巧，不仅适用于排序动画，对于任何需要分步演示或加入延时的前端交互流程都有启发。
UglifyJS有个不错的JavaScript解析器
为项目挑选合适的工具是常态，而本文记录的正是作者为异步JavaScript编译器Jscex寻找更优解析器的经历。作者此前使用的Narcissus解析器因依赖SpiderMonkey扩展，无法在IE8等仅支持ECMAScript 3的浏览器中运行，其输出的AST结构也存在不理想之处。 在评估了NarrativeJS内置的旧版解析器并发现其功能缺陷后，作者转向了UglifyJS。通过实际使用，他发现UglifyJS内置的解析器不仅完全符合标准，性能上也显著优于Narcissus，从而顺利解决了兼容性、功能与性能的多重需求。 这篇分享不仅是一个具体的工具替换案例，更展示了一个实用的工具选择思路：当现有方案成为瓶颈时，跳出原有框架去探索（如从压缩工具中寻找解析器），往往能收获意想不到的解决方案。
使用Google Closure Compiler全力压缩代码
这篇文章的核心观点是：UglifyJS 比 Google Closure Compiler 更“聪明”。作者通过对比几款主流 JavaScript 压缩工具，指出 UglifyJS 之所以能取代 Closure Compiler 成为 jQuery 项目的压缩工具，关键在于其更优的压缩策略。 作者用实测数据支撑了这一看法：对 jQuery 1.5.2 的核心代码，UglifyJS 压缩后体积减少了 62.5%，而 Closure Compiler 的“简单”优化模式仅减少了 57.53%。更值得注意的是，作者区分了 Closure Compiler 的“简单”与“高级”优化模式——后者为了极致的压缩效果，会采取近乎“破坏”代码的激进手段，是一把需要谨慎使用的双刃剑。 因此，文章并非单纯推崇某一款工具，而是在为开发者提供选择参考：若追求安全且高效的压缩，UglifyJS 目前的表现更胜一筹；若确实需要极致压缩并愿意承担配置风险，Closure Compiler 的高级模式依然有其用武之地。