代码组织与调试

7.4 代码组织与调试

止血做完，这节谈病房制度：几百行交互代码散在页面各处，半年后没人说得清哪段管哪块——组织解决"放哪里、怎么分"，调试解决"坏了怎么找"。本节给出 jQuery 项目最常用的组织模式与一套固定的排查流程；调试图谱自然衔接 7.3 的错误清单——那边按症状列病因，这边给排查动作。

本节摘要：组织上用"模块即区域"的立即执行函数模式：每个功能域一个自包含模块，显式依赖、统一入口、事件命名空间隔离；调试上按"复现—定位—验证—收尾"四步走，善用断点、集合检查与事件检查，把玄学故障变成可陈述的因果。

模块即区域：页面代码的组织单元

反面教材是历史项目最常见的形态：几百行代码平铺在 ready 里，选择器字符串散落各处，改一处要在全文里找同类。jQuery 项目的轻量组织法是按功能域切模块，每个模块一个立即执行函数：

// 模块一：队列管理
(function ($) {
  var $queue = $('#queue');                       // 私有：模块内共享

  function bindEvents() {
    $queue.on('click.row', '.item', toggleDone);  // 命名空间登记，方便整体拆线
  }
  function toggleDone() { $(this).toggleClass('done'); }
  function refresh() { $('#queue').load('fragments/queue.html'); }

  $(function () { bindEvents(); });               // 模块自己的开机检查
})(jQuery);

// 模块二：登记表单
(function ($) {
  $('#register').on('submit', function (e) { e.preventDefault(); });
})(jQuery);
​

三条纪律让它能撑住中型页面。其一，查询结果模块内缓存（性能止血点一的模块化版本）；其二，事件带命名空间（4.1 的机制在组织层的价值：模块卸载或重初始化时 off('.row') 一拆到底，不留悬线）；其三，模块间通信显式化——需要跨模块调用就把个别函数挂到明确命名的对象上，而不是靠全局变量暗中传递。更大的项目（构建工具与模块系统就位后）这套思维原样迁移成一个个源文件。

调试四步：复现、定位、验证、收尾

面对"没反应""反应怪"类故障，固定流程比灵感可靠。

第一步复现：找到最小触发路径。能一次点击复现的不要靠刷新碰运气；时好时坏的优先怀疑时序（ready 前绑定、异步竞态）。

第二步定位：断点打在嫌疑处理器第一行，确认信号到没到——

$('#queue').on('click', '.item', function (event) {
  debugger;                       // 断在这里，看三件事
  console.log(this, event.target, $(this).length);
});
​

到都没到，问题在绑定层：多半是 7.3 清单里的断线或重复绑定。到了但行为不对，问题在处理层。

第三步验证：在断点里逐段验证假设。集合对不对看 length；对象是谁看 instanceof；属性账与特性账分别在面板里展开看（3.2 的三本账在调试器里可见可改）。改属性不必改代码——断点现场直接改完放行，假设立刻验证。

第四步收尾：把修复固化成代码而不是断点补丁，并把根因记进注释或缺陷单——四步里最值钱的输出是"这次为什么坏"的因果陈述，下一位接手者靠它省一次完整排查。

两类高频故障的现场图谱

把本册出现过的故障按章节索引收拢成排查地图，查房时按图索骥：

用这张表时注意方向：先按症状锁定候选病因，再回到对应章节的机制复述里验证——调试的本质是把"不知道为什么"翻译成"哪一环的哪条规则被违反了"，而规则全部写在前面六章。

与原生工具的衔接

调试手段在原生世界同样成立，且现代开发工具对两边一视同仁：元素面板能直接看到每个节点上挂了哪些监听器（查重复绑定时比任何脚本都直观），断点、监视、调用栈对 jQuery 回调照常工作。组织层面，jQuery 模块与原生模块的差别只在载体——立即执行函数换成 ES 模块文件，纪律三条一条不用改。换句话说，本节教的组织力与调试力都是可迁移资产，这正是下一节"迁移"主题的底气所在。

现场演练：一次完整的"点了没反应"排查

把四步流程放进一次真实故障里走全程。背景：标本页的候诊队列，点击条目应划线标记就诊完成，测试反馈"偶尔点了没反应，刷新后恢复"。

复现环节先收敛条件：连续快速点击必现，等几秒再点又正常——时序类特征，嫌疑落在重复初始化或异步竞态上。定位环节在处理器首行下断点，复现时断点命中了，但 $(this).length 显示为二——同一个处理器被绑了两遍，一次点击触发两次 toggle，等于点了又点，视觉上"没反应"。

验证环节往上游追：谁绑了两遍？在 bindEvents 入口打条件断点，发现模块初始化函数被 load 回调里的局部刷新又调了一次，旧监听没拆，新的叠上去。解读：根因是"局部刷新走整体重初始化，却没配对拆线"。修法二选一——要么初始化前 off('.row') 先拆再绑，要么把刷新改成只替换内容不重绑。这里选后者（委托绑定本来就为此而生），并把结论写进模块注释。变式：如果症状换成"每个条目点一次触发一次，但新加的条目点不动"，同一套流程会把你引向另一处——绑定发生在元素加入之前，答案换成委托。四步流程不变，变的是每一步收集到的证据。

给自己造两件调试小工具

排查 jQuery 故障时有几行代码值得常备。第一件，数监听器的探针：

// 快速核对某节点上挂了哪些监听（现代浏览器）
getEventListeners($('#queue')[0]);   // 控制台直接调用，列出事件名与处理器
​

第二件，模块内的重初始化哨兵：

var initCount = 0;
function init() {
  initCount++;
  if (initCount > 1) console.warn('init 被调用了', initCount, '次——检查刷新路径');
  // ...正常初始化
}
​

两件工具的共同思路：把"看不见的次数"变成"看得见的数字"。重复绑定、重复初始化这类故障的麻烦在于不报错，哨兵与探针补的正是这层感知。它们不必留在生产代码里——调试期挂上，验收后拆掉，或者像第二件那样留成无害的警告。

要点复盘

• 组织单元是功能域模块：立即执行函数包裹、查询缓存、命名空间事件、显式跨模块通信。
• 事件命名空间在组织层的价值是"整体拆线"，重初始化不留悬线。
• 调试四步固定走：复现找最小路径、定位看信号到没到、验证在断点现场改、收尾固化因果。
• 高频故障先查症状图谱，再回机制章节验证——把玄学翻译成违反了哪条规则。
• 组织与调试能力随人迁移，类库换成原生，纪律原样生效。

车间制度立好了。最后一节回答整个时代的问题：这套手艺哪些该带走、哪些该留下，迁移之路怎么走。