Інтервальні повторення для програмування

Ви вже пишете код або вивчаєте його, а дещо з цього все одно забувається: прапорець із минулого кварталу, відмінність, яка в п’ятницю була зрозумілою, виправлення, що мало сенс лише поки файл був відкритий. Інтервальні повторення для програмування — це рішення про те, який із цих фрагментів отримує заплановане повторення і що робити, коли настає час його повторити.

У кожного фрагмента одна з трьох ролей.

Рідкісний точний синтаксис шукайте в довідці. Написання коду, налагодження та розв’язання задач практикуйте в редакторі. Пригадування плануйте лише для стабільної ідеї, яку ви постійно забуваєте й очікуєте знову використати.

Те, що потрапляє в розклад, ширше за глосарій і вужче, ніж ставити дату повторення на кожну збережену нотатку. Туди входять відмінності, конвенції, логіка патернів, пастки й підказка, щоб знову пояснити або застосувати поняття, яке вже стало важливим у реальному проєкті. Крапка з комою в кожному рядку лишається поза розкладом. Так само й функція, яку ви викличете один раз.

Звичний опис навчання програмуванню змішує нотацію, патерни і саму роботу з планування та налагодження. На практиці ви маєте справу з ними одночасно. Коли настає час повторення, відтворіть матеріал до того, як знову відкриєте джерело: заново поясніть відмінність або застосуйте правило до нового випадку, а не до збереженого скрипта. Потім перевірте. Пошук точного синтаксису в документації та практична робота в редакторі залишаються окремими задачами.

Три ролі замість однієї проблеми з пам’яттю

Рядок «Довідка» — точний синтаксис, який можна прочитати, поки скрипт відкритий. Рядок «Практика» — дефект: назвати його ще не означає, що тест пройде. Рядок «Розклад» — стабільна ідея, яку ви вже розумієте, але постійно забуваєте, хоча вона вам знову знадобиться.

Що ставити в розклад

У розклад ставте стабільну ідею, яку ви вже забули і з якою очікуєте знову зіткнутися.

Відмінності. Debounce і throttle. Або git reset --soft, який переміщує HEAD і лишає індекс та робоче дерево як є, на відміну від git reset --hard, який переміщує HEAD і скидає і індекс, і робоче дерево до цього коміту. Якщо ви хотіли --soft, а запускаєте --hard, незакомічені зміни у відстежуваних файлах відкидаються.

Конвенції. Правило, яке послідовно використовується в кодовій базі. Цей сервіс повертає помилки як значення на межі, а викинуті винятки лишаються всередині модуля. Саме в новому файлі про це правило забувають. Уподобання, яким ви скористалися в одному скрипті, може лишитися в цьому скрипті.

Логіка патерну. Оптимістичне блокування записує рядок лише тоді, коли версія, яку ви прочитали, усе ще збігається зі збереженою версією. Поясніть це речення знову. Коли беретеся за задачу, напишіть оператор для однієї таблиці.

Пастки. Array.prototype.sort сортує на місці, а без функції порівняння порівнює елементи як рядки. Це можна знати і все одно залишити в коді [10, 2, 1].sort() для списку чисел. Додайте цю пастку до повторень. Місце виклику покрийте тестом.

Підказка пояснити або застосувати знову. «Коли цього рівня ізоляції досить, а коли оновленню потрібне блокування рядка?» Коли настає час повторення, перед вами саме ця підказка. Ви відтворюєте пояснення зі сторінки, а потім його перевіряєте. На повторення ви ставите рішення, яке очікуєте ухвалювати знову.

Не ставте в розклад крапку з комою, яку набираєте в кожному рядку. Не ставте й функцію, якою скористаєтесь один раз.

Картка, сторінка і задача — різні формати

Який об’єкт ставити в розклад — той самий вибір формату, що й нотатки чи флешкартки. Зв’язне пояснення може лишитися сторінкою. Те, що можна перевірити окремо, може бути карткою. Для коду дотримуйтесь того самого масштабу.

Debounce і throttle залишайте на одній сторінці, коли суть — умова, яка визначає, коли потрібен кожен із них. Токен виносьте на картку, коли вам справді потрібна точна форма і цей токен можна повторити окремо: git push --force-with-lease, якщо ви постійно ризикуєте випадково використати звичайний --force. Реальна задача лишається практикою в редакторі. Планувальник може вирішувати, коли настає час знову її розв’язати. Розв’язувати її все одно треба в редакторі.

Anki може сховати токен у фрагменті або попросити ввести відповідь. Обидва варіанти все одно зводяться до однієї речі, яку можна перевірити. Cloze, що ховає --force-with-lease, перевіряє цей прапорець. Написати скрипт релізу — це вже інше. Anki не запускає вашу програму.

Ті, хто користується Anki для коду, зазвичай виносять на картку один факт, одну відмінність або одну пастку — те, що вже розуміють. Підказка, щоб відтворити цілу фічу, — практичне завдання, і це погана флешкартка. «Реалізуй debounce» не годиться як картка саме з цієї причини. Реалізація — це вже робота в редакторі.

