写代码一直都被认为是少数人才能掌握/理解的技能, 甚至有部分人认为这是与生俱来的天赋, 难以后天习得. 于是这些能使用编程语言与机器对话的人往往成了某种异类 – 类似与一些宗教中能够与神对话的祭司之类的角色.
然而市场有需求, 年轻人又好奇, 学习”编程”的需求总归是有增无减. 于是大学开设了专业, 培训机构进来捞钱, 竞赛什么的也搞得红火. 于是一代代的新人们就开始问问题: 怎样才能学好这玩意? 而最常见的回答也自然是: 多写, 多练习, 自然就会了.
好吧这个回答虽然不假 – 毕竟所谓的十万小时的理论看上去还是有那么点意思的. 反正精通编程的路还长得很, 管他三七二十一, 先动手写起来吧孩子. 但是假如编程的确是一种可习得的技能而非以天赋为门槛的属性, 那么这其中总归有可以通过语言或符号表达出来的知识, 继而可以通过文本传承下去而不是非要亲身经历才能掌握. 虽说从别人的经验里学东西很难很难, 但如果这个业界的人才只能依赖直接经验成长, 那恐怕也太落后了点.
与之类似的学习过程我暂时只能想到骑自行车: 初次骑上去基本上都是要摔上几次的, 而且没人能精确地用语言描述使用怎样的技巧就可以快速地入门. 我所唯一记住的骑自行车入门”诀窍”就是不要设法维护绝对的平衡, 要周期性地左右晃, 结果以后骑车就一直晃来晃去.
所以我想先假设: 学习编程的过程中有那么一些重要的知识 – 类似骑自行车要晃起来 – 在过来人眼里已经习以为常. 这些知识并不会记载在书本里, 或者有记载但缺少推广与强调, 结果就只能统一收录在”非实践不能体会”的分类里. 本来人类就容易陷入当局者迷的状态, 再加上程序员人群性格上的 stereotype – 内向且不善表达, 这些难以言说的知识就越发模糊起来, 不再容易被人们了解.
工具
先不提编辑器/IDE之战什么的, 程序员手头的第一个工具是键盘. 现在的年轻人盲打a-z应该不成问题, 但是标点符号与数字也请不要忽略, 组合键也应该找到舒适&高效的指法. 出于灵活适应的考虑不必急于训练到肌肉记忆的级别. (自己现在除了Vim binding别的都适应不了, 此后恐怕也很难尝试新玩意了.)
调试/版本控制/简单脚本等已经没什么好说的了, 但是不知道有多少人愿意花时间为别人做 Workflow 观察&改进. 有那么一次听到某路人说”操作慢一点正好休息”当时差点吐出一口老血. 理想中的效率瓶颈应该在思考问题而不是按 Alt+Tab 切换窗口.
Patterns
记忆特定问题的解决方案可能是”工作经验”最重要的组成部分. 从”谁给个X的代码实例”一类问题的数量就能看得出来. 分析/解决现实问题并总结 pattern 才能 get shit done, 而现状往往是死记一坨公式概念通过测试之后只会把 pattern 当作黑箱来处理(往往同样是死记).
地道(idiomatic)的代码同样是来自对 pattern 的正确应用. 目前我所见过的 idiom 都是冲着少打字和明确表达的原则去的.
Pattern或Idiom必然要受限于底层环境(基础API, 语言能力, etc.) 请从中立于具体环境的视角多加认识和理解 pattern.
全景
学习过程中你可以每次只吸收一点知识缓慢前进, 除了实现思路之外什么都不考虑. 一旦动手写起来就不得不面对错误信息/构建工具/依赖管理/版本控制/可维护性等一系列工程问题. 软件更多地还是工程而非科学. 的确你可以掌握N种时间复杂度小于O(n^2)的排序算法, 不过如果整个程序的瓶颈根本不在这, 这种不成熟的优化只是在徒劳地增加代码行数.
然后?
然后我暂时就在这枯竭了.