大家都知道编程很复杂，工作流程包含需求分析、架构设计、代码实现、测试发布等。每一步又都包含了很多学问，比如架构设计要考虑正确性、扩展性、安全、性能等，如果是分布式系统则还要考虑伸缩性、健壮性等等。这样大的一个主题，那本文为什么说编程是一件小事呢？因为要想一下说清楚一个学科是不可能的，大的方面我们暂且不提。凡事都是从一点一滴做起来的，本文就说说编程中最最微小的细节。只谈谈编程中最小的三个方面：编辑、排版、命名。从中我们能窥见，编程作为一门手艺是需要多么耐心和细心。只有不断地打磨自己的技艺和工具才能成为一个合格的程序员。“天下大事，必做于细”，就是这个道理。
1.指尖上的舞蹈
虽然编程很高大上，但千里之行始于足下。代码毕竟与写作有类似的地方，都是精心构思后一行一行敲出来的。所以，最细小却也最重要的一件事就是学好一款编辑器，长期使用它，从中受益。高手之间过招，不用太多花哨的招式，从最细小的地方就能看出差距。以前出差遇见过一位同事，第一次见时没什么引起注意的，几个月后见发现他的很多操作都脱离了鼠标，不止在IDE中，他还熟练地用快捷键在浏览器和开发环境之间切换，看得出他在努力学习，让自己进步。当然这里并没有否定鼠标的意思，鼠标绝对是一个伟大的发明，从虚拟投影到现实，让更多人用一种可以快速接受的方式进入计算机的世界。但对于程序员来说，鼠标可能真的是一个能少用则少用的设备。
每个IDE都有自己的快捷键和高效的用法，这里没法罗列，本文也无意做成一本查阅手册。但这里着重提一下Vim，因为笔者多年来逐渐地，不管使用哪一种IDE或编辑器，都会不由自主地去查一下是否有Vim插件。从Intellij IDEA、Sublime、Visual Studio Code，如此钟爱就是因为Vim实在是太强大、太好用了。不管本体提供了怎样的独有快捷键，Vim都可以作为一个纯插件提供可能是最高速的编辑。虽然Vim——历经时间考验的编辑神器，但比较让人诟病的一点就是学习曲线高。可一旦熟悉了它的基本用法甚至能灵活使用后，代码编辑简直是心情愉悦。强烈推荐各位阅读《Vim终极指南：所思即所得》，或原书《Practical Vim: Edit Text at the Speed of Thought》。
2.排版的艺术
Rob大叔经典的《Clean Code》中从视觉效果方面，提到了如何排版能让自己的代码更“干净”，更易于他人的阅读和理解。就像传统的印刷行业一样，我们像排版一份报纸一样排版自己的代码。将“标题、摘要、内容”都放在合适的位置上，突出重点同时也罗列细节，让读者身心愉悦地阅读自己的代码，作为作者也是一件幸事。
2.1 长度
《Clean Code》中坚信的一点就是：短小的类和方法。书中列举了开源软件代码行数的统计数据，Tomcat和Ant比较像我们的日常项目，个别文件几千行，大部分文件都几百行。然后JUnit、FitNesse、TimeAndMonkey（没听说过）几个“敏捷类”的项目的大部分文件都少于200行，没有任何一个文件的长度超过500行。而且这些项目也不小，像FitNesse的总代码行数也达到了50000行左右。虽然这无法说明JUnit、FitNesse的代码由于比较短小，所以比Tomcat和Ant的代码质量更高。但是这至少说明：一堆“短小精悍”的小文件是可以支撑起一个大项目的代码库的。实践上可行，同时如果你也坚信小文件、小类、小方法更易于理解的话，那么就身体力行地去实践吧，让实践和时间来检验你的代码和方法论。
2.2 垂直排版
报纸的排版是一个很好的比喻：标题告诉你故事是关于什么的，好让你来决定是否继续读下去。然后，第一段讲述整体上的故事梗概，所以具体的细节都避而不谈，逐一在后面的段落里列举。随着你不断往后读下去，你了解了所有的诸如时间、地点、人物、事件经过等细枝末节。
我们想让我们笔下的代码也像一份精妙构思的报纸一样，所以我们通常用空行（垂直间距）来分隔一块代码。这块多行组成的代码可能是一个方法、一组类成员变量、或方法里的几行代码，总之它们代表了逻辑上的一个概念和想法，通过合理的组织间距使读者更易于理解。同样的，对于多个这样的逻辑块，我们会尽可能地把它们组织在一起，并使每一句更尽可能简洁（垂直密度），让读者一眼就能看出个究竟。比如自上而下地排列依赖的方法或函数，方法内则使局部变量尽可能贴近使用它们的位置。总而言之就是一句话：用空行分隔不相关的概念，并让相关的概念离得尽可能地近，通过排列顺序、调整位置等。
2.3 水平排版
水平的排版比较容易一些，但与垂直排版类似，也要注意同样的两点：该远则远，该近则近。技巧就是用好缩进和空格，同时每一行不要太长。传统的观点是不要超过80个字符，在显示器格外宽的今天看来有些苛刻，但也绝不要根据显示器的宽度把每行都写的很长。其实即便完全遵照传统的80个字符，我们也没有浪费资源。笔者个人就比较喜欢分隔屏幕，经常比对代码，同时需要在小终端窗口编辑或查看代码时，也会非常方便。
3.起名字的学问
“命名和缓存是计算机科学里最难的两件事。”程序员无时无刻不处于给某样东西起名字的处境之中，变量、函数、类、文件…… 偷点懒的话可能就会大大降低代码的可读性，认真投入其中就会发现这真是个难题。来回改来改去是常态，千万不要觉得这是一种时间和精力上的浪费。当你左右为难、耗尽脑力时，才说明你真的在乎你的代码。思考了一小会就草草地决定了，可能是因为你不在意。
起名字的学问里，包括了起有意义的名字、区分动词和名词、单数和复数等。当然还有很多其他的规则，但最令人印象深刻的就是很久以前在《Code Complete》中读到的：作用域的范围决定了名字的“具体”程度。比如只在一个循环中存在的循环变量，按照惯例我们会用i、j、k等。而在一个函数中存在的局部变量，我们可能会取具体一些的，比如sum、result等。而对于在整个文件甚至项目中都能访问的类名，我们则会注意与项目中其他的类名区分，尽可能具体但又不至于过长。
但即便遵循所有这些最佳实践，不同的人可能也会起出不一样的名字。毕竟同样的意思有很多相近的单词，比如get、fetch、query，以及set、save等。这时如果有一份在整个项目组内共用的词汇表，那就相当有用了。例如规定大家统一使用get和set，订单统一叫order而不是purchase。在领域驱动设计（DDD）中也有类似的实践，统一组内所有人的用语。