Каковы некоторые варианты будущей проверки вашего приложения?

Question

Я смотрю на минимизацию будущего воздействия на еще не написанное приложение. Я стараюсь избегать любых сторонних продуктов и даже избегать вызовов конкретной системы. Может ли кто-нибудь предложить другие способы будущей проверки приложения. Идея не должна была бы переписывать основные части через 10 или 20 лет и что только техническое обслуживание (исправления ошибок) когда-либо понадобится.

Answer 1

Если вы хотите, чтобы ваша программа продолжала работать (на современных ОС) в течение такого периода времени, вам, вероятно, придется писать ее только в чистом ANSI C (или C++). Что-нибудь еще, вероятно, понадобится примерно вид настройки на протяжении многих лет - и никто не знает, что произойдет в течение следующих 10-20 лет.

Тем не менее, вот несколько советов, чтобы свести к минимуму такого рода проблемы:

1. Избегайте странные зависимости. Если вы собираетесь зависеть от какой-либо библиотеки, убедитесь, что очень хорошо зарекомендовал себя (и таким образом, вероятно, выжить как минимум 5 из этих 10-20 лет) или, по крайней мере, с открытым исходным кодом, чтобы вы могли развить его самостоятельно если потребуется.
2. Избегайте вызовов, специфичных для ОС. Это будет балансирующий акт с 1. - вы можете использовать библиотеку-обертку, такую ​​как boost или Qt, или glib или что-то есть, но это увеличит вероятность проблем совместимости на этом фронте.
3. Документировать все. Факт, независимо от того, как сильно вы пытаетесь, эта программа потребует исправлений совместимости и исправлений ошибок, а также, возможно, дополнений. Так что облегчите жизнь этому бедному программисту по обслуживанию, который приходит через 15 лет. :)

Answer 2

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

Answer 3

Откажитесь от 10 и 20-летних программ, которые по-прежнему работают на сегодняшних машинах и видят, почему они все еще работают и почему они ценны. Я вижу, что ряд приложений, основанных на вычислениях, на консольных приложениях все еще используются редко, в основном написанные на C и FORTRAN, называемые другими приложениями. Если в вашем приложении много графического интерфейса, уверены ли вы, что он по-прежнему будет иметь значение за несколько десятилетий? Возможно, рассмотрите разделение пользовательского интерфейса от основной функциональности таким образом, что пользовательский интерфейс может быть заменен в будущем, поскольку парадигмы пользовательского интерфейса меняются и развиваются. Если вы пишете свою систему очень модульно, модули, которые все еще обеспечивают ценность, могут быть сохранены, а те, которые явно устарели, могут быть заменены.

Answer 4

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

Answer 5

Лучший способ создать приложение, которое по-прежнему работает с минимальным обслуживанием в течение 10 лет, - это посмотреть на системы, которые были построены и продолжают работать с 10 лет назад.

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

Сопровождающие решили отказаться от улучшения производительности из-за закона Мура или улучшения удобства использования в пользу мало-технического обслуживания на протяжении многих лет.

Answer 6

Многие приложения, которые я разрабатываю, запускаются по циклу (пример: ежегодно). Самое главное, что я делаю, чтобы они продолжали работать, - это не жесткие даты кодирования или диапазоны дат.Пример:

• year(now()) за год
• DateSubmitted BETWEEN year(now()) AND DATEADD(year,1,year(now())) для диапазона

Конечно, это только примеры.