Что такое ката?

Помните ли вы, как начинался ваш путь в программировании? Первые статьи/книги с малопонятными конструкциями, первый "Hello, world!"?..

С первых шагов в профессии и до достижения статуса уважаемого разработчика наша формальная задача - обладать знанием, знанием framework'ов/технологий/языков. Но отражает ли она в действительности все требования к специалисту? Действительно ли среднестатистический разработчик полноценно владеет своими профессиональными инструментами - клавиатурой и IDE?

Начинающий музыкант на пути к вершинам мастерства тратит огромное количество времени на практические занятия. Раз за разом воспроизводя классические произведения, он оттачивает технику игры, уровень за уровнем познает смыслы и приемы, заложенные в мелодию... Лишь спустя годы он придет к такому автоматизму и легкости игры, что способен будет на полноценную импровизацию, созданию музыки "на лету".

Что же творится в нашей среде, если сравнивать с тем музыкантом? Джуну показывают ноты, объясняют как найти До и... вперед, напиши клиенту гимн компании, если что - google в помощь) Стоит ли удивляться тому, что код выходит омерзительным посредственным, а заложенные в начале карьеры подходы и шаблоны поведения отдаются эхом в сомнительном коде даже на n-й год карьеры? Страдает качество кода, страдает скорость написания, страдают коллеги...

Конечно же, ничто не отменит того факта, что программисты "тренируются" каждый день, создавая код в рамках рабочего процесса. Но как часто в вашей жизни бывали ситуации, когда вы не просто выполняли постановку, а ставили задачей довести до идеального состояния некий фрагмент функциональности? Вы знаете точно свою скорость печати? Когда было такое, что вы, написав некоторый код подумали "Я мог бы это сделать и побыстрее" и... удаляли все написанное и начинали заново с таймером? Абсурд?) В рабочее время уж точно - никто не будет вам платить за такие фокусы на рабочем месте.

Означает ли это, что ни скорость, ни качество кода не важны? Отнюдь, но бытует мнение, что они должны появиться сами собой... Вот только сколько ваших коллег вы можете назвать по-настоящему сильными разработчиками, на которых стоит равняться?

В качестве решения этой проблемы появились ката - упражнения, призванные сместить парадигму восприятия кодирования с "что я пишу" на "как я пишу".

Рабочие задачи - плохой тренер

Главное, чтобы были выполнены требования?

Вся работа программистов состоит в выполнении требований бизнеса - создать функциональность/воплотить дизайн. Основное внимание всегда сосредоточено на вопросе функционирования кода и имплементации требований. Потому главный, а часто, единственный критерий оценки - прохождение приемочного тестирования. Изредка встречаются команды, которые очень жестко выстраивают механизмы code review, но в большинстве компаний вы можете написать метод в 50 строчек длинной, и никто вас за это не побьет. Т.е. качество кода оставлено на совесть разработчиков. И вот тут заключается главный вопрос: а приемлемо ли для вас, как разработчика, писать подобное? Ответы в духе "дефицит времени"/"так тоже ничего" не принимаются) Приверженность идее лаконичности кода либо есть, либо нет. Не существует обстоятельств, которые бы не позволили разбить 50-строчный метод на более мелкие. Объяснение тут только одно - разработчику комфортно с этим бардаком, приложение ведь работает.

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

Скорость никому не важна

Конечно, бизнес хочет, чтобы задачи делались быстро, но что значит это "быстро"? С какой мерой мы подходим к оценке? "Я прикручу эту кнопку за 5 часов"? А что происходит в эти пять часов? Есть ли более мелкие задачи внутри этой? И самое главное для вашего роста: а знаете ли вы насколько быстрее вы делали эту задачу год назад?

Глупо говорить "я стал быстрее писать код". Насколько? Для того, чтобы измерить это нужно знать начальное и конечное состояние и иметь одинаковые условия задачи. Только так появится объективное "было 40 минут, стало 20, общая скорость выросла на 100%". Только вот на работе вы этого никогда не увидите - задачи всегда разные.

Ката заставляют вас следить за временем, появляется измеримый результат работы, который можно объективно измерить; да и наличие обратной связи стимулирует развитие.

Поставив задачу увеличения скорости написания кода разработчик начинает искать возможности. Например, некоторые разработчики умудряются переименовывать переменные с участием мыши. Т.е., буквально, нужно: убрать руку от клавиатуры, взять мышь, передвинуть ее на позицию, правый клик, поиск в меню, клик, возврат к клавиатуре, введение имени. В особо тяжелых случаях 'Ok' тоже кликается мышью. А не проще нажать F2, ввести имя и нажать Enter? Быстрее уж точно. Мелочь, несколько секунд разницы? В конкретный момент да, но законы больших чисел неумолимы - на длинной дистанции такие мелочи превращаются в часы.

Как тренироваться?

Найдите подходящую постановку (примеры можно поискать тут, раздел будет потихоньку пополняться).

Выделите время на регулярные тренировки. Стандартная сессия длится 30 минут. В зависимости от устремлений вы можете заниматься каждый день или раз в неделю. Но, конечно, чем больше тренировок, тем быстрее результат.

Всегда ставьте задачи на ближайшие тренировки. Поначалу это будет просто выполнить все пункты за отведенное время. Не стоит на этом останавливаться. Посмотрите keymap вашей IDE, найдите комбинации, которые пригодятся вам процессе написания кода. В какой-то момент вовсе откажитесь от мыши... вызов!)

С каждой итерацией старайтесь сделать свой код чище, лаконичнее, эффективнее.

Ни в коем случае не превышайте лимит времени. Спустя 30 минут вы должны закончить писать код. Получилось выполнить лишь 3 из 7ми пунктов? Будет стимул постараться завтра)