---
title: 唯快不破——快速编码实践
---

**必先正名 —— 何谓快**

在谈论快之前，有必要先讨论一下何谓快。我的定义是，快不是速度快，而是效率高。当然许多场景下，速度快了效率自然就高。“效率高”又有两个延伸问题需要定义：

* **做何事的效率？也即“快”的目标**，比如我要你2分钟洗5个梨，你说我洗10个苹果只需要1分钟，这种快跟目标不合就没用
* **为何要高效率？**

总结了一下半年多来的工作经验，我认为软件行业暂不讨论与人相关的因素下，技术工作需要具备三个能力：基础能力、快速构建能力、工程能力。这三项不在本文仔细展开，其中快速构建能力是指就一个项目需求或实际的工具需求，能使用已有知识和工具快速搭建出可工作的原型的能力。本文的快，（可能狭义地）认为是这种 快速适应项目或搭建应用 的快。

为何要高效率。为节省出时间和脑力，以获得学习更多东西的机会。像挣更多钱这种大~~俗~~实话这里就不说了，好歹也是一枚文艺青年不是……【捂脸】

## 快速编码笔记

要在已有项目上完成添加或修改工作，不同的人可能有不同的方式。这里说说上了项目后学到的一点，即是采用 **直接定位修改点** 的方式。相比起了解整个系统的流程与工作原理，它更快，也更直接，是短平快的工作方式，有其学习的价值。对系统从头到尾的架构和细节了解，是课外的功夫，也有经验和积累，属于程序员的自我修养。因为我自己是~~处女座~~对原理更感兴趣的性格，在面对问题的时候会想先探究是如何实现的，有时就会阻碍学习或者解决问题的进度。这种不问为什么的理念，我觉得是个很好的补充。

## 快速解决问题小笔记

总结起来，在 **不问为什么，直接定位出错/修改地点** 的理念下，产生了一些直接但有效的实践，与我所见闻有很大关联，仅是学习笔记和抛砖引玉。这部分欢迎各种补充：linesh.simpcity@gmail.com。

1. **看日志/控制台的输出信息，直接定位到问题发生的地点(controller, js, html element, etc...)**  
  如果不知道日志的位置，可以观察项目的目录结构，或者跟踪Logger代码中的路径

2. **GDT-Google Developer Tools的元素查看(Inspect elements)**  
  可以通过id或class等特性有针对性地找到特定的元素，并借此搜寻作用于其上的绑定(比如jQuery、css等)

3. **查看类或接口的所有实现(Command+Option+B in Intellij)**  
  这里也是只能靠猜测的地方.但凡接口的实现必然有注入的地方，但在注入点到我们的调试点中间链可能很长，这样，只能通过找寻接口所有可能的实现，根据项目的实际情况，猜测_**注入发生的地点**_和_**被注入的实际类型**_，直接找到注入类，忽略中间过程。

  **深入思考：**

  接口提炼意味着所有可能被注入的对象存在着逻辑上（软件架构上，而非字面上）的联系。这里的实现，可能是指类或接口，也可能是字符串，其他类型的东西。实际的注入方式可能有以下几种：
  * **字符串拼接**。这种情况说明待拼接串具有字面上的相似性（通常也反映了逻辑上的相似性），只是简单的文本填充。但其本身作为解耦的字串，可能暗示了其更高层使用者之间存在的逻辑联系。

  * **反射**。我的毕设专题。它不同于手动声明对象的方式，它把“声明对象（包含为其申请内存，构建一个对象的过程）”这个动作从语言层面再次解耦出去。

  * **混合使用**。其实这两种方式在Java中是以某种联系紧密连接的。字符串是反射特性使用的解耦符。它实现解耦的目的达到，在反射技术整个发展路上来看，这个技术的使用也是利大于弊的，但它也是有缺点的。抛开性能缺陷不说，它实现解耦的方式是把应用层的问题下放到语言层（虚拟机层），这样语言层面的代码可读性就消失了，你调试的难度就要增加。

4. **spring mvc的RequestMapping注解找映射路径**

5. **通过服务器(Tomcat, Jetty等)的配置文件找访问路径**  
  只要路径不是自动生成，最终都是组织到配置文件来解决的节奏。

6. **观察依赖管理工具的配置文件来看其引入的依赖**  
  项目常用的管理工具有：
  * 前端开发工具依赖管理npm(package.json)
  * 前端开发库依赖管理bower(.bowerrc, bower.json)
  * 前端任务构建管理grunt(gruntfile.js)
  * 后端依赖管理maven(pom.xml)
  * 后端任务构建管理gradle等。

7. **CVS日志找某个特性的开发人**

8. **Intellij的全文搜索**
  全文搜索其实还是有一些技巧，根据前面采集到的一些有标志性的信息来进行搜索，今天看到子建还可以用`>Policy Holders<`这样的方式来搜索一个HTML标签等。多观察多学习。

9. **网上资源库，一些可能有集中的相关context的人分享的平台，比如confluence**

10. **前端UI/JavaScript相关可以在控制台Google Developer Tools中直接像素级调整/观察资源加载/调试等**
  前端是个有趣且发挥想象力的地方，页面上的东西都是所见即所得，工作方式比较粗暴，要什么样式先直接在GDT里面调，像素级别地加减。

## 慢即是快

那么最后，与直接定位到问题所在的思维/解决方式不同的另外一种方式，是直接走通整个流程。这种方式通常更为可视化，理解更为透彻，也更花时间。但在尝试了所有能快速解决的方式仍不能成功的情况下，不能说这种方式就是慢。意在解决问题，而困难问题的解决，偏是需要耐心和智慧的。棋道术语曰“后中先”。常用的方法有：

1. **经典的debug功能**

2. **直接把整个程序跑起来**  
  比如在做Java反射的时候，最为直观的方式就是把虚拟机build起来。

## 查找一切 Google Everything 
好的，如果上面的方法依然不足以找到你需要的东西怎么办呢？把上面搜到的东西作为关键词，再采用其他的方式（如google）来进行链式搜索。Google乃是泛指，只要能搜到，管你是用什么工具（谢谢AlphaGo狗哥）。唯快不破，粗暴之美。

## 总结与反省 Conclusion

其实在快这个问题上，不妨认为“快”也只是其中的一种方式，不应拘束在术中，发现了好的方法能够提高效率，都该使用。另外，对为什么“快”的认知在学习的过程很重要，需要认清所需。不是一味追求快，以至对有时停步的思考都感到焦急。

本篇侧重在技术的编码上，在其他方面还有很多习惯可以使我们的工作变得更快，比如：

* 提高手速
* 熟悉快捷键
* 善用英文和搜索引擎
* 使用markdown写作
* 专注时间
* 趁手的编辑器（sublime/vim/emacs等）/软件（Alfred/……没了）等

对于工具这个专题，我 [自己也在写一些总结，托管在Gitbook上](https://www.gitbook.com/book/linesh/gitbook-elegant-mac-tools-system-closure/details)，尚未写完持续更新中，有兴趣的读者可以过来参阅。