Как правильно писать программы?

[Sonic86]

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

-- Чт июл 08, 2010 08:23:14 --

Стива Макконелла я попробую прочесть и возможно выскажусь, если интересно.

[Scholium]

Sonic86 писал(а):

Вопрос у меня к бывалым программистам - реально ли взять и все-таки сразу написать код почти весь правильно, без такого занудного тестирования, просто из головы. Или все-таки процесс такого тестирования-исправления неизбежен - все равно на него придется потратить много времени? Я все-таки думаю, что можно.

Наверное, многое зависит от уровня задачи. Если математическая задача имеет элегантный алгоритм, то вполне возможна ее красивая реализация в «один присест» . Но если брать реальные задачи, хоть по математическому моделированию, хоть производственно-экономического профиля, вывод неизбежен – профессиональное тестирование это неотъемлемая часть жизни программиста, как сон для обычного человека. Поэтому нравиться это или нет, но к тестированию и отладке нужно относиться очень серьезно. Как по мне, «занудное тестирование» имеет в своей основе логическую природу. Если вы кодируете некий алгоритм, то всегда неявно подразумеваете его контекст, в котором он будет выполнятся. Например, обрабатываете содержимое файла. Если он имеет нужную вам информацию в нужном формате, то проблем нет – алгоритм обработки может быть простым. Но! Файл может отсутствовать – естественно, эту ситуацию надо отработать. Файл может быть, но не с тем содержимым. Следовательно, нужно проверять его формат и сигнатуру. Формат может соответствовать, но данные могут быть неверны. Например, вы ожидаете строку оканчивающуюся нулем, а нуля может не быть, а строка может быть «бесконечной». Структура файла (например, *.exe) может быть очень сложна, так что процесс контроля и допустимости значений может занять очень много кода. То же касается и «поведения» алгоритма. Сложный алгоритм сложно тестировать и искать логические ошибки в нем. Если говорить математическим языком, то тестирование (обработка всех принципиально возможных ситуаций, в т.ч. исключительных) это логическое замыкание алгоритма. По аналогии с замыканием открытых множеств. Причем логическое замыкание должно сопровождаться механизмом вывода в поток (файл, окна сообщений или отладки и т.п.) протокола выполнения программы. Анализируя который, всегда можно найти причину сбоя, в т.ч. логического. Для примера, можно посмотреть реализацию сложного (для понимания) нового алгоритма сортировки (учитывающего естественное частичное упорядочивание, в любом порядке, даже в случайно распределенных последовательностях), в статье Внешняя сортировка «естественным слиянием». Отладка этого алгоритма заняла много времени, но только используемая система тестирования помогла осуществить ее за обозримое время. Хотя говорить о полном логическом замыкании предложенного алгоритма еще не приходится, тем не менее, это хороший пример.

[ewert]

Sonic86 в сообщении #337875 писал(а):

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

Могу предложить совсем простенькую задачку -- запрограммировать решение линейного дифура второго порядка с постоянными коэффициентами: $y''(x)+ay'(x)+by(x)=0$ (входные данные -- коэффициенты уравнения, начальные условия и точка наблюдения; все рабочие формулы общеизвестны). Вы удивитесь, насколько это нетривиально.

[Sonic86]

Scholium
Понятно. Буду привыкать тестировать тоже. В общем буду надеятся на лучшее.
Мне понравилось Ваше $2e-3$ из статьи. Я вот помню, мы когда ГСЧ проходили, там говорилось, что у ГСЧ должно быть в среднем $\frac{2}{3}$ поворотных точек (т.е. таких $j: (a_j-a_{j-1})(a_j-a_{j+1})<0$). Правда доказательства я не видел или не помню... Интересно, это как-то связано с Вашим $2e-3$ или нет...

ewert писал(а):

Могу предложить совсем простенькую задачку -- запрограммировать решение линейного дифура второго порядка с постоянными коэффициентами: $y''(x)+ay'(x)+by(x)=0$ (входные данные -- коэффициенты уравнения, начальные условия и точка наблюдения; все рабочие формулы общеизвестны). Вы удивитесь, насколько это нетривиально.

Серьезно!?

(Оффтоп)

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

[ewert]

Sonic86 в сообщении #337904 писал(а):

Серьезно!?

Вполне.

Вы попробуйте -- сами увидите. Только так, естественно, чтобы она работала надёжно во всех диапазонах параметров.

Я с этим столкнулся, когда лет 15 назад довелось решать модельную задачку по расчёту спектра оператора Шрёдингера с кусочно-постоянным потенциалом. И вот как раз на этом-то месте и пришлось хоть немножко, но помучиться.

[creative]

