大家周末愉快!今天写得有点迟了,因为我想了很久,加了东西又删了东西。
今天和大家简单聊聊我是怎么写题解的。经过了长时间的实践和交流,我总结了以下几点,和大家分享。
这其中一些方法也适用于做题和面试笔试的时候回答问题。当然我写的题解问题有很多,总结一下也是对自己的反思。当然我限于我的水平也有限,这一期的观点同样很主观,欢迎交流。
首先聊聊写题解的意义。
有一些题目的解法不是我想到的,或者有一些题目自己随便写的代码居然就通过了系统测评。这中间的道理如果自己不想明白,是很难和大家说清楚的。所以 写题解就会逼着自己去弄懂这些思路上不连贯的部分,搞懂一些代码上的细节。甚至通过这种以输出为目的的思考,可以帮助我们在原有的解法的基础上做一些优化。
写得清楚对别人有用,就会有人看,别人可以指出自己看不到的问题。回答别人的问题,也可以加深自己对知识点的理解。
我一般按照以下几个模块来写,这一点是学习「官方题解」的格式来写的。
其实这部分就是写「怎么想到的」。我肯定都会写这道的解法 是怎么想到的,也就是 体现思考的过程。不同类型的问题思路不一样。例如:
怎么写「如何想到的」?其实很多时候就是把题目读一遍,强调关键字和分析示例。最近和朋友们的交流,发现把「理解题意」单独设置一个小版块也蛮好的。
强调题目中的关键信息、关键字。很多时候一两个关键字的缺失,很可能这道题无解,或者就是另外一种解法。
分析示例,因为只根据题目的描述有些时候不能完全明白题目的意思,「示例」有输入输出,理解清楚「示例」就基本能够明白题目的意思。并且很多时候其实示例分析清楚了,解题的思路,使用的算法和数据结构就也清楚了。
先分析暴力解法,说一下暴力解法的优缺点,然后提出优化的解法。
我写的题解一般都会带一两张图,当然不会为了画图而画图,把当中抽象的部分,难理解的部分和一些细节展示出来。甚至解释题目意思的时候,我都会画一张图。我用的标准是:如果我在思考这个问题的时候,在草稿纸上画图了,那么我在写题解的时候就一定会画图。
画图软件就很多了,我用过 PPT(微软 Windows 办公软件之一)、KeyNote(Mac 办公软件之一)、OmniGraffle(Mac 上的收费软件)、draw.io(输入网址会自动跳到:https://app.diagrams.net/)。
一般我都放在 IDE 中写代码,因为 IDE 会告诉我:单词拼写错误、哪些声明的变量没有用到、哪些引入的类没有用到、以及一些代码优化的建议,以致于我不会把一些低级的错误展示给大家。
并且 IDE 还会帮我自动格式化代码,给别人看的代码,格式清楚还是要注意的。
有的时候做一下复杂度分析就会知道自己的代码问题在什么地方(甚至更好的做法可以在写代码之前做复杂度分析),还能够顺便带出优化的解法。我最经常用到的一句话是:这个解法时间复杂度较高,空间复杂度较低,因此我们可以考虑用「空间换时间」,在遍历的过程中记住一些信息,所以就有了下面的解法。
除了有一些非常复杂的「回溯算法」的复杂度分析,其它复杂度分析一般都不难。
下面谈一谈写好题解的一些我个人体会吧。
格式清楚这一点很重要。即使内容再好,要是格式歪歪扭扭的,可能读者也没法耐心看下去。这一点,除了细心和花时间,没有技巧。我一开始也写得歪歪扭扭的,也是写得多了,就慢慢被读者纠正过来了。
其实也很简单,我是来做分享的,我欢迎大家帮我看看错误,和可以改进的地方。
绝大多数做知识分享的朋友,一定会遇到质疑和一些没有理由的指责,还有一些过分的要求。理解这些看起来恶意的留言中善意的部分就好了。如果这部分留言能够帮助我改进,对我有所帮助就可以了。
这其实是我做得最不好的地方,最近回头看以前写的题解,有很多不满意的地方。现在新写的题解就会注意这一点,重点的地方加粗显示。
总的来说,读者愿意花一点时间停留在我们的题解上,我们就应该尽量提供一些对他们有用的信息。
周末脑子很空,主要想说的部分就是这些。大的道理都是简单的,就像减肥我们都知道最管用的是「管住嘴、迈开腿」。关键在于真的要行动起来。
这就是今天分享的内容,感谢大家的收看!