Метод пристального взгляда

В те времена, когда трава была зеленее, а в университетах ещё не обучали программной инженерии, да она и не особо была развита, вместо термина code review/обзор кода/инспекция кода, использовался классический "метод пристального взгляда".

Программисты интуитивно улавливали, что вообще очень полезно несколько раз просто внимательно пересмотреть исходный код — в частности, перед сборкой, которая на сишечке вполне могла длиться и часы, и если вдруг потом продукт падал с простым багом, становилось особенно обидно. "Метод пристального взгляда" даже был своеобразным мемом.

Это действительно очень полезный метод для поиска ошибок в коде. Вообще, сразу лезть в отладчик у программистов олдскула считается зашквар. В крайнем случае, можно поизучать логи, ну а самое правильное и крутое — это найти ошибку именно методом пристального взгляда. В 1990-м, мы сидели-кодили в парижском офисе вдвоём с парнишкой-программистом, и приходит ему факс из МГУ (интернета тогда не было), что в некотором стороннем продукте A найден такой-то баг, по сообщению пользователя. У него были с собой исходники, которые на месте собрать было нереально, она была слишком здоровая, но он нашёл ошибку "всухую" за полчаса, потому что просто хранил в голове модель всей системы.

Комментарии в коде конечно тут бывают весьма полезны, но самое главное — это как раз вот такое умение сформировать в своём мозгу виртуальную вычислительную машину, под конкретный проект, которая стартует когда надо в нашем бессознательном, и фоново прокручивает кусочки кода, а когда возникают баги, даёт сигналы лёгким смутным дискомфортом "вот в этих строчках кода что-то не так".

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

Но такой подход даст слабое представления о программировании как о единой дисциплине.

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

* * *

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

Подобные умники (на уровне, не дотягивающем даже до стажёров по моей матрице компетенции), попробовав code review, периодически заявляют:

- А мы пробовали обзоры кода, они не работают.

Я уже устал, как робот, повторять в таких случаях классический типовой сценарий Карнеги-Меллона... С какой командой не пообщаюсь, везде одно и то же около-дно.

- Ok, сколько кода вы проверили?

- Ну я даже не знаю... Может 500 строк, может побольше, мы не меряли.

- Как вы проводили обзор кода?

- Мы протестировали свой код, и тестами выявилось около 30 багов. Потом я принялся рассматривать свой код, и нашёл ещё десяток багов.

- Сколько времени ушло на инспекцию кода?

- Ну я даже не знаю, мы это не фиксировали... Мы не уверены, но вроде немного.

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

Сколько ненайденных ошибок осталось в системе? Почему вы думаете, что нашли их все? Откуда вы знаете, что отправили в продакшен свой код без багов? А может быть, там выявится ещё 100 ошибок?

Выявила ли инспекция кода критически важные ошибки?

Кстати, никто из ребят даже не пытался сделать обзор кода перед тестами, что делало и без того печальную ситуацию ещё более мрачной.

Большая часть любого инженерного дела — это измерение объективно измеряемых величин. Именно поэтому я, как уже говорил, полностью прекращаю поддержку схем "быстро в профессию". Человек обязательно должен как следует накушаться классических инженерных подходов, которым учат только в университетах, и только после этого браться за работу программистом.

Инженерная работа — это постоянное измерение ваттов на килограмм и километров в час, выкопанных канав до обеда и рейтингов ошибок в коде. Программная инженерия будет инженерией только тогда, когда мы регулярно собираем объективные показатели работы: эффективность инспекций кода, характеристики обнаружения ошибок, производительность и качество.

В мире наработан большой объем знаний по всем этим темкам. Если вы не собираете свои собственные метрики по своим проектам — потому что все эти характеристики объективные, но всегда относительные, относительно ваших конкретных способностей — то нет никакого волшебного способа довести вашу команду до уровня state of the art.

Это как ездить с закрытыми глазами.

* * *

Я объясняю это, а в ответ долгая тишина и хлопанье пустыми глазами.

Ну, штош...

Комментарии: