Как эффективно отследить многие ошибки после изменений?

[creative]

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

Вопрос: какими методами Вы пользуетесь, чтобы убедится что ничего не сломалось, а изменения функционируют так-как надо?

P.S. Похоже меня этот вопрос беспокоит больше остальных, так как у меня проблемы с внимательностью и скоростью мышления и уже давно понял, что полагаться на чтение изменений я не могу (читаешь код, особенно собственный и думаешь, что это работает, а на самом деле это не работает).

P.P.S. Я понимаю, что без формальной верификации всего ПО (что очень часто практически неосуществимо, да и в процессе самой верификации тоже можно допустить ошибку) все ошибки не отловить, поэтому в теме сообщения написал многие, а не все возможные ошибки, имея ввиду многие критические ошибки и ошибки нарушающие задуманную логику хода программы.

[Zealint]

К сожалению, я не знаю другого способа, кроме как тестирование. Тесты придумываются заранее. Запускаются до и после изменений. Тесты подбираются так, чтобы по возможности "проходить" по как можно большему числу веток программы и чтобы задействовать все возможные граничные и крайние случаи.

Запускать тесты можно также в режиме отладки, где, если есть возможность, надо добавить автоматические проверки (добавляемые компилятором) на выходы за границы массивов, деления на ноль и прочие типичные глупости.

А ещё, как я уже советовал ранее, надо учиться писать программы в блокноте, которые при этом СРАЗУ бы компилировались и работали правильно. Это сильно повышает способность писать сразу правильный код и видеть его самые глубокие связи.

[creative]

Zealint в сообщении #388298 писал(а):

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

А как быть с написанием тестов когда речь идет об изменении исходного кода для сервера, у которого нет unit tests, где есть куча таймеров и прочего добра? То есть когда разрабатываешь с нуля, то с самого начала можно предварительно писать автоматические тесты сопровождающие исходный код и это не так сложно представить.
Вот смотрю я на этот сервер, где проблему можно смоделировать только соединившись с debugger к master и worker процессу, расставив контрольные точки и просматривая control flow измененных участков кода. Но способ ручного тестирования не очень эффективен, хотя и без него тоже плохо.
То есть как быть в таком случае с написанием автоматических тестов?

Zealint в сообщении #388298 писал(а):

Запускать тесты можно также в режиме отладки, где, если есть возможность, надо добавить автоматические проверки (добавляемые компилятором) на выходы за границы массивов, деления на ноль и прочие типичные глупости.

Пока граничные условия я контролирую (с переменным успехом) расставляя assertions.

Zealint в сообщении #388298 писал(а):

А ещё, как я уже советовал ранее, надо учиться писать программы в блокноте, которые при этом СРАЗУ бы компилировались и работали правильно. Это сильно повышает способность писать сразу правильный код и видеть его самые глубокие связи.

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

[caxap]

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

Ну и, конечно, любой нормальный проект должен иметь стабильные и тестовые версии.

[creative]

Кстати в любой ли большой программе есть debug logging?
И как часто достаточно большое ПО имеет unit tests?

[Zealint]

Цитата:

То есть как быть в таком случае с написанием автоматических тестов?

А я и не имею в виду автоматические тесты. Я говорю о ручном и кропотливом тестировании. Никуда не деться - либо голова плохо варит, тогда надо сутками сидеть и тестировать, либо голова хорошо варит, тогда код получается почти всегда правильным. К сожалению, такова жизнь.

Цитата:

Пока граничные условия я контролирую (с переменным успехом) расставляя assertions.

Ну или так, главное делать это как-нибудь так, чтобы потом одним движением убрать / добавить можно было.

Цитата:

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

Вы, наверное, не поняли. Надо писать такие программки с нуля как раз для того, чтобы с легкостью разбираться в любом другом исходном коде. И как раз, научившись хотя бы 1000 строк писать без отладчика (на примере простых задач), вы сможете предвидеть очень многое в любом другом коде. Надо тренироваться. Либо так, либо суточные мучения с многократным прогоном тестов. Выбора-то нет, как вы сами видите. Лично я более лёгкого способа не знаю.

[creative]

Zealint в сообщении #388473 писал(а):

