Малые изменения

[drraug]

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

Впрочем, хотел рассказать не об этом.

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

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

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

Comments

[gembercannelle.livejournal.com]

I don't think your methods belong to the stone ages. Fortran works infinitely faster than Matlab. I remember that a couple of years ago after waiting for Matlab for about 48 hours I got bored, rewrote everything in Fortran (2 and a half hours) and got beautiful pictures after 30 minutes.

"Small perturbations" recall KAM theory to my mind... when a very small change of parameters change the behaviour of the whole system completely.

[draug.livejournal.com]

Yeah, and the most important question is if this theory (and practice) is applicable to real life.

[pphantom.livejournal.com]

Так все делают. Даже те, кто пришел в вычислительное программирование с сильной и современной общепрограммистской подготовкой. Последние, правда, какое-то время дергаются и пытаются все писать "правильно", но быстро обнаруживают, что обычные методы в приложении к этим задачам предельно неэффективны. :)

[draug.livejournal.com]

Ну, приятно же чувствовать себя этаким олд-скулом ))

[pphantom.livejournal.com]

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

[draug.livejournal.com]

))

[gertovsky.livejournal.com]

Не бери дурного в голову. В этой стране на программистов не учат в принципе.

Объектно ориентируемый подход, паттерны проектирования, выбрасывание и ловля исключений на самом деле спорные концепции.

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

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

Первый работающий код де факто не аккуратен, на второй уже можно смотреть. Седьмую, восьмую версию можно комментировать, но до этого не доходить.

Я видел подпроект, в котором была (а может и есть) очень редкая ошибка. Разобраться в проекте было невозможно, 95% кода реализовывало всякого рода паттерны, и скрывало реальный код. Так смотришь вроде все на месте, а пару раз в месяц идет сбой на 10 000 событий.