Как я могу выжить в моем коде? (anti software rot)

Ответ 1

• Построить на фреймворках/библиотеках/платформах, которые имеют прочную историю.

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

• Выберите платформу, которая выглядит так, как будто она будет на некоторое время.

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

• Напишите чистый код.

  Избегайте взлома любой ценой, напишите текстовый код, используйте только официальные вызовы API.

• Не полагайтесь на недокументированное поведение. (по популярности)

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

• Следите за устаревшими API-интерфейсами или теми, кто кажется кандидатами на устаревание.

  Никогда не используйте первое, попросите богов для последнего.

• Оставайтесь в цикле и поддерживайте.

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

Ответ 2

Я сомневаюсь, что современный UNIX содержит какой-либо из оригинальных кода Кена Томпсона (Linux, конечно же, нет), но он все еще известен как создатель UNIX. Причина, по которой кодовая гниль влияет на кодовые базы, заключается в том, что люди перестают использовать скомпилированный код, поэтому больше нет причин для его поддержания. Поэтому, если вы хотите, чтобы вы могли указывать вещи своим внукам, вам нужно придумать концепцию (а не только код), которую люди захотят использовать через 40 лет или около того. И это сложно.

Ответ 3

Здания остаются в течение длительного времени, потому что они поддерживаются. Когда вокруг нет людей, здания не будут длиться долго (посмотрите на никогда не открывшийся themepark в Цернобыле). Для программного обеспечения он является симулятивным, но обе конструкции как деградация могут идти намного быстрее.

Убедитесь, что программное обеспечение, которое вы создаете,  * ценный для общества  * является открытым исходным кодом (так что другие возьмут на себя работу по переподготовке, обновлению кода в мире и доступным библиотекам) ИЛИ вы сохраняете среду, в которой она работает вживую; но это будет нелегко.

В наши дни намного проще сохранить бинарные артефакты; виртуализация и эмуляция очень хороши. Вы можете эмулировать C64 на вашей многоядерной машине Wintel с несколькими ГГц.

Удачи!

Ответ 4

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

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

Ответ 5

Часто это вопрос хорошего дизайна библиотеки, независимо от того, думали ли разработчики о обратной совместимости или нет.

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

Если вы можете, сохраните точные версии сторонних компонентов, которые вы использовали вместе с вашими проектами.

Что касается языка программирования или ОС, который вы используете, это не имеет большого значения. Более важно ограничить зависимость от сторонних компонентов или на экспериментальных, но не зрелых технологиях.

Ответ 6

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

Поставщики ОС сталкиваются с подобными проблемами, потому что они хотят сохранить существующее программное обеспечение в новых версиях своей ОС. Они также пошли виртуально, чтобы достичь этого (например, режим Windows XP для Windows 7).

Ответ 7

Короче говоря, подумайте о мультиплатформенном!

Компания, с которой я работал, использовала С++ для разработки некоторых программных подсистем. Вместо использования одного компилятора поставщика (который был бы gcc) для каждой платформы использовался другой компилятор (gcc для Linux, компилятор HP для HP-UX и компилятор Sun для Solaris). Это заставило код писать так, чтобы не использовать нестандартные функции любимого компилятора; еще одно преимущество заключалось в том, что каждый компилятор выдавал разные предупреждения, чтобы еще больше повысить устойчивость к работе солодки. Кроме того, Java-часть программного обеспечения запускается в разных JVM, поэтому были обнаружены и обработаны небольшие несогласованности записи, когда-то выполнявшиеся везде, принципы.

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

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