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