Вы, наверное, не поняли. Надо писать такие программки с нуля как раз для того, чтобы с легкостью разбираться в любом другом исходном коде. И как раз, научившись хотя бы 1000 строк писать без отладчика (на примере простых задач), вы сможете предвидеть очень многое в любом другом коде. Надо тренироваться. Либо так, либо суточные мучения с многократным прогоном тестов. Выбора-то нет, как вы сами видите. Лично я более лёгкого способа не знаю.

Помогут ли в этом задачи, которые даются на TopCoder или Google Code Jam?

[Zealint]

creative в сообщении #388482 писал(а):

Помогут ли в этом задачи, которые даются на TopCoder или Google Code Jam?

Все поможет. Но лучше всего помогут timus или sgu. Решить придется несколько сотен. Лучше тысячу. А для этого придется прочитать кучу книг по алгоритмам. На все это уходит несколько лет, так что если вы еще учитесь, то самое время начать, а если уже нет, то, наверно, поздновато. Хотя воля и желание человека непредсказуемы... Просто я считаю, что работать чисто программистом после определенного возраста (~28 лет) уже как-то неправильно. ИМХО. Поэтому натаскиваться надо до этого момента.

[Sanyok]

Имхо, единственный нормальный способ - рефакторинг + тестирование.
Особенно, если имеет место вот такая ситуация:

Цитата:

читаешь код, особенно собственный и думаешь, что это работает, а на самом деле это не работает

.
Имхо, никогда не надо полагаться на "внимательность и скорость мышления".
Пишите код так, что бы он состоял из отдельных кусков (небольших), и каждый кусок можно было протестить отдельно от всего остального кода. Пусть этих кусков будет 100 штук по 150 строк каждый - их все по отдельности протестить будет легче, чем всю программу целиком.
Не знаю, может я наивен - недавний мой проект, который я считаю несколько меньшим средних размеров состоит примерно из 7,5 тыс. строк кода.
Возможно при 100 тыс. строк уже надо врубать "внимательность и скорость мышления" на полную. Но мне что бы столько написать надо 5 лет пахать без остановки.

[creative]

Zealint в сообщении #388659 писал(а):

Все поможет. Но лучше всего помогут timus или sgu. Решить придется несколько сотен. Лучше тысячу. А для этого придется прочитать кучу книг по алгоритмам.

Почему timus лучше Code Jam или TopCoder. Например, на TopCoder задачи отсортированы по уровню сложности и там очень легко тренироваться, если выбрал уровень по силам.

Zealint в сообщении #388659 писал(а):

На все это уходит несколько лет, так что если вы еще учитесь, то самое время начать, а если уже нет, то, наверно, поздновато. Хотя воля и желание человека непредсказуемы... Просто я считаю, что работать чисто программистом после определенного возраста (~28 лет) уже как-то неправильно. ИМХО. Поэтому натаскиваться надо до этого момента.

(Оффтоп)

Я начинал программировать в 1994 году, когда был в третьем/четвертом классе на своем ZX Spectrum (у меня сборка "Компаньон 2" ). Программировал по немногу до 2001 года, но дошёл до уровня ассемблера (у меня небыло транслятора, поэтому приходилось вводить опкоды вручную ). С 2001 года появился Pentium 166 с ОС Windows 98 и под влиянием этой ОС (т.е. её негласной идеологии и интерфейса) я вышел из программирования на 5 лет. С 2006 года опять начал изучать программирование под *nix. C 2007 года начал активней изучать программирование. Осенью 2008 года я понял, что без математики и алгоритмов я рискую стать быдло-кодером (которые уже успели наводнить веб своим ужасным кодом и знаю я это далеко не по наслышке), поэтому начал изучать математику и алгоритмы (до этого уже набрал кучу знаний по работе *nix), изучал математику с нуля в прямом смысле слова (до этого знал только арифметику). С осени 2009 года по осень 2010 года изучал исходный код Apache httpd и nginx и писал модули (на самом деле написал всего два модуля , но их код надежен). И сейчас я устроился работать программистом (не стажером).
Сейчас мне 26 с половиной лет. У меня мало практического опыта в программировании, но я достаточно изучил основы и могу хоть и медленно прочитать и разобраться в описании алгоритма с математическим доказательством (т.е. могу открыть какую нибудь главу у Кнута и разобраться в ней, но очень медленно). И ещё я заметил, что многие программисты (особенно веб программеры и они наверняка не читают этот форум ) даже будучи закончив университет (я не заканчивал) знают теорию хуже (если быть более точным, то они вообще её незнают), чем я.

