Это плохая практика для создания программного обеспечения, которое не будет работать в историческую дату?

Question

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

У меня есть функция, которая автоматически генерирует следующий номер логического элемента.Часть этого номера элемента включает год, когда был создан номер элемента.Сейчас мы находимся в 2010 году, поэтому наиболее значимая часть даты (для целей моего номера изделия) - «10» и длиной два символа.Если моя программа будет выполнена в 2009 году, в том виде, в котором она в настоящее время закодирована, я получу неверный номер элемента, потому что моя система ожидает двухзначную дату (10), а не одну цифру (9).

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

Answer 1

Совершенно верно сказать: «Моя программа не будет работать с историческими данными».В вашем конкретном случае «исторические данные» были существом до 1 января 2010 года. Я категорически не согласен с теми, кто говорит, что вообще плохая идея - налагать такие ограничения на ваш код.

Мы живем с этимиограничения каждый день.Например, стандарт UNIX time_t имеет диапазон плюс-минус около 68 лет.Приложения, в которых даты и время хранятся с time_t, не могут представлять дату до 1901-12-13 или после 2030-01-19.И все же миллионы приложений написаны с использованием этого формата времени.Но мы не слышим, чтобы кто-то утверждал, что эти программы как-то плохи.

Создание приложений - это компромисс.Если, по вашему мнению, нет необходимости указывать даты, превышающие какой-то произвольный момент в прошлом или даже в будущем, тогда это нормально.Это ничем не отличается от разработки системы, которая будет хранить только X записей, или развертывания с диском объемом 1 терабайт, зная, что в конечном итоге вам придется обновляться по мере роста ваших данных.Дело в том, что мы не можем разрабатывать для всех случаев.

Те, кто утверждает, что «ошибка 2000 года» показывает, почему вы не должны устанавливать произвольные ограничения в своем коде, не продумывают вещи.В конце концов, 4-значный год также является произвольным ограничением.Что, если я хочу представить дату в 10 000 лет в прошлом или будущем?Это чертовски ошибка Y10K!В какой-то момент мы накладываем ограничение на диапазон вещей, которые мы поддерживаем.

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

Answer 2

Я думаю, вы слышали о ошибка y2k ?Так что да, это плохая практика.

Answer 3

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

Answer 4

Серая зона.Я думаю, что хорошо писать код, который не будет работать, если текущая дата до 1970 года (Unix epoc).До текущего года, возможно, немного рискованнее.Даже помимо несчастных случаев, могут быть веские причины, по которым у людей установлены контрольные примеры с неправильными часами - регрессивные тесты на воспроизводимость и / или дату.

Если вам нужен короткий код, основанный на дате и выигранныйне оборачивайте слишком рано, тогда год - это примерно 2 ^ 25 секунд, так что вы можете разделить дату секунды с момента появления на нее и взять две шестнадцатеричные цифры.Это несколько удобочитаемо для человека, так как вы можете определить, является ли значение «недавним» или нет, но оно не настолько читабельно, чтобы люди полагались на него как на двузначный год.

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

Даже с десятичными цифрами вы понимаете, что могли бы написать 2009 как «09», верно?Для этого не нужно приводить к короткой строке; -)

Answer 5

Зависит от ваших требований к развертыванию, но, как правило, это определенно плохая практика.

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

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

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

* Например, для решения проблем с другим программным обеспечением, сделавшим необоснованные календарные предположения.