有没有过这种经历：收藏夹里躺着几十篇“刷题攻略”，却连第一页题都没看完；背单词App打卡三百天，真拿到一份英文技术文档还是读得磕磕绊绊。我之前也这样，直到把“编程题练习”和“计算机英语翻译”拆成两条独立的每日打卡线，才真正找到能把积累落地的节奏。今天这份记录，就是我这段时间实践下来最想分享的东西——写代码的手感没凉，啃英文资料的能力也在稳步提升。
先交代背景。我这个“Day30 + Day23”不是同一天起步的，编程题先开跑，跑了七天之后觉得光写题不够，又把计算机英语翻译练习加上了。所以两个进度差了正好一周。我能明显感觉到，前两周纯粹刷题的时候，代码逻辑想得越来越清楚，但一看官方文档就头痛；后来把翻译练习补上，再回头看那些API说明、报错信息，整个人的阅读状态都不一样了。这篇文章会把这套双线打卡的思路、每天具体怎么练、踩过的坑和怎么调整的，完完整整复盘一遍。适合正在刷题但感觉瓶颈明显的人，也适合英语底子一般、但被海量英文资料折磨的开发者。不需要多高的基础，核心是方法要对。
1. 编程题练习Day30：从“为了刷而刷”到“带着问题刷”
编程题练习这条线，我前后持续了三十天。头几天热血上头，一天干六七道简单题，觉得状态神勇。到第十天左右突然发现，简单题做了一堆，稍微绕一点的中等题还是没思路，这才意识到光靠量堆不出来“题感”。后来把策略改成“精选题目 + 刻意复盘”，这才算真正进入状态。
1.1 刷题目标拆解：别把“刷题”当成毅力测试
很多人觉得刷题就是拼坚持、拼数量，其实那是最容易放弃的玩法。到了第30天再回头看，我最大的改变是：不再把“做对一道题”当成目标，而是把“我能从这道题里带走什么”当成目标。
具体拆下来，编程题练习大概分三层目标：
- 第一层：熟练基础语法和常用数据结构（数组、链表、栈、队列、哈希表这些），目标是写代码不卡壳。
- 第二层：掌握常见解题范式，比如双指针、滑动窗口、动态规划、DFS/BFS，目标是见到同类题有下手方向。
- 第三层：训练读题、拆解约束条件、设计测试用例的能力，目标是上了考场或者接到算法需求时，能稳。
我前十五天基本在啃第一层和第二层的简单中等题，后十五天开始每天固定一道中等题加一道简单题热身。这么做的好处是，既有新知识输入，又有旧知识保温，不容易因为难度突然飙升而心态崩掉。
1.2 每日任务量与时间分配：不要迷信“每天五道题”
网上很多人晒“每日刷题五道 + 周赛”，看着确实燃，但实操起来，对普通上班族或者学生党来说不太现实。我给自己定的标准是：每天至少一道，最多不超过三道，但每道题都得能讲出个所以然。
具体时间分配大概是这样的（按每天六十分钟算）：
- 前十分钟：回顾昨天的错题或没想通的解法，不看代码、凭记忆重写一遍关键逻辑。
- 中间三十分钟：做今天的新题。拿到题先自己思考十分钟，没思路就看题解，但看完题解必须自己默写一遍，不能照着抄。
- 后二十分钟：整理笔记。这一步很多人会跳过，但我强烈建议别省。把今天题目的解决思路、复杂度分析、最关键的一行代码或一个优化点，用两到三句话写下来。周末再把这一周笔记扫一遍，比周赛打十场都管用。
理由也很简单：编程题练习的核心不是“见过多少题”，而是“能独立做对多少题”。做题时间压缩、复盘时间拉长，看起来进度变慢了，实际是在给底层能力打地基。
1.3 选什么难度的题最合适：舒适区边缘才是最佳练习区
如果一直做简单题，成长会很慢；一上来就啃困难题，挫败感会直接打消积极性。我的体会是，尽量保持“七成会做、三成需要想”的难度区间。
用LeetCode或者类似的题库选的话，我一般按照这个思路挑选：
- 简单题热身：选一道基础数据结构题，主要用来保持手感。比如链表的反转、二叉树的前序遍历这类，五分钟内搞定算达标。
- 中等题烧脑：选一道当前薄弱知识点的题目。比如这周想练动态规划，就连续三四天都选动态规划的中等题，直到形成条件反射。
- 困难题尝鲜：一周两到三次，选那些通过率不是特别低的困难题。不要指望一次AC，重点是看题解的时候能不能理解状态转移方程为什么这么设计。
这个选法配合了“刻意练习”的原则：练习的内容必须略高于当前水平，但不能高到完全够不着。题做不出来不可怕，可怕的是每次都只能靠题解才能做出来，那就变成背诵大全了。
2. 计算机英语翻译练习Day23：程序员学英语的正确姿势
编程练习做了一周之后，我开始认真考虑把计算机英语翻译加进来。起因是有天读Spring官方文档，一个简单的“bean scope”概念愣是读了三遍没捋明白，当时就意识到，查词典逐句翻都翻不对，这英语水平已经严重影响技术学习了。
2.1 为什么要练“计算机英语翻译”，而不是单纯背单词
很多人对程序员学英语的理解是“背单词”，但从我自己的经验看，背单词对阅读能力提升非常有限。什么“abort”“retry”“fail”这些背起来毫无难度，但真正卡住人的往往是一句完整的句子，比如：
The application context is responsible for instantiating, configuring and assembling the beans.
这句话里每个单词都认识，但如果平时没读过类似的句式，很容易翻译成“应用上下文负责实例化、配置和组装这些豆子”——这能看懂才有鬼。计算机英语翻译练习练的其实是两件事：一是技术词汇的准确理解，二是英文技术文档中常见句式的翻译习惯。
我给自己设定的训练方式是：每天选一段英文技术文档、源码注释或者知识库内容，长度控制在200到400词之间，完成三遍式翻译：“先通读预翻——再精翻逐句——最后对照参考译文。”坚持下来，效果比单纯背单词好太多。
2.2 翻译材料怎么选：从“看得懂”到“有收获”
选材料是这个练习里最重要的一步。选太简单的，练不出东西；选太难的，坚持不了三天。我按照经验排了个难度阶梯，大家可以直接用：
- 第一周：选自己熟悉框架的官方文档片段，比如Spring的Bean文档、React的快速入门，因为内容领域熟，就算英语句子复杂，也能靠上下文猜个大概。
- 第二周：选GitHub上一些知名项目的README和CONTRIBUTING文档，词汇偏实际开发，句式也更口语化。
- 第三周以后：可以挑战一些偏底层或特定领域的英文文章，比如数据库隔离级别、操作系统的进程调度、网络协议的原理说明。这时候词汇量不够的话，第一天会非常痛苦，但坚持一周之后进步特别明显。
我个人的建议是，每天的内容不要贪多，宁愿一段话翻得透透的，也别图快翻三页什么都记不住。翻译练习的核心不是“翻完”，而是“翻的过程中搞懂每一个模棱两可的句子”。
2.3 翻译过程拆解：从“逐词翻译”到“意译准确”
很多初学者翻英文技术文档，容易翻成那种“逐词对应”的机器翻译腔。比如：
The server responds with a redirect if the resource has been moved.
整句逐词翻出来是：“服务器响应一个重定向如果这个资源已经被移动了。”这种翻译在中文里根本不像人话。我在练习中慢慢总结出一个更顺的流程：
- 先整段通读一遍，搞清楚这段文字在讲什么技术动作。
- 按意群而不是按单词切分句子，比如上面的例句可以切分为：“服务器发出一个重定向响应 / 当资源已经被移动时”。
- 把切出来的意群按照中文的表达习惯重新排列：“如果资源已被移动，服务器会返回一个重定向响应。”
- 最后回头核对一遍，保证技术名词没有错译，逻辑关系没颠倒。
这个方法前几次用会感觉特别别扭，因为大脑习惯了逐词翻译的安全感。但用上三四次之后，翻译速度和准确度都会上一个台阶。这也是我把计算机英语翻译练习单独拎出来做打卡的原因——它是需要专门训练的独立技能，不是英语课上学的那套。
3. 双线打卡怎么配合：编程题和英语翻译的交叉训练法
单独练编程题和单独练英语翻译，都能各自做出成果。但把这俩放在一起做，其实能产生一些单线训练给不了的化学反应。
3.1 用英文原题替代部分中文刷题，一举两得
我在第20天左右开始尝试一个新的玩法：每周挑两天，直接用英文原题刷编程题。这就是编程题和计算机英语最自然的结合点。
具体操作是：拿到一道英文题目，先不看中文翻译，自己读题、提取约束条件、推断输入输出格式。等把题做完了，再回头对照中文翻译，看看自己有没有理解偏差。
这么做的好处是：英文阅读能力在真实场景里得到了检验，编程题的读题能力也在同步提升。毕竟不少竞赛和面试的题目都是英文的，提前适应没坏处。另一个好处是，很多中文翻译版本偶尔会有信息损耗，读原题反而能更准确地把边界条件搞明白。
当然，这个方法不适合零基础直接上。建议至少有十天以上的刷题基础，对常见的英文题目格式有了一定的熟悉度，再尝试这套混合玩法。
3.2 时间上的穿插安排：避免“先紧后松”的节奏崩坏
我的每日安排大致是这样：
- 早上（精力最充沛时）：编程题练习，做新题加复盘，耗时约50到60分钟。
- 下午或晚上（精神稍疲时）：计算机英语翻译练习，耗时约30到40分钟。
刻意把英语翻译放在精力稍微下降的时段，是因为翻译工作相对直觉化，不需要像解题那样高度集中逻辑思维。当然也有人反过来，早上脑子清醒适合学语言，晚上精神好适合写代码。这个可以根据自己的生物钟调整，关键是“顺序固定、时段固定”这个原则别丢。
我踩过的坑是，有一阵子为了赶进度，把两件事都挪到晚上做，结果编程题写不完就十点半了，英语翻译着急忙慌翻完，质量很差。后来重新固定为早上编程、晚上英语，整个节奏顺了很多。打卡练习最忌讳的就是“看心情安排时间”，规律感本身就是对抗懒惰的手段。
3.3 建立互相反哺的笔记体系：代码和翻译一起沉淀
双线打卡练到后期，我养成了一个习惯：专门建了一个笔记库，里面既有编程题的解题思路，也有当天翻译时遇到的好句子和术语。
笔记的维度大致分成四个板块：
| 类别 | 记录内容 | 举例 |
|---|---|---|
| 算法笔记 | 题号、难度、核心思路、复杂度 | 滑动窗口：维护一个可变区间，右指针扩张，左指针收缩 |
| 易错点 | 刷题过程中反复踩的坑 | 二分查找边界条件为什么容易写错 |
| 术语表 | 翻译时高频出现的技术词条 | idempotent（幂等）、deadlock（死锁）、throughput（吞吐量） |
| 金句库 | 英文原句和精翻对照 | "Fail fast is a principle that allows errors to surface early." |
这套笔记体系的好处是，复习的时候能够把昨天新学的专业术语直接对应到真实技术语境里。比如今天我翻译遇到“idempotent”这个单词，过了两天刷题正好遇到一个“幂等性设计”的题，两边一对照，这个单词就再也忘不掉了。这就是双线打卡的隐性收益：互相反哺，形成记忆钩子。
4. 30天能明显看到哪些变化：进度之外的收获
说了这么多方法，有人可能会问：练了三十天到底有没有效果？我先说结论——有的，而且比预想的更明显，但要区分“短期可见的收益”和“需要更长时间累积的收益”。
4.1 代码能力的实际变化
编程题练习到第30天，最直观的感受是：看到题目不再害怕了。以前看到中等题会习惯性退缩，先翻题解再说；现在能静下心来自己分析几分钟，即使最后没做出来，也能知道自己卡在哪个环节了。
具体的变化体现在三方面：
- 读题速度快了：从过去读题五分钟还抓不住重点，到现在基本能在第一遍读题时锁定输入输出和约束条件。
- 代码调试效率高了：以前报错要看半天才定位到问题，现在对常见错误类型（数组越界、空指针、边界条件少判断）形成了条件反射，debug时间缩短了不少。
- 对复杂度的敏感度提高了：写代码之前会主动想一下数据规模，是O(n)还是O(n^2)，不再像以前那样能跑过测试就行。
当然，必须说句实话：三十天能带来的变化，主要体现在“熟练度”上，要想在算法思想上发生质的飞跃，至少需要两到三个月的持续输入。但这个三十天的阶段，作为启动期，效果已经完全超出了我的预期。
4.2 计算机英语水平的真实感受
英语翻译练习到了第23天，最明显的变化体现在两方面。
一是阅读速度。最开始翻一段三百词的官方文档，加上查词、反复斟酌，可能要四十分钟以上；到了第二十天之后，基本上十五到二十分钟就能完成一次三遍式翻译。这个速度变化能够比较直观地验证练习的积累效果。
二是对“翻译腔”的敏感度。现在看到机器翻译的某些垃圾结果，几乎能瞬间说出问题在哪：语序生硬、术语不统一、动词和名词的转译出了偏差。这种能力在以前是没有的，说明大脑已经建立起一套针对“英文技术文档 → 中文表达”的转换模型。虽然还远没到专业译者的水平，但至少够自己日常查文档用了。
4.3 双线进行带来的心态变化
说实话，单线打卡很容易在某一天因为题目太难或者状态不好而断掉，但双线打卡给了一个缓冲：今天编程题做不出来，至少英语翻译还能完成一点；今天翻译状态差，至少编程题还能稳一稳心态。这种“两条腿走路”的容错设计，在我看来是能坚持三十天的最大功臣。
我也有过想放弃的瞬间——大概是第17天左右，连续两天遇到了同类型的动态规划题都没做出来，那种挫败感确实很上头。但因为有英语翻译这条线撑着，第二天恢复状态的过程中，心里想着“至少英语那边还在涨能力”，就能更快地从情绪低谷里走出来。
5. 实操中踩过的坑与避坑思路：给后来者的真心话
这种打卡练习，听起来简单，真做起来会遇到一堆意料之外的麻烦。我把踩过的坑和排查思路整理出来，算是给后来者的一点小小的“避坑指南”。
5.1 坑一：开头用力过猛，导致后面在家摆烂
前五天我给自己定的是每天五道编程题加一篇长文翻译，结果第三天就吃不消了。每天光完成这些就要三四个小时，完全挤占了正常的工作和休息时间。到第六天，直接一整天都没碰电脑。
后来我把任务量降到“每日一道编程题 + 一段300词翻译”，严格执行了两周，才慢慢把习惯重新养起来。我的建议是：宁可开始时任务量小到“不好意思说不练”，也不要大到一个周末就让人崩溃。习惯养成的核心是“每天都做”，而不是“每天做很多”。
5.2 坑二：翻译练习只翻不复习，翻完等于没翻
有段时间我翻完了就算完事，结果过三天再看那篇文章，里面的生词和句子结构基本忘干净了。后来我加了一个“三天后重译”的步骤：每隔三天，把之前翻过的那段英文再拿出来，不复看中文翻译，凭记忆重新翻一遍，然后和第一次的译文对照。
这个方法极其有用，因为重译能暴露出“当时以为懂了、其实没懂”的地方。凡是第二遍翻不出来的句子，就是真正需要花功夫攻克的知识点。计算机英语翻译练习如果只是单向输入，效率会打折扣；加上间隔复习，才算形成了一个闭环。
5.3 坑三：遇到不熟悉的主题就跳，练习面越跳越窄
我刚开始练习翻译时，喜欢挑自己熟悉的技术领域，比如前端框架相关的文档，因为读起来不费力。但练了两周后发现，这样做的成长非常有限——全是在舒适区里打转。
后来我给自己定了个规则：每周至少选一篇“完全陌生领域”的内容来翻。翻译《操作系统导论》的某一段、数据库索引原理的英文说明、甚至安全领域的入门文章，虽然痛苦，但坚持下来之后，能明显感觉到可阅读范围在向外扩展。
5.4 常见问题速查：实操中的典型情况与处理办法
| 问题 | 表现 | 处理办法 |
|---|---|---|
| 某天中断了打卡 | 一天没练，第二天不想碰了 | 不要追求完美连续打卡，断了就当“重启”，从最小的量重新开始 |
| 编程题完全没思路 | 拿到中等题思考十五分钟还是一筹莫展 | 直接看题解，但要“看完默写”，并记录“为什么我能想到的思路是错的” |
| 英文句子读不懂 | 每个词都认识，拼起来不知道什么意思 | 先找主干（主谓宾），再把修饰成分逐层挂上去，不要试图一遍读懂整句 |
| 时间不够用 | 工作一忙，白天的计划全泡汤 | 前一天晚上把次日的题和翻译材料准备好，第二天只要执行就行，减少决策成本 |
| 学了就忘 | 上周练的题、翻的词，这周全忘了 | 用“三天后重译”和“周度错题复盘”两种方式对抗遗忘 |
5.5 工具选择与效率提升：尽量少折腾，把时间花在实处
打卡练习的核心是“练”本身，所以工具越简单越好。我这里分享一套自己折腾后最终固定下来的组合：
- 刷题平台：选一个主平台就够，不用办很多会员，免费题量已经足够。
- 翻译工具：先用DeepL或Google翻译做辅助参考，但不能直接照搬，必须自己先翻一遍再对照参考译法。
- 词典：优先用专门的技术词典或英英词典，查出来的解释更贴合计算机语境。
- 笔记工具：任何支持本地存储的Markdown笔记软件都行。重点是笔记要留着，方便周末翻阅和三天后重译复习。
工具这个东西，最怕的就是过度配置。有人花一晚上研究各种花哨的刷题模板、单词卡插件和自动化脚本，结果真正坐下来学习的时间不到二十分钟。真没必要，一个代码编辑器加一个笔记软件，足够支撑一整年的打卡学习。
6. 接下来的拓展方向：从打卡到内化
二十多天三十天的打卡，对我而言相当于热身运动。练习期间积累的最有价值的东西，不是某道题、某个单词，而是一套“每天进步一点点”的节奏感。现在节奏已经有了，下一步就是把这个节奏用到更深的地方去。
我目前计划拓展的方向有三个：
第一个方向是把编程题的覆盖面拓宽。目前练得比较多的还是经典的数据结构和算法题，后续想往系统设计、并发编程和高性能计算方向靠一靠，通过题目驱动自己主动去补充底层原理知识。
第二个方向是直接给开源项目提PR。以前看英文issue和PR描述总觉得“没准备好”，但经过二十多天的翻译训练，现在基本能流畅地读懂讨论上下文了，下一步就是尝试参与进去。这一步相当于把英语翻译能力从输入方向迁到输出方向。
第三个方向是把“三遍式翻译”的思路推广到中文技术写作当中。学翻译的过程中积累了不少“如何把逻辑讲清楚”的心得，后续写技术博客时，把这些思路用起来，让文字更简洁清晰。
我始终觉得，编程题练习和计算机英语翻译练习这两件事之所以值得放在一起做，是因为它们本质上都在训练同一种能力：把模糊的问题拆解成清晰的结构，再找到对应的表达。无论是把一道算法题拆成几个子问题，还是把一个长难句拆成若干个意群，底层逻辑是相通的。
如果你也打算开始类似的打卡练习，我的最后一条建议是：不要等到“准备好了”再开始，直接选一道简单的编程题、选一段两百词的英文文档，今天就开始。过程中遇到问题不奇怪，边做边调整就好。三十天后回过头来，你会感谢那个今天迈出第一步的自己。
