什么是“方法论”？
导言： ……
Image （题图来自网络）
1
人到了一定年纪，习惯偏好总会相应改变，开始喜欢怅然怀旧，开始喜欢指指点点，开始自以为是。往前翻了翻自己写过的东西，好像确实如此，天道恢恢，我也应了自然规律。
年轻时喜欢琢磨技术细节和工具，是具体的术，是具象的器；年纪大了，牙口日渐衰退，啃不动太硬核的，只好捡一些总也不会说错的东西，侃侃而谈，是抽象的道；美其名曰“形而下者谓之器，形而上者谓之道”。
道是什么，似乎谁都说不清，但都知道是高级玩意儿，大概包含世界观、方法论之类。不再扯远，今天只说说方法论。反正怎么论都有理，怎么不靠谱，也都不会犯错。
2
程序员通常都不喜欢写文档，包括注释。我也一样。能用代码清晰表示的，干嘛要再用自然语言写一遍？
什么？应该先写文档，再写代码？文档又不能运行，干嘛不直接写代码？
再说了，以后改了代码，还要再改一遍文档，谁有那闲工夫？不改不改，文档爱看不看。反正肯定没人看。
后来，天降“敏捷”大法，听说可以不写文档？这么好，赶紧学起来，赶紧用起来。然后，就没有然后了。
3
然而，还真是有几类文档，是程序员不得不写的，甚至有时候还乐此不疲地写的。比如接口定义文档，再比如代码风格规范要求。这些文档能让程序员不至于费尽口舌，一遍遍向他人进行要求，写完一次，再有哪个菜鸟不按规矩来，就把文档砸过去，拍死他。
这类文档，并非代码的“复制品”，而是用来说明“如何写代码”的文档。它们很难用代码来直接描述，嗯，看起来自然语言表达还是很有用处的。
至此，“如何写代码”有了规定，这就是“方法论”。
4
由于是自然语言描述，当然，不出意外地，用不了多久，这些关于“如何写代码”的文档，就开始往五花八门、奇形怪状的方向疯狂生长了。这可苦了其他接触并被要求用到这些文档的程序员。
为了避免风格不一致，为了避免写出让人看着不舒服、难以理解、甚至发生歧义的内容，让我们来增加些约束吧。于是，“如何写‘如何写代码’的文档”的文档，也就诞生了。
这仍然是“方法论”，而且是更高级的方法论，更能体现“专业度”的方法论。一个团队、一家企业，是否规范，是否专业，是否接轨国际，全看是否能符合这“有文档”、“有文档的文档”、“有文档的文档的文档”等要求。
5
这样的层级“方法论”要求，的确提升了组织的稳健性，让整部机器运转更加有序，风险也更加可控。
在这台理想的机器运转时，机器的拥有者终于可以高枕无忧。因为无论发生任何意外，都肯定能在某份文件中，找到相应的错误定义及其预设处置方法。即使是某个重要零部件损坏，甚至是突然蒸发消失，也必然能够以最低代价，迅速找到一个替换备件顶上，化风险于无形。真是美妙的设计。
即使看穿程序的本质，仅仅只是为了写一行“print ‘hello, world!’”，也必然要为其周边几百上千行代码，寻找充足的存在理由，任谁也无法反驳的理由：万一屏幕不够大、装不下整个字符串呢？万一只打印了一个单词就断电了呢？……如此种种，总都得提前做点什么准备吧。
如今，我也开始喜欢上这种当年无法理解的“方法论”。毕竟嘛，开发工具从Visual Studio升级到Office，成本降低也是符合开源节流精神的。要支持！
—– END —–
注：本文首发表于“不靠谱颜论”公众号，并同步至本站。