Что Вы можете сказать на счет всего этого? Есть у меня шансы добраться до серьезного уровня к 35 годам? (даже если Вы скажете нет, я все равно попробую достичь его ради спортивного интереса).

P.S. Так как тема не в "свободном полете", то лучше ответить в офтопике, чтобы не смешивать главную тему обсуждения.

[Sanyok]

creative, думаю, Вы зря засунули последний кусок текста в offtop. :) Оно напрямую относится к обсуждаемой проблеме. Математика и алгоритмы - это, конечно, хорошо. Но в большинстве случаев имеются библиотеки, в которых эти алгоритмы уже реализованы, нужно только эти библиотеки уметь подключить. Имхо, Ваши проблемы - это не проблемы с математикой. Вам нужно почитать что-то по Software Engineering. Особенно советую - Ален И. Голуб "Веревка достаточной длины...", первые 2 главы. По словам автора (во вступлении в первую главу):

Цитата:

Эта глава вместе с последующей, посвященной разработке, являются наиболее туманными главами в
этой книге. Правила здесь довольно общего характера по своей природе, они совсем не затрагивают
техники программирования на С или С++, а скорее рассматривают более общий процесс
проектирования и разработки программы.

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

P.S. Можно узнать, какого размера Ваша программа (та, с которой у Вас проблемы при внесении изменений)?
P.P.S. Может, статический анализатор кода Вам чем-то поможет? Или уже пробовали?

[Zealint]

Цитата:

Почему timus лучше Code Jam или TopCoder. Например, на TopCoder задачи отсортированы по уровню сложности и там очень легко тренироваться, если выбрал уровень по силам.

Ну, на самом деле, когда я был на 6 лет младше вас сейчас, то просто брал тот же sgu и решал задачи подряд одну за другой. На некоторые уходил целый месяц, на некоторые - полторы минуты, но мне было все равно, я взял за правило решать именно подряд, не перепрыгивая. В конце концов, решил все, что там было к тому моменту (первый том и 20-30 задач из второго). Я не делил задачи на сложные или простые, поэтому меня это совершенно не парило. Есть задача, её сдали другие участники - значит её можно решить. Аналогично было на timus, но там я решал не подряд. 2 или 3 первых тома у меня были сданы, по-моему, без одной-двух задач. Совсем не помню...

Цитата:

Я начинал программировать в 1994 году

А я позже : ) Причем значительно позже. И уже сейчас я не вижу в программировании ничего интересного самого по себе. К вашему возрасту надо думать о более серьезных вещах. Например, я до сих пор программирую свои задачи сам только потому, что пока этого никто из моих учеников лучше сделать не может. Как только подрастут мои ученики, забью нафиг. Нужно переходить на более глобальные и более сложные задачи - прорабатывание идеологии, управление, координация исследовательской группы и т. д. Поэтому пока вы ставите себе такую незначительную цель - научиться писать программы достаточно быстро и аккуратно - вы ничего не добьетесь, это ложная ценность современного общества. Так как когда этому научитесь (пусть, к 35 годам), у вас больше ничего не будет.

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

Цитата:

Что Вы можете сказать на счет всего этого? Есть у меня шансы добраться до серьезного уровня к 35 годам? (даже если Вы скажете нет, я все равно попробую достичь его ради спортивного интереса).

Еще раз повторю: я даже статус Чемпиона Мира по программированию не считаю серьезным. Серьезно - это когда вы решили научную проблему. Или хотя бы можете предъявить новые факты, способствующие её решению. Для этого нужно быть лучшим в мире в той научной области, которой занимаетесь. Это минимум, я к этому сейчас иду. Но это лишь одна из нескольких параллельных целей. Самая простая. Так что и вам советую думать несколько шире в этой жизни.

Например, точно также можно стать гениальным игроком в StarCraft или Quake, за это бабла платят гораздо больше.

[creative]

Sanyok

Я понимаю о чем Вы говорите, но думаю у меня проблемы не уровня проектирования, так как я понимаю, что такое слои уровней абстракции, изоляция данных, и прочее. То есть в состоянии отличить ugly hack от нормального изменения.
Проблема именно в таких "мелочах", тут забыл проверку поставить, там не учел граничное условие, тут вызвал функцию но не учел некоторые побочные эффекты, тут забыл буфер очистить и т.д.

Zealint

(Оффтоп)

