Сколько времени код длится?

Вот мои два цента:

Когда мы разрабатываем проект, мы обычно заявляем, что он рассчитан на «не менее» 5 лет. Обычно не более 10 лет, прежде чем мы его перепроектируем и построим заново. (Здесь мы говорим о проектах среднего и большого размера.)

Обычно происходит то, что новый проект, который вы создаете, должен заменить старый, либо с точки зрения технологии (например, переход от MF к Windows, VB к .net и т.д.), но этот проект никогда не заканчивается. Таким образом, ваш клиент в конечном итоге работает с 2 системами одновременно, и эта оставшаяся система будет позже называться «устаревшей».

Если вы подождете достаточно долго, появится третий проект, заставив клиент работать с 3 системами одновременно и так далее ...

Но отвечая на ваш вопрос, я бы поставил на 5-10 лет до редизайна,

ИМХО все сводится к мастерству изготовления: гордость, которую мы испытываем в своей работе, кодирование в соответствии со стандартами, которые нам не будет стыдно увидеть другой настоящий программист.

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

3-5 лет макс. После этого вы перешли на другую работу и оставили свой дрянной код.

Вопрос не в том, "Как долго длится код?" а скорее «Как долго элементы моего кода будут влиять на приложение?»

Даже если ваш код будет заменен, возможно, что он будет заменен кодом, который делает то же самое. В некоторой степени это прямая причина проблемы 2000 года. Более того, это прямая причина проблемы Y2038 .

Я всегда пытался писать код так, как будто мои приложения должны работать «вечно». Я очень уверен, что меня больше не будет в 2100 году, но знание того, что у моего программного обеспечения есть сборка, срок годности которой истекает, меня не устраивает. Если вы знаете о таких вещах, постарайтесь их избегать! Вы никогда не узнаете, но какой-нибудь неизвестный программист в будущем может быть вам благодарен.

Это зависит от того, насколько важен код для бизнеса и сколько ресурсов требуется, чтобы написать его с нуля. Чем больше ценности и ресурсов, тем дольше он работает. Для коммерческого кода «Работай, не трогай» - десять и более лет.

Ну, мы недавно создали формат метки времени, в котором время хранится в виде 64-битного целого числа без знака в микросекундах с 1970 года. Это будет длиться до 586912 года, чего должно быть достаточно.

Кодирование для «навсегда» не нужно - конечно, вы можете использовать BigInteger и тому подобное везде, но почему? Просто будьте готовы более 5 или 10 лет. В настоящее время производственный код двадцатилетней давности не является чем-то необычным, и я подозреваю, что в ближайшем будущем средний жизненный цикл станет еще длиннее.

Я не думаю, что код просуществует так долго. Подумайте обо всех изобретениях и прогрессе, достигнутых за последние 90 лет.

В 2100 году нам не нужно будет писать код. Будет какой-то интерфейс мозг-машина.

бессмертными словами Дэна Бернстайна: Не участвуйте в проблеме 10К!

Eternity.

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

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

На самом деле никто не знает. Профессиональное программирование существует уже 30-40 лет, поэтому никто точно не знает, прослужит ли код 100 лет. Но если ошибка 2000 года является показателем, то это означает, что большая часть кода будет оставаться намного дольше, чем предполагал программист. Имейте в виду, что даже если вы примете это во внимание, он все равно может оставаться дольше, чем вы ожидали. Независимо от того, сколько вы готовитесь, он все равно может пережить предполагаемую продолжительность жизни.

Мой совет - не планировать, что код прослужит 100 лет. Вместо этого постарайтесь убедиться, что весь ваш код будет работать одинаковое время, то есть его часть не должна выйти из строя через 2 года, а другая часть - через 100 лет. Помните, вы всегда должны сначала исправить самое слабое звено, поэтому нет смысла делать самое сильное звено сильнее.

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

Между прочим, я рекомендую иметь идентификатор проблемы (например, FogBugz номер дела) в каждом комментарии TODO, чтобы люди действительно могли подписаться на этот TODO и отслеживать его.

