Как различить тривиальное и нетривиальное программное обеспечение? [закрыто]

Так что же делает программу тривиальной?

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

Например, много раз по вопросу о модульном тестировании я слышал «если это не тривиально, вам потребуется модульное тестирование».

Я собираюсь выйти на конечности здесь и сказать:

Тривиальная программа - это программа, которая напрямую не влияет на бизнес.

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

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

• Он маленький.
• Короткая жизнь
• Нет необходимости в дальнейшем продлении.
• Только один разработчик.

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

Тривиально это ...

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

В корпоративной среде я бы добавил это:

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

Я бы определил тривиальную программу как ту, которая может быть разумно закодирована:

• В один присест.
• Как отдельный файл / модуль (при условии, что вы не программируете на Java или каком-либо другом языке, который вызывает сверхтонкое разбиение модулей).
• Любой приличный «мастер на все руки» программист, а не специалист.

Вот мои примеры "тривиальных" программ:

1. «Макетный» проект, который я настроил и начал кодировать, чтобы я смог опробовать образец технологии или пример кода. Нет намерения быть развернутым или даже показанным кому-либо.
2. Демонстрационный код написан для технических презентаций.
3. «Одноразовый». Я имею в виду быстрое приложение, которое мне пришлось создать, чтобы использовать один раз, потому что это странная ситуация с данными, которые нужно было перемещать определенным образом, или что-то, что затем будет немедленно заменено чем-то более постоянным.

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

Вот цитата, которую я видел в Usenet десять лет назад, сейчас она еще более актуальна.

Сложность программного решения обратно пропорциональна сложности объяснения того, что оно должно делать. - неизвестно

Программа, которая представляет собой просто набор методов getter / setter. Нет логики программирования. Может быть, что-то с несколькими петлями.

Это моё определение тривиально.

Наше рабочее определение: «от чего-то еще ничего не зависит».

К сожалению, было несколько тривиальных прототипов, которые стали нетривиальными продуктами производства.

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

Я знал одного программиста, который имел тенденцию использовать «тривиальный» в качестве синонима «даже не стоит обсуждать».