Экстраполяция IT

Теория избыточной информации, как подход к программированию. С ней я познакомился лет десять назад и совершенно забыл как она называется. Несколько раз были попытки восстановить знания гуглежом, но все тщетно. Быть может, кто-то знает правильное название этой штуки? Напишите в чат, пожалуйста. Сама теория очень простая и крайне очевидная: что-то, представленное в системе единожды является точкой отказа всей системы. Дублирование стоп-сигналов на автомобиле и двухфакторная аутентификация где-то об этом.

В программировании эта теория представлена в разных ипостасях, например в принципе «никому не доверяй». Это не о принципе работы в дружном коллективе, там и без этого принципа все не славабогу, а о взаимодействии между инкапсулированными участками кода (микросервисами или модулями, если угодно).

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

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

www.tgoop.com/itextrapolation/360

3.02K viewsedited  Jul 9, 2019 at 08:02

Теория избыточной информации, как подход к программированию. С ней я познакомился лет десять назад и совершенно забыл как она называется. Несколько раз были попытки восстановить знания гуглежом, но все тщетно. Быть может, кто-то знает правильное название этой штуки? Напишите в чат, пожалуйста. Сама теория очень простая и крайне очевидная: что-то, представленное в системе единожды является точкой отказа всей системы. Дублирование стоп-сигналов на автомобиле и двухфакторная аутентификация где-то об этом.

В программировании эта теория представлена в разных ипостасях, например в принципе «никому не доверяй». Это не о принципе работы в дружном коллективе, там и без этого принципа все не славабогу, а о взаимодействии между инкапсулированными участками кода (микросервисами или модулями, если угодно).

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

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

BY Экстраполяция IT