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

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

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

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

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

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

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

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

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

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

Розрізнення. 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, коли про це питають, означає, що підказка спрацювала. Обрати її, набрати і поєднати — подальший крок.

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