Читаю первую главу “Системного мышления”.
Интеллект — это мыслительное мастерство, часть личности. Интеллект реализован мозгом и телом (embodied), или даже совместно работающими мозгом и компьютером (экзокортекс), телом и инструментами (экзотело) обобщённый вычислитель-как-устройство, «мозг с глазками, ушками, ножками и ручками, компьютерами и инструментами»
Зацепилась за инструменты. И подумала: интеллект с инструментами (tools and instruments) бьёт просто интеллект.
Мысль не новая, везде на все лады нам повторяют “экзокортекс”, пишите и т.п. Но в рабочей ситуации возникла другая мысль: “Линтеры лучше людей”.
Размышления про ревью и уровень компетентности
Я с одной стороны за компетентность. С другой стороны, всё знать, а тем более всё помнить - невозможно. Проще спросить. Плюс это экономит время (на важное)?
Вот у нас в вакансии написано “требуется знание docker”. Но знание можно разметить какой-нибудь шкалой.
Никидываю шкалу:
0 - слышал, но не пользовался
1 - пользуюсь на уровне простых команд
2 - пользуюсь командами посложнее, могу написать код, который работает
3 - могу написать код, который работает оптимально, знаю распространённые ошибки и не делаю их
4 - знаю хитрые ошибки, знаю как работает внутри
5 - ходячая энциклопедия, слежу за всеми апдейтами и несу эти знания в массы
Вот у нас в команде нет нулевых по знанию докера. 80% людей единички. 20% двойки. И в то же время реальность такова, что Dockerfile для приложения пишется крайне редко. Один раз в начале, когда проект только начинался. В следующий раз только если мы дробим приложение на части. Из всей команды, может пара человек это делали. Остальные используют то, что написано другими.
Чтобы стать тройкой, я вижу два пути: заморочиться и добрать знаний, поставить навык; либо заручиться поддержкой tools. Медленный и более привычный путь первый. Для меня иногда он контринтуитивный - уточнять информацию по методу, когда делаешь. Я же специалист, знаю что делаю! Второй: автоматизировать уточнение инфы (воткнуть linter, спрашивать у бота).
А ещё у нас T-shape person. Т.е. я от себя ожидаю глубокой экспертизы в профильных областях и неплохой в смежных. И тут я подумала: как будто надо разделить какие у меня знания из вертикальной палки T-shape, а какие из горизонтальной. Мы вертикальную обычно доучиваем (растим цифру из моей шкалы), а по горизонтальной - может достаточно знать, где искать (у кого или как спросить)?
К чему я про ревью упомянула. Это взаимосвязанные вещи. Мне сейчас назначили пачку задач по правкам замечаний от службы безопастности. Как это выглядит? Да почти так же, как пожарную безопасность проверяют в кафе. Раз в период какой-то приходит инспектор и давай шерстить ваше заведение. У нас шерстит какой-нибудь статический анализатор кода по всем репозиториям проекта на предмет уязвимостей. С периодичностью тоже есть вопросы. Вот я сейчас допустим поправлю всё, что нашли. А в следующий раз они через полгода придут? А за эти полгода каков шанс, что мы снова дырок не наделаем?
Тут возникает вопрос ревью и линтеров. Как в любой команде разработки у нас есть процесс код ревью. И даже правило (непреложное), что апрувнуть (одобрить) твою ветку с кодом должен любой другой член команды. Сам ты себе не должен ставить галочку. Хотя на уровне репозитория правила на это нет и её всё-таки можно поставить. Но мы такие “это на критичные случаи”. Критичные случаи это когда кто-то хотфикс ночью делает для продакшена. И просто нет на связи тех, кто может поставить галочку. Что подразумевает ревью кода? Как будто бы, то что коллега (или несколько коллег) посмотрят глазами твой код, побудут “интерпретатором программы”, попытаются в голове прогнать код и подумать где он может работать криво. Криво - не так, как мы ожидаем. Что для этого нужно от коллег? Компетентность (экспертиза в той технологии кода, которая используется для решения задачи) и внимательность. Я выше про компетентность написала, она может быть разная. Плюс умножаем комптентность на невнимательность получаем ноль пользы. “Я не заметил! - ты не обратил внимание”. Умножаем компетентность на плохую память мокрой нейросетки - опять получаем ноль. Я вроде знаю это, но конкретно в этот момент не вспомнила. Какого качество такое ручное интерпретирование программ? Так себе. Это я ещё про формальность галочек ничего не сказала. А формальные галочки тоже бывают. Потому что опять вопросы собранности, срочности, того чем человек занят, когда ты в чат кидаешь просьбу провести ревью. Можно сейчас начать разговор, что ревью это не про качество. Но не будем.
Что делать с этим? Я за линтеры. Если я забываю и невнимательная, а какие-то штуки можно проверять формально через tools. То их надо проверять. Просто добавляя очередной линтер. Но самая контринтуитивная мысль такая: использовать предподготовку до/во время написания кода. Т.е. сразу подумать, как я могу себя проверить, есть какая-то штука, которая проверит “распространенные ошибки”. И если она есть (библиотека или бот), то я её запускаю на то, что пишу. И до ревью уже какие-то вещи исправлю, несильно надеясь на коллег и дальнейшие этапы жизни моего кода. Это не волшебная таблетка, есть довольно много мест, которые всё ещё только глазами можно распарсить. Причём это тоже на уровне тела “что-то мне тут не нравится”. И там остановиться и подумать, пойти документацию почитать. Куча ошибок продолжает путешествовать по линии “первый делал быстро, потому что горело, второй скопировал код, не думал, третий и т.д. копируют кривое”. Потом полгода проходит и кто-то внимательный вдруг обнаруживает, “а что это за ерунда написана? это же не будет работать. И у нас это в 10 местах в проекте”. Тушите свет.