Поиск ошибок в программах. Психологический аспект. Вопрос без ответа
Программисты совершают ошибки. Тезис конечно не мудреный. Ошибки совершают все. Но если в обычной жизни можно об ошибке потом даже не вспоминать, то ошибку в программе надо исправлять. Деваться от этого некуда.
Некоторое время назад я работал руководителем коллектива программистов. Мы выпускали банковский софт, коммерческий и кое какой системный. Я, кроме руководства процессом, и сам писал часть кода. И конечно же все в коллективе совершали ошибки.
Обнаружено наличие ошибки
В основном ошибки находились и исправлялись тем, кто их сделал за некоторое малое время. Это как бы часть процесса отладки — быстрое нахождение ошибок.
Но вот иногда программа вела себя нестандартно. И тот, кто писал эту часть, ошибку найти не мог. Или ошибки. Человек сидит, смотрит на экран, проверяет все построчно. Разбивает текст на отдельные части и пытается таким образом изолировать ошибку. Но все тщетно. Ошибка не находится.
Тогда программист начинает грешить на само средство программирования. На компилятор например. Начинает изучать версию, что ошибка не у него, а это дефект компилятора.
Потом изучается вариант, что может быть в базе данных, с которой работает программа, есть дефект и ошибка вызвана не корректными данным и просто она не обрабатывается. (кстати была такая база Interbase и в ней была ошибка — при определенном размере записи в этой базе вторичный индекс пропускал часть данных).
Потом изучаются входные данные на корректность и ставятся всевозможные проверки. Ну примерно каждый знает что можно предпринять для поиска ошибки.
Помощь друга
Время идет, а ошибка не находится. И тогда программист прибегает к «помощи друга». Идет со своей ошибкой к коллеге и просит помощи. Это ситуация напряженная, так как у всех своя работа и надо на своей работе концентрироваться. Всякое отвлечение на 5 минут требует потом 30 минут концентрации на тексте. Коллега, отвлекаясь от своей работы оказывает серьезную услугу. Кстати у авиадиспетчеров такое тоже наблюдается. У них как у программистов надо запомнить картинку на радаре.
Далее открывается код на экране и коллега говорит «ну показывай что у тебя там есть».
Происходит демонстрация кода, сопровождаемое словесным объяснением, что в этом коде делается. Коллега смотрит в этот код и задает уточняющие вопросы. Все более погружаясь в проблему.
Озарение
И в какой-то момент вдруг неожиданно тот, кто ошибку сделал, ее сам и находит. Именно автор ошибки. В каком-то таком месте, на которое он смотрел уже не однократно. Далее текст «спасибо я все нашел!» Он по этому месту ездил отладчиком не один раз. Проверял все переменные и индексы. Проверил чтобы все скобки стояли правильно. Но ничего не нашел. И только когда рядом появился человек, которому он начал пояснять как все устроено, ошибка была найдена.
Поскольку я руководил командой, то при появлении ситуации с длительным не нахождением ошибки, то и сам инициировал вот такое совместное рассмотрение текста. Подходил к коллеге и говорил «Вижу, что ты не продвигаешься в разработке. Давай вместе посмотрим». И я конечно тоже пытаюсь вникнуть в текст, но чаще всего совершенно достаточно тыкать в текст на экране и спрашивать «а вот этот кусок что делает?, а вот этот? А почему именно этот параметр в функцию передается? А какой метод вот тут наследуется?»
И вот чаще всего я сам никакую ошибку не нахожу. Я даже и мало понимаю, что там на самом деле происходит. Коллега в итоге все находит сам. Но только мое присутствие и выслушивание его объяснений приводит к успеху.
Почему так происходит?
Можно пытаться объяснить этот эффект тем, что человека выводят из привычной колеи и он получает с чужой помощью свой собственный взгляд со стороны. Или тем, что рассмотрение текста становится сплошным. То есть те куски, которые психологически вообще не рассматриваются при проверке, как предположительно «явно нормальные», начинают попадать в проверку. Может быть и другие эффекты срабатывают.
Точную причину эффекта этого механизма я не знаю. Но сам факт явления для меня является неоспоримым. Проверено многократно, что в когда есть проблема с поиском ошибки, поиску ее хорошо помогает «помощь друга», причем часто этому «другу» вообще не вдаваться в подробности, а можно просто тыкать в экран и спрашивать «а это вот что такое?». И проиходит чудо. Ошибка находится и ты слышишь «ну вот же оно! ну все. дальше я сам. Спасибо».
Творческий процесс кодирования видимо периодически заходит в тупик. Что-то неуловимое заводит разработчика в это состояние. Из которого имеется выход — совместный поиск. Наверняка имеются и другие варианты ускорения поиска ошибок. Есть всякие анализаторы кода, которые помогают находить типичные ситуации, которые могут приводить к ошибкам. Но в этой статье речь идет о ситуациях, когда уже все это было использовано. И анализаторы кода и расширенные директивы компилятору, то бы вывести больше предупреждений.
Скорость кодирования
Ранее (30 и более лет назад) была некая классификация программистов по скорости работы. Считалось, что 30–40 строк отложенного кода в день это уровень нормального программиста. Но есть программисты, которые производят более 150 строк отложенного кода в день. Их классифицировали как «супер программистов». И были две методики разработки. Один из них — набор команды нормальных программистов, к ним прибавлялся как сейчас говорят «тимлид» и с максимальным документированием изготовлялся проект.
И был второй подход. Нанимается один супер программист или двое. И они, работая на другом уровне скорости и концентрации, приводили к успеху проект даже быстрее. Это не проекты размера с «гугол» или «word». Но все равно не маленькие.
На Хабре тема скорости кодирования уже всплывала: https://habr.com/ru/articles/285966/
Вот еще более ранняя переводная статья: https://habr.com/ru/articles/102620/
Так вот на моей памяти эффект попадания в тупики при поиске ошибок наблюдался в обоих случаях. Способ «помощь друга» работает, даже если друг не сильно пытается понять что есть в коде и просто сидит и задает наводящие вопросы и в том и другом варианте.
Быть может кто-то сделает такое предположение по поводу работы описанного эффекта, которое позволит его понять и использовать системно.
Я им пользовался, так и не поняв самого механизма. Хотелось бы еще понять, как его использовать, когда команда не сидит в одном месте, а является распределенной.
В общих наших интересах находить полезные способы работы и учиться системно их использовать.
