题目背後的设计思维 - 资料结构与演算法

刷题的正确姿势

在前一天的 LeetCode 解题的思考策略与解题地图 中提到程序题目的两种考法，分别是「前测的技术面试题目」或「现场互动的白板题」。今天想要跟大家聊聊解题时的心态与策略，如何理解题目背後的设计思维。

刷题过程的心态与技巧

其实写程序本身就是一种对话，你不是机器人、也不是百科全书，所以很难一昧、单向的进行解题。回想我们平常在开发程序的过程，其实上网搜寻、查阅书籍的时间一定占用不少的时间，真正「敲程序码」的时间反而有限。因此，不管你是在面试当下面对面试官的解题或平常在练习刷题时，透过「对话」厘清需求、发想解法都是蛮建议的方法。

我自己会把刷题过程的心态与技巧的大概可以总结为这三项：

• 勇敢的提出互动与沟通（不管是自言自语或是与面试官交流）
• 尝试用自己的话解释题目化，将抽象的情境转化为具体的问题
• 动手之前先思考，将过程拆解成 step-by-step 的解题步骤

就像经典的 黄色小鸭除错法（Rubber Duck Debugging） 一样，你需要其实是那个「思考」的过程。

如何写出「更好的」的程序码？

所谓的「如何理解题目背後的设计思维」这个问题，需要先思考「写程序的本质」到底是什麽？而 LeetCode 的题目就是其实就是一种「评断程序能力到什麽程度？」的面试题目汇总，比起刷题更值得关注的是该如何从这些练习中锻链出更好的程序码品质开发功力。

所谓的写程序就是利用电脑的记忆与运算，根据 Input 产生 Output 的过程，而演算法指的是在有限步骤与时间内执行的程序，这也是写程序与演算法之间最大的差异。演算法我们更执着「多少个步骤」或「多少时间」可以完成，这个效能与复杂度是否堪用。

从程序设计到资料结构与演算法

程序设计利用「变数」使用记忆体储存与记忆、利用「流程控制」实现运算，所以写程序就是在变数与运算间穿梭。流程控制可以由「循序」、「条件」与「重复」三种结构所组成，使用不同的程序码搭配创造出各式各样的运行结果。一般讨论程序码写得好不好，可以从「记忆体的空间复杂度」与「CPU 的运算时间复杂」两个方向着手，也就是如何管理好变数以及如何设计好流程。

资料结构这一门学科专注在如何利用一些抽象的结构有效在程序中储存资料，换句话说，就是在讨论怎样更好的使用变数的方法。演算法的话则是搜集那些经典的方法，介绍那些常见的问题过去是如何设计出漂亮的方法来解决的，也可以视为是一种流程上的优化。所以，其实资料结构与演算法就是写程序，资料结构或演算法其实就是程序码经年累月淬炼出的精华，经过整理而成的武功秘笈，让我们得以站在巨人的肩膀上写出更好的程序码。

看懂题目背後的设计思维

从「如何理解题目背後的设计思维」到「看懂题目背後的设计思维」，其实就是一种写出更好的程序码品质的过程。这些题目背後在意的其实就是那些曾经被优化过的历程（例如资料结构或演算法），你能否站在巨人的肩膀上再持续往前呢？所以你说 LeetCode 题就是在考资料结构或演算法吗？这句话我觉得对与不对，应该说是想考的是你能否从这些方法中习得「优化程序」码的能力。

持续优化的思考过程

这个段落听起来也许有点抽象，我们试着思考以下两种场景：

① A 看完了题目马上画了关键字，心中想过我练过这个题目，然後埋首刻出了一个「一个非常漂亮」的写法
② B 看完了题目皱了眉头，向面试官厘清了一些疑问之後，然後写出来了一个「好像没有那麽厉害」的写法

这边我们可以明显感觉到 A > B，但你丢出下一个问题「你可以怎麽优化这个程序码呢？」後 ...

① A 同学就说这是我在解答中看过最佳的算法，已经没有更好的方法了。
② B 开始与面试官讨论并且根据经验提出这边可以怎麽改、那边可以使用另外一种方法，然後拼凑出优化後的程序码。

从这两个情境中可以明显感觉 A 与 B 不太一样，我也不确定那一种人在面试过程中比较容易受到青睐。不过更多的情况下，你很难真的刷到面试一模一样的题目，所以我想能够「从根据经验提出优化的策略」是刷题中必须习得的技能之一。

嗨，大家好！我是维元，一名擅长网站开发与资料科学的双栖工程师，斜杠於程序社群【JSDC】核心成员及【资料科学家的工作日常】粉专经营。目前在 ALPHACamp 担任资料工程师，同时也在中华电信、工研院与多所学校等单位持续开课。拥有多次大型技术会议讲者与竞赛获奖经验，持续在不同的平台发表对 #资料科学、 #网页开发 或 #软件职涯 相关的分享，邀请你加入 订阅 接收最新资讯。