I have had occasion to be brought in on contract more than a decade after the fact to consult on porting code to a new platform (OS/2 just isn't that popular these days!). When in doubt, assume that your code will live longer than you will. At the very least, document the heck out of limitations like this; fix them unless that takes tremendously more work than to document them.

Предположим, что тот, кто будет поддерживать код, является психопатом и имеет ваш домашний адрес .

Также имейте в виду, что вы имеете в виду под последним.

Например, исходная операционная система UNIX была разработана 30 лет назад. Но за эти 30 лет продукт со временем развивался.

Хотя меня не удивило бы, если немного, кроме оригинального кода, все еще существует в нем сегодня.

Так что подумайте об этом двумя способами ... 1 ) вы когда-нибудь противодействуете коду, который будет затронут в будущем, 2) продукт / код будут развиваться, если у вас будет поддержка и участие.

Важнейшее Вот такие вещи:

1. Насколько хорош ваш внутренний класс даты (получите очень надежную версию библиотеки и придерживайтесь ее!)

2. Это не только время, но и рост диапазона входных данных, которые нужны вашим пользователям. Например, возможно, у вас есть 30-летняя ипотека, но в следующем месяце кто-то решит ввести договор аренды на 99 лет со сроком погашения 2110 или 100-летнюю облигацию Disney!

Если вы принимаете 2-значные данные для года с окном даты, подумайте очень тщательно о том, как это применяется к датам начала и окончания, и незамедлительно дать много отзывов.

В моем текущем магазине имеется большая база кода, которая запускает финансовые приложения со сложными бизнес-правилами. Некоторые из этих правил закодированы в хранимых процедурах, некоторые - в триггерах, а некоторые - в коде приложений 3gl и 4gl. Есть работающий код конца 90-х, и его нет на ваших «традиционных» устаревших языках, таких как COBOL или FORTRAN. Как можно догадаться, это дымящаяся куча спагетти-кода, большая часть из которых была создана до того, как TDD что-то значило, поэтому люди не хотят ничего трогать.

Есть примеры кода, работающего на старых машинах, которым 40 или 50 лет.

(Интересные биты в этом потоке: http://developers.slashdot.org/developers/08/05/11/1759213.shtml).

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

1) Что такое "активная жизнь" приложения - это то, где оно будет использоваться и обрабатываться.

2) Что такое "неактивная жизнь" приложения - это то, что оно не будет использоваться изо дня в день, а может быть использовано для поиска и просмотра старых записей. Например, закон об аудите Великобритании означает, что записи должны быть доступны в течение 7 лет, т.е. потенциально 7 лет с момента последнего использования системы.

3) Каков диапазон будущих данных, которые ему необходимо обрабатывать? Например, скажем, что вы снимаете срок годности кредитной карты - у вас может быть карта, срок действия которой не истечет в течение десятилетия. Сможете ли вы обрабатывать эту дату?

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

До тех пор, пока он не сломается или не перестанет быть полезным, а затем еще немного после этого

В 1995 году я начал работать на новой работе с 8-летней кодовой базой. Значит, это была дата начала примерно в 1987 году.

Код, вероятно, все еще используется . Это то что ? 23 года.
В компании произошли некоторые переезды, но они, вероятно, сохранили программное обеспечение (потому что оно работает) Если оно все еще работает, то через десять лет или около того оно будет работать. .

Это неудивительно, особенно высокотехнологичный код на C (в основном)

В 1999 году я начал работать на новой работе, кодовая база имела предшественников еще в 1984 году. Новая версия, которую я разработал в 2000-е годы все еще используются, с элементами дизайна, такими как форматы файлов данных из предыдущего (и так далее), и это будет программа развития более 26 лет.

Таким образом, проблема 2086 года начинает немного вырисовываться по мере того, как эти 32-битные подписанные time_t переносятся.

Помните, что одним из главных преимуществ современного программирования является повторное использование.

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

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