Як розмежувати тривіальне та нетривіальне програмне забезпечення? [зачинено]

То що насправді робить програму тривіальною?

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

Наприклад, багато разів у питанні одиничного тестування я чую, "якщо його дрібниці вам не потрібно буде провести одиничне тестування".

Я збираюся вийти на кінцівку тут і сказати:

Тривіальна програма - це та, яка не впливає безпосередньо на бізнес.

Виробнича фірма вважає, що її програмне забезпечення для бухгалтерського обліку є тривіальним, але програмне забезпечення, яке керує роботом-рукою, яка рухає киплячу сталь, є критичною. Вони можуть мати справу з помилками та низьким рівнем підтримки в першому, але не в останньому. Якщо є проблема, вони потребують її виправлення зараз .

Я вважаю, що найпоширенішим наміром цієї заяви є те, щоб програма мала такі характеристики:

• Це маленьке.
• Короткий термін експлуатації.
• Не потрібно подальшого продовження.
• Лише один розробник.

Викинувши його повністю, бінарні файли та джерела. Якщо хтось помічає, це було не банально.

Тривіально ...

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

У корпоративному середовищі я додам:

• щось, що ділові користувачі не проти чекати деякий час на виправлення.
• щось, що використовується внутрішньо, що не має офіційної підтримки з боку ІТ.
• що є пріоритетним серед найнижчих пріоритетів для бізнесу, коли робите планування ресурсів і планування.

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

• В одному сидінні.
• Як єдиний файл / модуль (припускаючи, що ви не програмуєте на Java чи якусь мову, що примушує супер дрібне розщеплення модулів).
• Будь-яким порядним програмістом "джек усіх торгів", а не фахівцем.

Ось мої приклади "тривіальних" програм:

1. "Фіктивний" проект, який я налаштував і почав кодувати просто так, щоб я міг випробувати технологію або зразок коду. Не має наміру розгортатись і навіть нікому не показуватися.
2. Демо-код, написаний для технічних презентацій.
3. "Разовий". Я маю на увазі швидку програму, яку мені довелося створити, щоб використати один раз, оскільки це дивна ситуація з даними, яку потрібно було певним чином перемістити, або те, що потім буде негайно замінено чимось більш постійним.

Програмного забезпечення Trival не існує, це коли ви почуєте вимоги і те, що буде тривалим, коли насправді це завжди не тривал

Ось цитата, яку я бачив на Usenet десять років тому, вона є ще актуальнішою зараз.

Складність програмного рішення обернено пропорційна складності пояснення того, що він повинен робити. - Невідомо

Програма, яка є лише безліччю методів просто геттера / сетера. Немає логіки програмування. Може щось із кількома петлями.

Це моє визначення тривіального.

Наше робоче визначення - це щось, від чого більше нічого не залежить ».

На жаль, було кілька тривіальних прототипів, які стали нетривіальними продуктами виробництва.

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

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