280 lines
26 KiB
Markdown
280 lines
26 KiB
Markdown
# Траектория голоса автора: 2017–2027
|
||
|
||
Это редакторская карта для продолжения архива. Она описывает не идеального
|
||
«технического автора вообще», а наблюдаемую эволюцию DarkRiDDeR: от
|
||
практика, который делится найденным решением, к инженеру, способному объяснить
|
||
границы системы и выбор команды.
|
||
|
||
Основание карты — 13 исходных публикаций 2017–2019 годов: рецепты по
|
||
Bitrix/PHP и Windows, заметки о D, а также материалы о Webpack и jQuery.
|
||
Интервью, переводы и пересказы конференционных докладов важны для тематического
|
||
круга автора, но не являются чистым образцом его фразировки. Голос автора в них
|
||
лучше искать в заголовке, подводке, выборе примера, пояснениях и практическом
|
||
выводе.
|
||
|
||
## 1. Исходный язык 2017 года
|
||
|
||
Автор начинает с предмета, а не с рассуждения о его важности. Заголовок обычно
|
||
называет стек и операцию: «Bitrix API. Функция для генерации кода элемента…»,
|
||
«Ошибка PHP. SSL certificate error…», «Компиляция 64-x разрядных программ…».
|
||
Первый абзац быстро даёт знакомую ситуацию: «Часто в Bitrix необходимо…»,
|
||
«Недавно столкнулся с такой проблемой…», «При выполнении… может возникнуть
|
||
ошибка».
|
||
|
||
Базовая интонация — доброжелательный коллега рядом с рабочим столом. Он не
|
||
строит безличную лекцию, а ведёт читателя по найденному пути: «Для начала
|
||
нужно…», «Давайте…», «Создадим…», «Открываем командную строку, пишем…».
|
||
После инструкции автор обычно называет ожидаемый результат: «После чего ошибка
|
||
должна быть решена», «Если всё прошло удачно…», «В итоге у нас получается…».
|
||
Финал осторожный и человеческий: «Возможно, в вашем случае…», «Надеюсь, что
|
||
помог», «Поздравляю».
|
||
|
||
| Наблюдаемый паттерн | Зачем он нужен | Редакторская форма |
|
||
| --- | --- | --- |
|
||
| Стек + конкретная операция в заголовке | Сразу ограничивает задачу | <code>Bitrix API. Проверка символьного кода перед сохранением</code> |
|
||
| Симптом до рецепта | Читатель узнаёт свой случай | <code>Форма возвращает ID, но изображение не привязывается к товару.</code> |
|
||
| Последовательность «для начала → действие → результат» | Делает текст выполнимым | Один шаг, команда или фрагмент кода, затем ожидаемый эффект |
|
||
| Термин и расшифровка в скобках | Автор не предполагает лишнего опыта | <code>entry-файл (точка входа сборки)</code> при первом упоминании |
|
||
| Осторожный вывод | Не выдаёт локальную находку за закон | <code>Этот путь подходит, если проблема находится именно в…</code> |
|
||
|
||
Синтаксис исходного автора не академический. В нём есть длинные объяснения,
|
||
скобки с расшифровками, разговорные переходы и иногда шероховатости. Их не надо
|
||
копировать: орфографическая ошибка, калька, устаревшее техническое утверждение
|
||
или лишняя эмоциональность не являются частью голоса. Сохраняется другое:
|
||
близость к реальному действию, прямой порядок шагов и понятный критерий
|
||
готовности.
|
||
|
||
Постоянная формула автора на всём промежутке:
|
||
|
||
> симптом → граница проблемы → проверка → действие → ожидаемый результат → ограничение
|
||
|
||
В 2017 году граница чаще всего локальна: конкретный API-вызов, настройка
|
||
Windows, браузер, файл конфигурации или форма Bitrix. Позже формула остаётся,
|
||
но граница постепенно расширяется до модуля, сервиса, потока данных и решения
|
||
команды.
|
||
|
||
## 2. Развитие по периодам
|
||
|
||
### 2017–2018: практик интеграций и среды разработки
|
||
|
||
**T-shape.** Вертикаль — PHP/Bitrix: инфоблоки, свойства, файлы, торговые
|
||
предложения, ошибки интеграции. Ширина — D, Windows-инструменты, браузер,
|
||
базовый JavaScript и первая фронтенд-сборка. Автор уверенно показывает
|
||
выполнимый фрагмент, но ещё не обобщает его до архитектурного правила.
|
||
|
||
**Допустимый словарь.** <code>инфоблок</code>, <code>торговое предложение</code>,
|
||
<code>символьный код</code>, <code>cURL</code>, <code>CA bundle</code>,
|
||
<code>timeout</code>, <code>SDK</code>, <code>linker</code>, <code>entry</code>,
|
||
<code>bundle</code>, <code>jQuery</code>, «глобальная переменная». Английский
|
||
термин поясняется, если он не виден из кода. Слова «контракт», «граница
|
||
ответственности» и «жизненный цикл» возможны, когда они привязаны к конкретным
|
||
полям или вызовам, а не заменяют объяснение.
|
||
|
||
**Синтаксис и тон.** Короткий симптом, затем нумерованный маршрут или код.
|
||
Допустимы «давайте», «проверим», «в моём случае», но без заигрывания с
|
||
читателем. Сначала действие, затем обоснование. Одно предложение не должно
|
||
одновременно объяснять API, историю платформы и решение.
|
||
|
||
**Виды доказательств.** Воспроизводимый фрагмент кода, текст ошибки, снимок
|
||
экрана, команда, файл конфигурации, ручная проверка результата, ссылка на
|
||
документацию API. Достаточно локального случая, если автор явно называет его
|
||
границы.
|
||
|
||
**Чего автор ещё не знает.** Он не пишет от лица человека, который строил
|
||
SLO, проводил разборы крупных инцидентов, внедрял распределённую трассировку,
|
||
проектировал организационные процессы или владеет экономикой платформы. Нельзя
|
||
ретроспективно добавлять ему зрелую практику threat modeling, Kubernetes,
|
||
feature flags и продуктовые метрики без отдельного, правдоподобного мостика.
|
||
|
||
### 2019–2021: инженер на стыке фронтенда, доставки и данных
|
||
|
||
**T-shape.** PHP/интеграции остаются вертикалью, но к ним добавляются
|
||
модульный JavaScript, Webpack, HTTP, контейнеризация, SQL и первые
|
||
воспроизводимые сценарии доставки. Автор уже видит, что ошибка рождается на
|
||
границе модулей, конфигураций и окружений.
|
||
|
||
**Допустимый словарь.** <code>ES-модуль</code>, <code>dependency graph</code>,
|
||
<code>source map</code>, «кеш-заголовок», <code>Dockerfile</code>, «образ»,
|
||
«миграция», «индекс», <code>EXPLAIN</code>, <code>pipeline</code>,
|
||
<code>rollback</code>. Термины <code>CI/CD</code> и «наблюдаемость» допустимы,
|
||
но каждый раз должны быть разложены на конкретный запуск, лог, метрику или
|
||
проверку.
|
||
|
||
**Синтаксис и тон.** Появляется спокойное разделение условий: «если плагин
|
||
читает <code>window.jQuery</code>…», «если контейнер стартует от
|
||
непривилегированного пользователя…». Автор всё ещё может говорить от первого
|
||
лица, но реже использует ободряющие финалы и чаще фиксирует предпосылку, версию
|
||
и побочный эффект.
|
||
|
||
**Виды доказательств.** Конфигурация до/после, размер bundle, сетевой запрос,
|
||
вывод сборки, SQL-план, контейнерный лог, тестовый запрос, документированный
|
||
rollback. Метрика допустима, когда известны источник, окно измерения и
|
||
сравниваемый вариант.
|
||
|
||
**Чего автор ещё не знает.** Нельзя изображать опыт руководителя большой
|
||
платформы, владельца многооблачных расходов или человека с многолетней
|
||
практикой incident command. Сложные распределённые схемы допустимы как
|
||
изучаемый предмет, но не как безапелляционный личный опыт.
|
||
|
||
### 2022–2024: системный практик
|
||
|
||
**T-shape.** Центр тяжести смещается от отдельного рецепта к надёжности
|
||
изменения: производительность, доступность, безопасность, тестирование,
|
||
релизы, данные и согласование ролей. Глубина остаётся технической — автор не
|
||
уходит в абстрактное управление.
|
||
|
||
**Допустимый словарь.** <code>p95</code>, «бюджет ошибок», <code>trace</code>,
|
||
<code>span</code>, «корреляционный идентификатор», <code>rate limit</code>,
|
||
<code>threat model</code>, <code>CSP</code>, <code>WCAG</code>, «контракт API»,
|
||
«идемпотентность», «канареечный релиз», «откат». Эти слова нельзя ставить
|
||
списком: рядом нужны единица измерения, граница ответственности или конкретный
|
||
сценарий отказа.
|
||
|
||
**Синтаксис и тон.** Автор пишет короче и точнее. Вместо «система стала
|
||
быстрее» — «p95 ответа снизился с 1,8 до 0,7 с на тестовом наборе из N
|
||
запросов». Вместо «следует учесть безопасность» — условие атаки, защитный
|
||
контроль и способ проверки. Появляются таблицы вариантов и отдельные абзацы
|
||
про цену решения.
|
||
|
||
**Виды доказательств.** Трасса, график, нагрузочный сценарий, результат
|
||
автотеста, матрица прав, модель угроз, чек-лист релиза, план отката. Личный
|
||
опыт отделяется от данных из внешней документации.
|
||
|
||
**Чего автор ещё не знает.** Он ещё не обязан писать стратегию компании,
|
||
правила закупок или универсальную организационную модель. Не стоит приписывать
|
||
ему неизмеренный опыт внедрения AI-практик на масштабе всей организации.
|
||
|
||
### 2025–2027: наставник и техлид
|
||
|
||
**T-shape.** Автор связывает глубину разработки с последствиями для команды:
|
||
границы сервисов, владение, стоимость сопровождения, надёжная доставка,
|
||
наблюдаемость и безопасное использование новых инструментов. Он объясняет не
|
||
только «как исправить», но и почему выбран именно этот компромисс.
|
||
|
||
**Допустимый словарь.** <code>ADR</code>, <code>owner</code>, <code>SLO</code>,
|
||
«стоимость владения», <code>blast radius</code>, «схема миграции», «контроль
|
||
деградации», «eval-набор», <code>human review</code>, «политика данных».
|
||
Термины из AI, платформенной инженерии и безопасности допустимы только при
|
||
технической привязке: входные данные, риск, метрика, контроль и владелец.
|
||
|
||
**Синтаксис и тон.** Тон спокойный, наставнический и лишён позы. Статья
|
||
сравнивает два-три варианта, называет цену каждого и оставляет короткий путь
|
||
внедрения. Первое лицо используется для наблюдения из практики, а не как
|
||
замена доказательству. Закрытие — не вдохновляющий манифест, а решение,
|
||
ограничение и следующий проверяемый шаг.
|
||
|
||
**Виды доказательств.** Матрица выбора, архитектурная схема, измерение до/после,
|
||
последствия инцидента без чувствительных деталей, прогон тестов, план
|
||
мониторинга и отката, ADR или иной зафиксированный контекст решения. Если
|
||
данные нельзя раскрыть, автор честно описывает метод и не придумывает цифры.
|
||
|
||
**Чего автор всё ещё не знает.** Десять лет публикаций не дают права
|
||
утверждать, что его путь универсален. Автор не делает прогнозов за всю отрасль,
|
||
не приписывает команде непроверенные результаты и не заменяет технический
|
||
анализ модными словами.
|
||
|
||
## 3. Как звучит прагматичная техническая речь
|
||
|
||
Плохая фраза обычно скрывает объект, условие или проверку. Хорошая называет их
|
||
прямо.
|
||
|
||
| Период | Плохо | Хорошо |
|
||
| --- | --- | --- |
|
||
| 2017–2018 | «Нужно грамотно создавать торговые предложения, иначе будут проблемы.» | «<code>CIBlockElement::Add</code> вернул ID, но предложение ещё не связано с товаром. После сохранения проверяем свойство связи и выборку каталога.» |
|
||
| 2019–2021 | «Webpack магически подключает jQuery во всём проекте.» | «Старый плагин читает <code>window.jQuery</code>. Сначала кладём импорт в <code>window</code>, затем подключаем плагин; одного <code>ProvidePlugin</code> для этого случая недостаточно.» |
|
||
| 2022–2024 | «Наблюдаемость помогла оптимизировать сервис.» | «Трасса показала 1,1 с ожидания в запросе к партнёру. Ограничили timeout и добавили отдельную метрику ошибок этого вызова.» |
|
||
| 2025–2027 | «Надо внедрить AI и Kubernetes по современным стандартам.» | «Для автосуммаризации используем только обезличенный вход. До релиза сравниваем ответы на фиксированном eval-наборе, а спорные случаи оставляем на human review.» |
|
||
|
||
Короткая техническая речь не означает телеграфный стиль. Контекст нужен, если
|
||
без него нельзя повторить решение. Лишним считается предложение, которое не
|
||
добавляет симптом, причину, проверку, действие, ограничение или результат.
|
||
|
||
## 4. Непрерывность эволюции
|
||
|
||
Во все годы сохраняются пять признаков автора:
|
||
|
||
1. Тема начинается с конкретной инженерной работы, а не с тренда.
|
||
2. Термин привязан к коду, конфигурации или наблюдаемому эффекту.
|
||
3. Читателю дают выполнимый следующий шаг.
|
||
4. Ограничение называют рядом с решением, а не мелким шрифтом в конце.
|
||
5. Заключение возвращает к исходному симптому и критерию проверки.
|
||
|
||
Меняется глубина этого же движения:
|
||
|
||
| Этап | Что расширяется | Как это проявляется в тексте |
|
||
| --- | --- | --- |
|
||
| 2017–2018 | Локальная операция | Код, команда, настройка, ручная проверка |
|
||
| 2019–2021 | Граница модулей и окружений | Конфигурация, порядок загрузки, сборка, данные |
|
||
| 2022–2024 | Поведение системы после изменения | Метрики, тесты, риски, релиз и откат |
|
||
| 2025–2027 | Последствия решения для команды | Варианты, стоимость, владелец, способ повторить решение |
|
||
|
||
Новая компетенция должна появляться как ответ на предыдущую проблему. Например,
|
||
после заметок о timeout естественна статья о границах ожидания между браузером,
|
||
прокси и сервисом; после сборки фронтенда — материал о размере bundle или
|
||
кешировании; после ручной диагностики — наблюдаемость и автоматическая
|
||
проверка. Ненормален скачок от рецепта Bitrix сразу к «корпоративной AI-стратегии»
|
||
без цепочки практических задач между ними.
|
||
|
||
## 5. Обязательные критерии редактора
|
||
|
||
Редактор считает текст эволюцией автора, а не внезапной статьёй автора 2027
|
||
года, только если выполнены все условия ниже.
|
||
|
||
1. **Временная честность.** Словарь и уровень уверенности соответствуют году.
|
||
В статье 2017 года нет нераскрытых <code>SLO</code>,
|
||
<code>OpenTelemetry</code>, <code>Kubernetes</code>, <code>LLM eval</code>
|
||
и других поздних рамок. В статье 2027 года они объяснены через технический
|
||
сценарий, а не используются как декорация.
|
||
2. **Преемственность темы.** Новая область вырастает из уже освоенной: CMS и
|
||
PHP → фронтенд/сборка → доставка и данные → надёжность и архитектурные
|
||
решения. Если мост не очевиден, его нужно назвать во вступлении.
|
||
3. **Соразмерное доказательство.** Ранний локальный рецепт подтверждается
|
||
кодом и ручной проверкой; поздний системный вывод — измерением, тестом,
|
||
схемой, сравнением вариантов или документом решения.
|
||
4. **Сохранённая оптика практики.** Даже поздний текст начинает с конкретного
|
||
сбоя, ограничения или вопроса реализации. Статья, начинающаяся с
|
||
«в современном мире» или с общего манифеста, не проходит.
|
||
5. **Постепенное усложнение синтаксиса.** Ранний текст ведёт читателя шагами;
|
||
поздний может сравнивать варианты, но не прячет действие за абстрактными
|
||
существительными.
|
||
6. **Ограниченная компетентность.** Автор называет неизвестное, зависимость от
|
||
версии, нагрузки, прав, данных или команды. Уверенный тон не заменяет
|
||
границы применимости.
|
||
7. **Непридуманный опыт.** Число, инцидент, команда и результат либо имеют
|
||
источник, либо описаны как учебный пример. Нельзя фабриковать
|
||
«сэкономили 40%» или «внедрили во всей компании».
|
||
8. **Практический артефакт.** Есть минимальный путь проверки: код, запрос,
|
||
конфигурация, таблица симптомов, схема, тест или измерение. Совет без
|
||
артефакта не соответствует исходной манере.
|
||
9. **Проверяемый финал.** В конце есть ожидаемый эффект и следующий шаг, а не
|
||
лозунг, рекламный призыв или универсальное обещание.
|
||
|
||
Статья не проходит редактуру, если содержит три или более признака
|
||
«внезапного 2027 года»: непояснённый современный жаргон, абстрактный
|
||
стратегический тон, метрики без метода, универсальные выводы, отсутствие
|
||
выполнимого шага или компетенции, не связанные с предыдущими периодами.
|
||
|
||
## 6. Три прохода редактора голоса
|
||
|
||
Эта карта дополняет общий стандарт качества и не заменяет техническое,
|
||
фактологическое и визуальное ревью.
|
||
|
||
1. **Временной проход.** Отметить год статьи, разрешённый словарь и одно новое
|
||
умение. Проверить, что оно следует из предыдущей траектории.
|
||
2. **Голосовой проход.** Найти симптом в начале, конкретный артефакт в середине
|
||
и проверяемый финал. Убрать кальки, общие оценки и фразы, в которых
|
||
существительные скрывают действие.
|
||
3. **Прагматический проход.** Для каждого абзаца ответить: что читатель теперь
|
||
может проверить или сделать? Если ответа нет, сократить, перенести или
|
||
заменить абзац фактом.
|
||
|
||
Короткая карточка решения для редактора:
|
||
|
||
Год и период:
|
||
Постоянные признаки голоса:
|
||
Новое умение и мост к нему:
|
||
Артефакт доказательства:
|
||
Оговорка или граница:
|
||
Анахронизмы, которые были удалены:
|
||
Вердикт: соответствует / вернуть в доработку
|