Spiiin's blog

Ctrl+C, Ctrl+X и Ctrl+Arrow программисты — древнее полушуточное деление программистов по клавише, которую они чаще всего нажимают.

Я в этой схеме Ctrl+X программист.

• после Ctrl+X иногда можно не нажимать Ctrl+V. Код надо активно удалять, разросшаяся кодовая база — это самое страшное, что может случиться с проектом.
• философия Ctrl+X наивно предполагает, что существующий код в хорошем состоянии. Каждое небольшое изменение, начиная с первого коммита в репозиторий делает его немного лучше. Не переиспользовать готовый хороший код — плохо. Даже если готовый код плохой, чтош, приходится переиспользовать плохой код. При таком подходе не годится только код, который вообще нельзя переиспользовать, его можно только выбросить и написать новый, который делает то же, но лучше подходит для переиспользования.
• в большой кодовой базе редко возникает ситуация, когда новая задача требует абсолютно нового кода.
• если необходимо заменить целую подсистему, возможно делать это инкрементально, а не большим куском (Strangler Fig pattern).

Strangles fig — тотемное дерево Ctrl-X программистов, в Тайланде много таких. Маленькие ростки сверхну вниз постепенно создают отдельные новые пути, замещая старое дерево

• Хорошие качества программистов — умение решать задачу минимальным количеством изменений в коде

Ctrl+N программисты

Недавно я понял, что знаю ещё один тип программистов. Их любимое сочетание клавиш — Ctrl+N. Создать новый файл и начать писать туда код. Много кода. Типа такого, 10к строк, насколько PR их не дели, остаются 10к строк за раз. “Там на 70% всё правильно” (это кажется одновременно и шутка, и серьёзная оценка). В хороших случаях — половина кода тесты. Но про этим, если верить эвристике, что число ошибок на 1к строк кода постоянно, то в тестах тоже будет несколько ошибок. Да и тесты — это не способ проверить сам добавляемый сейчас код, и тем более не способ проверить интеграцию этого кода в общую базу, они для проверки добавляемого кода к будущем его изменениям.

“Почему коллеги не захотели отревьюить мой код, у них был шанс, теперь придётся мерджить так” — реалистичный лимит на ревью - 100-500 строк, а в идеале 20-100 строк. Всё что больше просто монолит, гарантированно содержащий несколько ошибок, с большим количеством информации о коде в голове автора. Либо брать целиком как есть, либо выбрасывать целиком. Я встречал кейс, когда автор прочитал 1.5 часовую лекцию с обещанием потом записать всё в вики. Конспект и детальное расписывание примеров в этом случае займёт дополнительно часов 5 (в ходе написания документации обнаружатся пробелы в памяти автора и скорее всего ошибки в коде).

При интеграции возникает проблема Ахиллеса и черепахи, пока программист делает свою часть работы, проект уходит немного вперёд (или оказывается, что автор забыл, что его изменения требуют ещё каких-то дополнительных изменений в проекте или в коде автора), что требует дополнительных правок, за время которых проект уходит ещё немного вперёд.

Из хороших качеств Ctrl-N программистов — это умные и энергичные люди, способные быстро писать большое количество кода и держать в голове его структуру (пока не забудут). В хорошем случае, тратят больше времени на планирование на бумаге и тесты.

Сложность предметной области

Иногда большой объём кода, который любят писать Ctrl+N программисты является отражением сложности предметной области. Например, для создания/рефакторинга библиотеки gui программисту потребовалось переписать разом 50 контролов, или при создании DSL — несколько десятков конструкций для своего доменного языка. Варианты решений, которые могут немного исправить такие ситуации — кодогенерация (кодогенератор десяти тысяч строк вполне может уложиться в 500 строк), или использование другого языка, который уже решает часть проблем.

Например каждая конструкция доменного языка скорее всего потребует описания не только своей структуры, а и нескольких действий на основе этой структуры:
- верификации (валиден ли сгенерированный пользователем код?)
- выполнения (как именно выполнять описанные пользователем dsl действия),
- преобразований (может ли мы улучшить описанную пользователем структуру вместо выполнения)
- хранения (как сохранить/восстановить структуру при перезапуске программы-хоста, включая версионирование при изменениях в самом DSL)
- представления (как отображать dsl, визуальное представление для редактирования или отладки)
Эти действия в разных языкам могут быть выражены как тривиально, так и требовать ручной работы. Один из вариантов решения — не описывать это руками, а воспользоваться функционалом другого языка (с виртуальной машиной или другим способом встроить его в основной), который уже решает часть или все задачи. Тогда реализуемый dsl вместо описания того как выполнять каждое из этих действий превратится в описание того, как отобразить описание структур на исходном языке в описание для виртуальной машины (и, возможно, обратно).

Ctrl+S программисты

Ходят легенды также о мифических Ctrl-S программистах, которые чаще всего сохраняют код, и благодаря hot-reload изучают результат в запущенном приложении.