Я конечно понимаю, что доказать эквивалентность P и NP фундаментально и круто. И начиная с совсем прикладных вещей я в процессе изучения, все же склоняюсь к чтению более фундаментальной литературы. Ну и вообще на определенном уровне всегда остается голая математика, чистая абстракция. Но до этого я уже точно не успею добраться, хотя и не перестаю почитывать.
Не думаю, что программирование это "низкая" цель, так как это слишком широкая область, от чисто прикладного, до алгоритмического и тесно сплетенного с математикой. Можно написать веб-страничку, а можно написать искусственный интеллект.

На самом деле я так и не понял, почему TopCoder или Code Jam хуже.

[Zealint]

Цитата:

Я конечно понимаю, что доказать эквивалентность P и NP фундаментально и круто.

Нет, дело не в том, что круто.

Цитата:

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

Опять же, когда научитесь программировать, поймете, что ничего больше кроме этого не умеете. А к 35 годам, как вы говорите, студенты будут предпочтительнее вас в силу более скорого мышления. Так обычно и происходит. К этому моменту нужно успеть занять руководящую должность. Искусственный интеллект написать нельзя - это не из области программирования. Веб страничка - это вёрстка, но не программирование. Веб-сайт, наверно, вы имели в виду. Вообще, разделяйте Computer Science и программирование - это разные области. В нашем гнилом обществе нужны прикладные науки, вот все ими и занимаются. Развитие фундаментальных для многих - круто, но сколько круто, столько же и непонятно, почему им надо этим заниматься.

Цитата:

На самом деле я так и не понял, почему TopCoder или Code Jam хуже.

С моей точки зрения, задачи там проще. На том же ТопКодере они рассчитаны на полтора часа. На тимусе или сгу они берутся из соревнований, рассчитанных на 5 часов. Кроме того, эти задачи составлены, в основном, российскими тренерами по программированию и в 100500 раз интереснее буржуйских. На топкодере тоже бывают такие, но мало. Вообще, это ИМХО, разумеется. Поэтому поймете вы меня или нет, зависит от вашего субъективного представления.

[Sanyok]

creative, вот это:

Цитата:

Проблема именно в таких "мелочах", тут забыл проверку поставить, там не учел граничное условие, тут вызвал функцию но не учел некоторые побочные эффекты, тут забыл буфер очистить и т.д.

абсолютно нормальные вещи для среднего человека, какими мы в большинстве своем являемся (я, Вы, и многие другие не-Эйнштейны:) ) Вы читали книгу "Экстремальное программирование: разработка через тестирование" (атор Кент Бек)? Очень помогает избавиться от дурацких комплексов типа "я такой тупой", "у меня проблемы с внимательностью" и т.п. Да у всех такие же проблемы! Читая книгу Кента Бека у Вас может появится ощущение, что автор "ну такой тупой, что сил нет". :) Однако оказывается, решение сложных задач (т.е. написание большого объема кода без ошибок) под силу даже такому тупице, как автор :). Если у Вас есть готовая система без набора тестов, которую писали не Вы (или Вы, но не подумали снабдить ее тестами), самое время написать тесты сейчас. Прежде чем вносить изменения в какое-то место, напишите набор тестов, который проверяет это место. Вы утверждаете, что Ваша проблема не в проектировании, стало быть Ваша система не является одним неделимым целым, а состоит из частей, каждую из которых можно тестировать независимо от других.
Набор тестов должен быть таким, что если Вы намеренно внесете какую-то ошибку в тестируемый модуль, тесты немедленно должны ломаться. И наоборот, когда перед внесением изменений Вы будете писать тесты для проверки казалось уже отлаженного кода - постарайтесь написать тест, который будет ломать уже работающий код код. Например, напишите тест, который приводит к нарушением граничных условий. Он не должен проходить нормально, а должен падать с соответствующим сообщением от тестируемого модуля (желательно, модуль должен писать детальное сообщение об ошибке в лог, с информацией о том, в каком месте (файл, номер строки) произошла ошибка ).
И наконец, напишу, что же такое тест. Я пишу это не потому, что думаю, что Вы этого не знаете. Дело в том, что я сам долго не понимал, что означает словосочетание "тестовая программа". Так вот, тестовая программка для какого-то модуля или класса - это просто программа, которая использует этот модуль или класс. По возможности, использует "на полную катушку". Так что в некотором смысле, любая программа, в которой используется Ваш модуль или класс, является тестом Вашего модуля или класса.