大学的时间真的很自由，而且特别充裕，所以我下定决心要找点真正有意义的事情来做，比如，学算法，然后参加比赛。
这个想法其实从高中就开始在脑子里转了。虽然因为各种原因，我高中只读了一年半，但我心里的那份遗憾和不甘一直都在。现在既然有了大学这个平台，我终于可以尝试一下了。
而在开始学习和刷题的过程中，我也总结出了一些自己觉得挺实用的“小窍门”和心得体会：
1. 编码习惯：先搭骨架，再填细节
我发现，写算法题最怕的就是思路混乱。为了避免混乱，我认为以下几点最好可以做到：
- 框架先行： 拿到题，我不会急着开始敲代码。我会先写一个大框架，把输入和输出的基本结构定下来。
- 注释和函数名打头阵： 接着，我会写上清晰的注释，并把需要用到的核心函数名和参数先写好。
- 只写思路： 最关键的是，我暂时不会写详细的实现代码，而是直接在函数旁边写上我的解题思路。
这样做的好处是，能帮我先把整个流程梳理一遍，心里有数，比一上来就陷入细节要高效得多。
2. 模块化原则：功能切块，避免“一步错步步错”
另一个我习惯是模块化。
- 功能独立： 我会确保每一个独立的功能点（比如数据读取、核心计算、结果格式化）都单独写一个函数或者声明去实现。
- 防止连坐： 这样做最大的好处就是容错率高。如果代码的某个部分出了问题，比如某个复杂逻辑写错了，我只需要去修改和调试对应的那个函数就行，不会波及到其他已经写好的、没问题的代码。
- 提高维护性： 要不然，如果所有代码都挤在一起，某个地方一出 Bug，可能所有代码都要跟着修改和检查，那样消耗的时间和精力就太大了，感觉有点得不偿失。
3. 效率考量：实用至上，不为优化而优化
关于算法效率追求：
- 看收益比： 我认为，在写题的时候没必要太追求极致的效率。比如，一个算法已经是 $O(N)$（线性时间复杂度）了，为了把它优化到 $O(N \log N)$，我可能需要花费很多的时间去推导和重构代码。
- 时间更宝贵： 这种情况下，优化带来的性能提升往往并不明显，但消耗的时间成本却很高，感觉就有点得不偿失了。
我的原则是，把精力放在那些必须优化（比如从 $O(N^2)$ 优化到 $O(N \log N)$）才能通过时限的题目上，而不是在那些细枝末节的效率上钻牛角尖。