Sonic86 в сообщении #337875 писал(а):

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

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

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

Но понять как это делать можно только со временем.

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

Sonic86 в сообщении #337875 писал(а):

Стива Макконелла я попробую прочесть и возможно выскажусь, если интересно.

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

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

[Sonic86]

creative
Насколько я помню к хорошему коду относится код с комментариями команд и правильно названных переменных? Тогда надо будет на работе попробовать писать коменты, их почти нету... Хотя писать наверное надо будет много - сплошная предметная область (почта). Сам по себе мне итеративный подход нравится, хотя из-за его универсальности.
С кодом дома я уже разобрался. Я просто опыт свой обдумывал на будущее...

[creative]

Sonic86 в сообщении #337924 писал(а):

creative
Насколько я помню к хорошему коду относится код с комментариями команд и правильно названных переменных? Тогда надо будет на работе попробовать писать коменты, их почти нету... Хотя писать наверное надо будет много - сплошная предметная область (почта). Сам по себе мне итеративный подход нравится, хотя из-за его универсальности.
С кодом дома я уже разобрался. Я просто опыт свой обдумывал на будущее...

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

[Scholium]

Sonic86 писал(а):

Scholium
Понятно. Буду привыкать тестировать тоже. В общем буду надеятся на лучшее.
Мне понравилось Ваше $2e-3$ из статьи. Я вот помню, мы когда ГСЧ проходили, там говорилось, что у ГСЧ должно быть в среднем $\frac{2}{3}$ поворотных точек (т.е. таких $j: (a_j-a_{j-1})(a_j-a_{j+1})<0$). Правда доказательства я не видел или не помню... Интересно, это как-то связано с Вашим $2e-3$ или нет...

Спасибо за интерес!

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

Кстати, эту статью я сейчас перевожу на буржуйский язык, чтобы опубликовать ее на http://www.codeproject.com/. Очень рекомендую обратить на этот сайт внимание. Многие молодые программисты нашли работу за рубежом после публикации нескольких своих статей и кода на этом сайте. Там есть прекрасная система ранжирования и оценки популярности Вас, как программиста. Пару человек признались, что на них даже обратил внимание «отец американского программирования» и они получили работу в самом Microsoft. Короче, лучшей возможности раскрутить себя за рубежом трудно найти. Кроме популярности, Вы получите опыт, ибо объяснить в статье работу своей программы и привести ее оптимальный код, да еще на другом языке это очень хороший треннинг для собственной квалификации и сатисфакции. Не обязательно публиковать шедевры. Например, у меня наибольшим рейтингом пользуется статья, которую лично я оцениваю как самую слабую .

-- Чт июл 08, 2010 13:51:10 --

ewert писал(а):

Могу предложить совсем простенькую задачку -- запрограммировать решение линейного дифура второго порядка с постоянными коэффициентами: $y''(x)+ay'(x)+by(x)=0$ (входные данные -- коэффициенты уравнения, начальные условия и точка наблюдения; все рабочие формулы общеизвестны). Вы удивитесь, насколько это нетривиально.

А чем не устраивает Maple 13? Только тем, что его не было 15 лет назад?

[ewert]

Scholium в сообщении #337929 писал(а):

А чем не устраивает Maple 13? Только тем, что его не было 15 лет назад?

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

[Scholium]

ewert писал(а):

Scholium писал(а):

А чем не устраивает Maple 13? Только тем, что его не было 15 лет назад?

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

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

[ewert]

Scholium в сообщении #337936 писал(а):

Так что сам факт неожиданного удвоения усилий не кажется чем-то особенным, разве что тем, что этот коэффициент слишком мал. Однако предлагать подобные задачи не резон. Ибо они слишком стандартны, а потому малоинтересны.

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

Это -- одна причина, по которой отладка программ практически неизбежна. Другая -- в том, что сами требования, предъявляемые к программе, заранее часто не определены. Вот ещё пример: составить программу, генерирующую однородный набор учебных задач. Ну, скажем, систем линейных уравнений. Тривиально, да? Да, только системы на выходе должны получаться "хорошими". А в каком смысле "хорошими"?...

[worm2]

ewert писал(а):

А в каком смысле "хорошими"?

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

-- Чт июл 08, 2010 19:01:37 --

В более сложных случаях, увы, мне приходилось вручную возиться с каждым примером

[ewert]

worm2 в сообщении #337959 писал(а):

ewert писал(а):

А в каком смысле "хорошими"?

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

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

[SSerge]

Sonic86 в сообщении #337875 писал(а):

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

Системы контроля версий не зря придуманы. Очень рекомендую. Хотя бы SVN (Subversion) для начала.