Для підготовки до співбесід підходить той самий поділ. Один підхід, який спрацьовує: нехай Anki вирішує, коли настає час знову розв’язати задачу, а потім розв’яжіть її в редакторі, щоб тренувати патерн, а не проговорювати один збережений розв’язок. На картці залишаються підказка та дата наступного повторення.

Реалізувати патерн або пояснити його за підказкою, а потім перевірити за джерелом — це повторення без карток.

У розклад — лише те, що вже знадобилося

Поширена робоча звичка — пам’ятати те, чим користуєтесь часто, решту шукати в довідці, а нотатку або картку залишати лише для того, що ви постійно забуваєте. Один її варіант — зберігати матеріал тоді, коли шукаєте його вдруге. Перший пошук — звичайна робота. Другий означає, що інформація знову знадобилася, але після першого разу не запам’яталася. Це просто звичка, а не висновок дослідження.

Особисте правило одного уважного користувача Anki було таким: API вчіть, користуючись ним, а картки лишайте лише для частин, які знову знадобляться. Nielsen наводить це правило у власному описі. Це правило однієї людини.

Користуйтеся API на задачі, яка у вас справді є. Прибирайте картки для матеріалу, з яким ви більше не зіткнетеся. API, який колись може стати в пригоді, не ставте в розклад, доки проєкт не зробить якусь його частину важливою.

Пригадати команду чи ідею — ще не означає вміти її застосувати

У тому самому описі картка може допомогти пригадати команду або ідею. Скористатися нею за клавіатурою і поєднати з іншими ідеями — подальший крок.

Ви можете пригадати git rebase -i, коли картка питає цю команду. Обрати її, відредагувати список todo і розв’язати конфлікт, на якому зупиняється rebase, — це подальший крок. Картка зробила свою роботу, коли ви пригадали команду. У редакторі з’ясовується, чи можете ви застосувати її разом із рештою історії.

Коли доречніший інший інструмент

Якщо набір складається із сотень прапорців, сигнатур або форм команд, Anki підходить краще. Кожен елемент — один факт, зі своєю підказкою і своєю датою наступного повторення.

Деякі інструменти планують короткі вправи на синтаксис і перевіряють код, який ви набираєте. Це завдання — точно відтворити невеликий патерн. Це не те саме, що зберігати пояснення, яким можна скористатися знову.

Писати код потрібно в обох випадках. Yuhimo — не така колода і не вправа, яка перевіряє набраний код.

Як Yuhimo вписується в цей підхід

Yuhimo підходить тоді, коли пояснення має залишитися сторінкою, а в розклад потрапляють лише деякі сторінки. Кожна сторінка спершу є нотаткою. Увімкніть навчання для поняття, яке хочете регулярно пригадувати: сторінка про debounce, правило на межі, підказка про ізоляцію. Сигнатури, які шукаєте в довідці, залишайте поза розкладом. Саме цей вибір і є навчальною сторінкою.

Додайте питання тоді, коли підказка достатньо конкретна, щоб ви могли однозначно визначити, чи справді пригадали потрібну відповідь. «Який git reset переміщує HEAD і ще скидає робоче дерево?» уже можна перевірити: є одна конкретна відповідь, яку ви або пригадали, або ні. Заголовок, у якому лише «Git reset», зазвичай занадто широкий: він не питає один режим, тож незрозуміло, чи ви пригадали саме те, що треба. Як складати таку підказку — те саме вміння, що й для будь-якого іншого запитання для пригадування.

Коли настає час повторити сторінку, поясніть або застосуйте матеріал знову, перш ніж її відкривати. Потім порівняйте спробу зі сторінкою. Підказка така: «Як добре ви це пам’ятали?» Ви оцінюєте власне пригадування:

• Забув — Не зміг згадати
• Важко — Згадав, але насилу
• Добре — Згадав правильно
• Легко — Згадав без зусиль

Yuhimo не вирішує, чи відповідь правильна, і не запускає код. Якщо ви змогли переказати debounce, а написати його все одно не змогли, оцініть те пригадування, яке справді вдалося, а сам код напишіть у редакторі.

Загальний спосіб планувати нотатки — інтервальні повторення для нотаток. Користуйтеся тим матеріалом, коли йдеться про те, як сторінка стає повторенням. Цією сторінкою користуйтеся, коли йдеться про те, які ідеї з програмування заслуговують на таке планування.

Типові помилки

Ціла функція на одній картці. У такої картки немає однієї відповіді, яку можна перевірити. Відпрацьовуйте цю функцію в редакторі.

Кожен API, який колись може стати в пригоді. Доки проєкт не зробив якусь його частину важливою, досить довідки. Після того як ви ним скористалися, лишайте лише ті частини, які знадобляться знову.

Синтаксична вправа замість реальної практики. Вправа перевіряє невеликий патерн. Обрати цей патерн у контексті реальної задачі та її обмежень і написати програму — це все ще робота редактора.

Картка, яка просить лише впізнати команду. Пригадати git rebase -i, коли про це питають, означає, що підказка спрацювала. Обрати її, набрати і поєднати — подальший крок.

Черга задач на співбесіду, запхана в застосунок для нотаток. Сторінка нотаток погано підходить для списку задач, які ви збиралися розв’язати знову. Нехай планувальник карток вирішує, коли настає час знову розв’язати задачу, і розв’язуйте її в редакторі, щоб тренувати патерн.