Лекция
Привет, Вы узнаете о том , что такое закон амдала, Разберем основные их виды и особенности использования. Еще будет много подробных примеров и описаний. Для того чтобы лучше понимать что такое закон амдала, теория разбитых окон, закон брукса, закон конвея, закон каннингема, число данбара, закон голла, закон гудхарта, бритва хэнлона, закон хофстадера, закон хатбера, цикл шумихи, закон хирама, закон кернигана, закон меткалфа, закон мура, закон мёрфи, бритва оккама, закон паркинсона, эффект преждевременной оптимизации, закон патта, закон рида, закон теслера, закон протекающих абстракций, закон тривиальности, философия unix, модель spotify, закон уодлера, закон уитона , настоятельно рекомендую прочитать все из категории Разработка программного обеспечения и информационных систем.
Здесь содержатся объяснения некоторых законов, принципов и закономерностей, но нет никакой агитации в их пользу. Применять их или нет – это всегда вопрос спорный, и все зависит от того, над чем вы работаете.
Принцип наименьшего знания
Закон Деметры (Law of Demeter, LoD) — набор правил проектирования при разработке программного обеспечения, в частности объектно-ориентированных программ, накладывающий ограничения на взаимодействия объектов (модулей).
Обобщенно, закон Деметры является специальным случаем слабой связанности (loose coupling). Правила были предложены в конце 1987 в северо-восточном Университете (Бостон, Массачусетс, США).
Говоря упрощенно, каждый программный модуль:
Общее описание правила: Объект A не должен иметь возможность получить непосредственный доступ к объекту C, если у объекта A есть доступ к объекту B и у объекта B есть доступ к объекту C.
Таким образом, код a.b.Method() нарушает Закон Деметры, а код a.Method() является корректным.
Преимущества
Преимуществами закона Деметры является то, что код, разработанный с соблюдением данного закона, делает написание тестов более простым, а разработанное программное обеспечение менее сложно при поддержке и имеет большие возможности повторного использования кода. Так как объекты являются менее зависимыми от внутренней структуры других объектов, контейнеры объектов могут быть изменены без модификации вызывающих объектов (клиентов).
Недостатки
Недостатком закона Деметры является то, что иногда требуется создание большого количества малых методов-адаптеров (делегатов) для передачи вызовов метода к внутренним компонентам.
Закон Амдала — это формула, демонстрирующая потенциал ускорения вычислительной задачи, которого можно достичь при увеличении количества ресурсов системы. Обычно он используется в параллельных вычислениях, и может предсказать наличие реальных преимуществ от увеличения количества процессоров с учетом ограничений параллелизуемости программы.
Приведем пример. Если программа состоит из двух частей – части А, которую необходимо исполнять на одном процессоре, и части Б, которую можно распараллелить, видно, что преимущества добавления нескольких процессоров к исполняющей программу системе ограничены. Потенциально это может сильно ускорить часть Б – но скорость части А не изменится.
На следующей диаграмме показаны примеры потенциального прироста скорости:
Как видно, даже если 50% программы можно распараллелить, преимущества от добавления более 10 отдельных процессоров будут незначительными. Если программу можно распараллелить на 95%, улучшения будут заметны даже после добавления тысячи процессоров.
С замедлением закона Мура и ускорения процессоров параллелизация становится ключом к улучшению эффективности. Прекрасным примером будет программирование графики – современное программирование на основе шейдеров позволяет отрисовывать фрагменты изображения параллельно, поэтому в современных графических картах можно встретить тысячи процессорных ядер (GPU или шейдерных модулей).
Теория разбитых окон утверждает, что видимые признаки преступлений (или отсутствие заботы об окружающей среде) влечет за собой увеличение количества и тяжести преступлений (и дальнейшее ухудшение окружающей среды).
Эту теорию применяли к разработке ПО, предполагая, что плохое качество кода (или т.н. "технический долг") может вызвать ощущение того, что все попытки улучшить качество будут проигнорированы или недооценены, что приведет к появлению нового плохого кода. Этот эффект развивается каскадно, из-за чего качество со временем ухудшается.
Добавление дополнительного человеческого ресурса к опаздывающему проекту задерживает его выход еще больше.
Закон Брукса говорит о том, что во многих случаях попытки ускорить выпуск проекта, который и так опаздывает, путем добавления к нему дополнительных людей, приводят к тому, что проект выпускают еще позже, чем могли бы. Однако Брукс подчеркивает, что это чрезмерное упрощение проблемы. Рассуждает он следующим образом: учитывая затраты на время, необходимое на ввод в строй новых ресурсов, и на общение людей между собой, в краткосрочной перспективе скорость развития проекта падает. Также многие задачи могут не подлежать разделению, то есть, их не получается легко распределить между ресурсами, количество которых увеличили, поэтому потенциальное увеличение скорости оказывается не таким значительным.
Распространенная присказка «девять женщин не могут родить ребенка за один месяц» относится к закону Брукса, в частности потому, что некоторые виды работ нельзя разделить или распараллелить.
Это главная тема книги «Мифический человеко-месяц».
Закон Конвея говорит о том, что технические ограничения проектируемой системы будут отражать структуру организации. Его часто вспоминают при попытке улучшить работу организации. Закон говорит, что если организация структурирована на множество мелких, не связанных между собой модулей, то и созданная ею программа будет такой же. Если организация будет построена вокруг вертикалей, опирающихся на определенные особенности или услуги, то и ее ПО будет отражать этот факт.
Лучший способ найти правильный ответ в интернете — не задать вопрос, а разместить заведомо неправильный ответ.
Стивен Макгиди говорит, что в начале 1980-х Уорд Каннингем дал ему совет: «Лучший способ найти правильный ответ в Интернете — не задать вопрос, а разместить заведомо неправильный ответ». Макгиди назвал это «законом Каннингема», хотя сам Каннингем отрицает его авторство и говорит, что его «неверно цитируют». Хотя изначально фраза относилась к общению в Usenet, с тех пор закон использовали для описания работы и других сообществ (Wikipedia, Reddit, Twitter, Facebook).
Число Данбара — ограничение на количество постоянных социальных связей, которые человек может поддерживать. Имеются в виду связи, предполагающие знание отличительных черт конкретного индивида, связь с которым необходимо поддерживать, его характера, а также социального положения, и его связей с другими людьми.
Точное число таких связей неизвестно. Сам Данбар предполагал, что человек с комфортом может поддерживать не более 150 таких связей. Он описывал его в более социальном контексте: «Количество людей, к которым вы не постесняетесь присоединиться без приглашения, чтобы вместе выпить, если вы случайно столкнетесь с ними в баре». Обычно оценки такого числа разнятся от 100 до 250.
Как и стабильные взаимоотношения между людьми, поддержка взаимоотношения программиста с кодом требует затрат сил. Сталкиваясь с крупными и сложными проектами или с владением множества мелких, мы полагаемся на определенные соглашения, политики и модели процедур. Число Данбара важно учитывать не только при росте количества сотрудников, но и при определении масштабов работы команды или того момента, когда системе стоит обзавестись вспомогательными инструментами для моделирования и автоматизации логистики. В инженерном контексте, это число проектов (или нормализованная сложность одного проекта), для которого вы бы уверенно вошли в группу поддержки кода.
Работающая сложная система обязательно произошла от работавшей простой системы. Сложная система, разработанная с нуля, никогда не работает, и ее невозможно исправить так, чтобы она заработала. Нужно начать заново, с простой работающей системы.
Закон Голла говорит о том, что попытки разработать очень сложную систему наверняка провалятся. Системы высокой сложности редко создают за один присест – они эволюционируют из более простых.
Классический пример – всемирная сеть. В текущем состоянии это система высокой сложности. Однако изначально ее определили как простой способ обмена контентом между институтами. Она очень успешно справилась с этими целями и эволюционировала, превратившись со временем в более сложную.
Любая наблюдаемая статистическая закономерность склонна разрушаться, как только на нее оказывается давление с целью управления ею.
Также часто формулируется как:
Когда мерило становится целью, оно перестает быть хорошим мерилом.
Мэрилин Стратерн
Закон (принцип) Гудхарта посвящен использованию показателей и заключается в следующем: «Когда мера становится целью, она перестает быть хорошей мерой», потому что становится объектом манипулирования как прямого (фальсификация чисел), так и косвенного (работа исключительно для улучшения этой меры). Так, если экономический показатель становится целевой функцией для проведения экономической политики, прежние эмпирические закономерности, использующие данный показатель, перестают действовать.
Существует немало связанных концепций. Так Дональд Кэмпбелл отмечал, что введение индикаторов или критериев, по которым оценивается работа того или иного института, неизбежно приводит к искажению как самих индикаторов, так и социальных процессов, которые тот должен оценивать. Соответствующий Закон Кэмпбелла в различных формулировках появился еще в 1969 году.
К. Кристал и П. Мизен полагали, что критика Лукаса и закон Гудхарта очень близки, и Лукасу принадлежит первенство: хотя публикация Гудхарта (1975) предшествует публикации Лукаса (1976), но критика Лукаса была доложена на конференции в 1973 году и была широко известна до публикации. Критика Лукаса обычно применяется при обсуждении макроэкономических показателей, а закон Гудхарта — при обсуждении денежной политики.
Кристал и Мизен также нашли связь с физическим принципом неопределенности (измерения параметров системы влияют на эту систему) и «проблемой инвариантности» T. Ховельмо (соотношения между экономическими величинами могут измениться при изменении внешних условий — так инженер, экспериментально оценивший поведение автомобиля на ровной прямой дороге, обнаружит, что его формулы не описывают движения по бездорожью, поскольку ранее не менявшиеся величины (инварианты) начинают меняться).
Джон Дэниелссон сформулировал закон Гудхарта как «любая статистическая взаимосвязь будет нарушена при использовании в целях политики» и предложил следствие для моделирования финансовых рисков: «Модель риска не работает, когда используется для регулирования».
Марио Бьяджоли связал концепцию Гудхарта с последствиями использования показателей цитируемости для оценки важности научных публикаций, напомнив, что по закону Гудхарта люди начинают играть с характеристиками экономики, которые используются как индикаторы
Закон утверждает, что оптимизация на основе определенных мер может привести к обесцениванию этих мер. Слишком избирательные измерения (KPI), вслепую применяемые к процессу, приводят к искажениям. Люди стремятся оптимизировать процесс локально, «обманывая» систему с тем, чтобы удовлетворить определенной метрике, вместо того, чтобы обращать внимание на глобальный результат их действий.
Примеры:
Никогда не приписывай злонамеренности тому, что вполне объясняется тупостью.
Принцип утверждает, что действия, приведшие к негативному результату, могли производиться не с дурными намерениями. Негативный результат с большей вероятностью объясняется тем, что эти действия и их последствия недостаточно хорошо были поняты.
На выполнение задачи всегда уходит больше времени, чем ожидаешь, даже если ты принял во внимание закон Хофстадера.
Вы могли встречать упоминания этого закона, разбираясь с оценками временных затрат на проект. В области разработки ПО кажется трюизмом тот факт, что мы не очень хорошо способны точно оценить время, которое уйдет на завершение проекта.
Цитата из книги "Гедель, Эшер, Бах: эта бесконечная гирлянда".
Улучшение эквивалентно разрушению.
Этот закон утверждает, что улучшение одной части системы ведет к разрушению других частей, или прячет иные типы разрушения, что в целом приводит к деградации системы по сравнению с текущим ее состоянием.
К примеру, уменьшение времени отклика в определенной части системы может привести к увеличению ее пропускной способности, и, как следствие, к проблемам с емкостью где-то на пути потока запросов, что может повлиять на другую подсистему.
Мы склонны переоценивать влияние технологии в краткосрочной перспективе и недооценивать его в долгосрочной.
Цикл шумихи – визуализация восторгов и развития технологии со временем, изначально построенная компанией Gartner. Лучше всего иллюстрируется графиком:
После появления технологии ее популярность доходит до пика раздутых ожиданий, затем ныряет во впадину разочарования, поднимается по склону просветления и выходит на плато продуктивности
Вкратце цикл утверждает, что вокруг новой технологии и ее потенциальных последствий обычно возникает фонтан восторгов. Команды часто быстро увлекаются этими технологиями и часто испытывают разочарование полученными результатами. Возможно, это происходит потому, что технология еще недостаточно развита, или способы ее применения еще не продуманы. По прошествии определенного времени возможности технологии увеличиваются, и количество практических применений растет, после чего команды, наконец, могут становиться продуктивными.
При достижении достаточного количества пользователей API уже неважно, какие его особенности вы обещали всем: для любой из возможных особенностей поведения вашей системы найдется зависящий от нее пользователь.
Закон Хирама постулирует, что если у вашего API достаточно много пользователей, для любой из возможных особенностей поведения вашей системы (даже не описанной в публичном контракте) найдется зависящий от него пользователь. Тривиальным примером могут быть нефункциональные особенности API, типа времени отклика. Более тонкий пример – потребители, полагающиеся на определение типа ошибки посредством применения к ее описанию функции regex. Даже если в публичном контракте ничего не сказано по поводу содержания сообщения, и подразумевается, что пользователи должны использовать код ошибки, некоторые из них могут решить использовать сообщение, и изменение сообщения сломает API для этих пользователей.
Отладка кода в два раза тяжелее, чем его написание. Поэтому, если вы пишете код на пределе умственных возможностей, вам, по определению, не хватит ума, чтобы его отлаживать.
Закон Кернигана назван в честь Брайана Кернигана и взят из книги, написанной им и Плогером: «Элементы стиля программирования».
Все знают, что отладка кода в два раза тяжелее, чем его написание. Поэтому если вы прилагаете все умственные усилия, когда пишете код, как вы собираетесь его отлаживать?
Пусть закон и является гиперболой, он утверждает, что лучше использовать простой код, чем сложный, поскольку отладка любых проблем, возникающих в сложном коде, может оказаться слишком затратной или даже невозможной.
В теории сетей полезность сети растет примерно как квадрат количества ее пользователей.
Закон основывается на количестве возможных попарных связей внутри системы, и тесно связан с законом Рида. Одлыжко и другие утверждали, что законы Рида и Меткалфа преувеличивают ценность системы, не учитывая ограничения человеческих возможностей понимания сети; см. число Данбара.
Закон Меткалфа гласит, что полезность для потребителя участия в сетевом взаимодействии числено измеряется как половине квадрата численности пользователей сети (n2/2
). Такая оценка полезности опирается на подсчет количества прямых связей в сети с количеством узлов n
, которое математически выражено треугольным числом n(n−1)/2
, что асимптотически при больших n стремится к ∼n2/2
.
Предполагается, что одна прямая связь в сети потенциально приносит участнику 1 условную единицу пользы. Об этом говорит сайт https://intellect.icu . Тогда при 5 участниках польза составит 10 (по формуле n(n−1)/2), условных единиц, для сети из 10 участников это будет уже 50 единиц и так далее.
Этот закон был впервые сформулирован Робертом Меткалфом в 1980 году, хотя и не с точки зрения пользователей, а скорее с точки зрения «совместимых устройств связи» (телефонов, факсов). После статьи в Forbes 13 сентября 1993 года закон стал ассоциироваться с пользователями Ethernet.
Закон используют для численного описания сетевого эффекта, в том числе в многоуровневом сетевом маркетинге, в социальных сетях и других сетевых структурах.
Два телефона позволяют только одно взаимодействие, пять — создают 10 соединений, при двенадцати будет 66 соединений
График закона Меткалфа
Закон Свансона — эмпирический закон, заключающийся в том, что цена солнечных фотоэлементов имеет тенденцию к снижению на 20 % после каждого удвоения совокупного объема. В настоящее время цены понижаются вдвое примерно каждые 10 лет. Закон назван в честь Ричарда Свансона, основателя SunPower Corporation, производителя солнечных панелей.
Закон Свансона сравнивают с законом Мура, который предсказывает рост вычислительную мощность процессоров. Цены на фотоэлектрические ячейки из кристаллического кремния упали с 76,67 долл. США за ватт в 1977 году до 0,36 долл. США за ватт в 2014 году. Изменение цены модуля в долларах США во времени заключается в снижении на 10 % в год.
Закон Свансона
Отец Стивена Стиглера, экономист Джордж Стиглер, исследовал историю экономических открытий. Он говорил: «То, что ранее не услышанное утверждение, затем, будучи переоткрытым, признается наукой, можно считать безусловным доказательством того, что научное сообщество принимает идеи, только когда они согласуются с актуальным состоянием науки» (англ. If an earlier, valid statement of a theory falls on deaf ears, and a later restatement is accepted by the science, this is surely proof that the science accepts ideas only when they fit into the then-current state of the science). Он также приводил некоторые примеры, когда первооткрыватель не получал должного признания.
Роберт Мертон использовал термин эффект Матфея, описывая закономерность, при которой известный ученый имеет приоритет над малоизвестным ученым в вопросе признания за ним авторства. И даже если их результаты были похожи, авторство открытия обычно закрепляется за уже и без того известным ученым. Мертон писал: «Такой перекос в признании авторства в пользу признанного ученого имеет место при совместной работе и в случаях, когда открытия независимо делали ученые с существенно разным авторитетом» (англ. this pattern of recognition, skewed in favor of the established scientist, appears principally (i) in cases of collaboration and (ii) in cases of independent multiple discoveries made by scientists of distinctly different rank).
Закон Бойера был сформулирован Хьюбертом Кеннеди в 1972 году. Он гласит: «Математические формулы и теоремы обычно названы не в честь первооткрывателей», и был назван в честь Карла Бойера, чья книга История математики содержала множество примеров этой закономерности. Так же как и Стиглер, Кеннеди отмечал, что это редкий случай, когда закон является подтверждением самого себя (англ. it is perhaps interesting to note that this is probably a rare instance of a law whose statement confirms its own validity).
Поговорка «Все важное уже было сказано кем-то, кто этого не находил» (англ. Everything of importance has been said before by somebody who did not discover it) приписывается Альфреду Уайтхеду.
В России закон Стиглера часто называют «принципом Арнольда»; В. И. Арнольд сформулировал его в своей научно-популярной заметке 1998 года и подробно описал ситуацию, при которой был сформулирован этот принцип:
Английский физик Майкл Берри назвал этот эпонимический принцип «принципом Арнольда», дополнив его еще вторым. Принцип Берри: Принцип Арнольда применим к самому себе (то есть был известен и раньше). Сообщил же я ему эпонимический принцип в ответ на препринт о «фазе Берри», примеры которой, ничуть не уступающие общей теории, за десятки лет до Берри были опубликованы С. М. Рытовым (под названием «инерции направления поляризации») и А. Ю. Ишлинским (под названием «ухода гироскопа подводной лодки вследствие несовпадения пути возвращения на базу с путем ухода от нее»)
Шнайер считал, что экспертная оценка и экспертный анализ очень важны для защиты криптографических систем. Математическая криптография обычно не самое слабое звено в цепи безопасности. Поэтому эффективная защита требует, чтобы криптография объединялась с другими вещам.
Термин Закон Шнайера был введен Кори Доктороу в своей речи про Технические средства защиты авторских прав для Microsoft Research. Закон сформулирован следующим образом:
Любой человек может придумать такую умную систему безопасности, что он или она не может представить себе способ взломать эту систему.
Интеллектуальный взрыв — возможное последствие создания и развития человеком сильного искусственного интеллекта, описанное Ирвингом Гудом в 1965 году.
Согласно этой концепции, в определенный момент человечество создаст искусственный интеллект, который будет способен к улучшению самого себя, притом без участия человека. Так, в процессе самосовершенствования такой искусственный интеллект может трансформироваться в искусственный суперинтеллект, который превзойдет способности людей. Это и будет моментом «интеллектуального взрыва». Понятие интеллектуального взрыва тесно связано с понятием технологической сингулярности.
Количество транзисторов, размещаемых на кристалле интегральной схемы, удваивается примерно каждые 24 месяца.
Предсказание Мура, которое часто используют для демонстрации огромной скорости улучшения технологий производства полупроводников и чипов, оказалось удивительно точным, и работало с 1970-х по конец 2000-х. В последние годы тренд немного изменился, в частности, из-за физических ограничений миниатюризации компонентов. Однако прогресс распараллеливания и потенциально революционные изменения в полупроводниковой технологии и квантовых компьютеров могут означать, что закон Мура может и следующие несколько десятилетий оставаться верным.
Все, что может пойти не так, пойдет не так.
Закон Мерфи, за авторством Эдварда А. Мерфи, постулирует, что все, что может пойти не так, обязательно пойдет не так.
Эту поговорку часто используют разработчики. Иногда неожиданные вещи происходят во время разработки, тестирования или даже в продакшене. Его можно связать с чаще употребляемым в Британии законом подлости [собственно, и в России он тоже известен / прим. перев.]:
Если что-то может пойти не так, это случится, причем в наихудший из возможных моментов.
Обычно эти «законы» используются в юмористическом смысле. Однако такие явления, как предвзятость подтверждения и систематическая ошибка отбора, могут привести к тому, что люди чрезмерно увлекаются этими законами (в большинстве случаев, когда все работает, как надо, этого никто не замечает, а вот отказы заметнее и привлекают больше обсуждения).
Не следует множить сущее без необходимости.
Бритва Оккама утверждает, что из нескольких возможных решений наиболее вероятным будет решение, содержащее наименьшее количество концепций и предположений. Это решение будет простейшим и будет решать только заданную проблему, не вводя случайных сложностей и возможных негативных последствий.
Работа заполняет время, отпущенное на нее.
В оригинальном контексте закон был основан на изучении бюрократизма. Пессимистически его можно применить к разработке ПО, предположив, что команда будет работать неэффективно, пока не начнет приближаться срок сдачи проекта, а затем будет торопиться, чтобы сдать его в срок, из-за чего конкретная дата окончания оказывается довольно произвольной.
Если скомбинировать его с законом Хофстадера, получится еще более пессимистичный взгляд: работа будет расширяться, пока не заполнит все время, необходимое на ее завершение, и все равно займет больше, чем ожидалось.
Преждевременная оптимизация – корень всех зол.
В работе Дональда Кнута «Структурированное программирование с GoTo» он писал: «Программисты тратят огромное количество времени на размышления и волнения по поводу скорости выполнения некритичных частей программ, и попытки сделать их эффективнее оказывают сильный негативный эффект, если задуматься об их отладке и поддержке. Нам нужно забывать о малозначимой эффективности 97% времени: преждевременная оптимизация – корень всех зол. Однако в критических важных 3% случаев мы не должны упускать наши возможности».
Однако преждевременную оптимизацию также можно описать, как попытку оптимизировать что-то до того, как мы поймем, что нам нужно сделать.
В технологическом секторе доминируют два типа людей: те, кто разбирается в том, что они не контролируют, и те, кто контролирует то, в чем они не разбираются.
В любой технической иерархии со временем вырабатывается инверсия компетентности.
Эти утверждения предполагают, что из-за различных критериев отбора и тенденций организации групп, на рабочих уровнях технической организации всегда будет находиться некоторое количество опытных людей, а на уровне менеджмента всегда будут люди, не имеющие понятия о сложностях и проблемах работы, которой они управляют.
Однако стоит подчеркнуть, что подобные законы являются очень грубым обобщением, и могут быть применимыми к одним типам организаций, и не применимыми к другим.
Полезность крупных сетей, в особенности, социальных, масштабируется экспоненциально с ростом размера сети.
Этот закон основан на теории графов, где полезность масштабируется как число возможных подгрупп, растущее быстрее, чем количество участников или возможных попарных связей. Одлыжко и другие утверждали, что законы Рида и Меткалфа преувеличивают ценность системы, не учитывая ограничения человеческих возможностей понимания сети; см. число Данбара.
Закон утверждает, что у системы существует определенная сложность, уменьшить которую нельзя.
Часть сложности системы может возникнуть ненамеренно. Она является результатом плохой структуры, ошибок или неудачного моделирования решаемой задачи. Ненамеренную сложность можно уменьшить или устранить. Однако некоторые виды сложности являются неотъемлемым следствием сложностей самой задачи. Эту сложность можно переместить, но не устранить.
Один из интересных элементов этого закона – предположение о том, что даже при упрощении всей системы ее внутренняя сложность не уменьшается, а переходит на пользователя, которому приходится сложнее себя вести.
Все нетривиальные абстракции до определенного предела подвержены протеканию.
Этот закон утверждает, что абстракции, которые обычно используются в IT для упрощения работы со сложными системами, в определенных ситуациях дают «протечку», пропуская наверх элементы лежащих в их основе систем, из-за чего абстракция начинает вести себя непредсказуемо.
Примером может служить загрузка файла и чтение его содержимого. API файловой системы – это абстракция систем ядра более низкого уровня, которые сами являются абстракцией физических процессов, связанных с изменением данных на магнитной пластине (или в флэш-памяти SSD). В большинстве случаев абстракция, представляющая файл в виде потока двоичных данных, будет работать. Однако последовательное чтение данных с магнитного диска будет идти быстрее, чем случайный доступ к ним, но при этом у SSD таких проблем не будет. Нужно понимать детали, лежащие в глубине, чтобы обрабатывать эти случаи (к примеру, индексные файлы баз данных структурируются, чтобы уменьшить время случайного доступа), когда абстракция дает «протечку» деталей реализации, о которых нужно знать разработчику.
Приведенный пример может усложниться при добавлении новых абстракций. ОС Linux позволяет получать доступ к файлам по сети, однако они видны локально, как «обычные». Эта абстракция даст «протечку» в случае проблем с сетью. Если разработчик будет относиться к ним, как к «нормальным», не учитывая того, что они подвержены проблемам с задержками и отказам в сети, его решение будет неоптимальным и глючным.
В статье, описывающей закон, предполагается, что чрезмерное пристрастие к абстракциям вкупе с плохим пониманием лежащим в ее основе процессам в некоторых случаях даже усложняет процесс решения задачи.
Примеры: медленный запуск Photoshop. С этой проблемой я столкнулся в прошлом. Photoshop очень медленно запускался, иногда на это уходило несколько минут. Судя по всему, проблема была в том, что при запуске он считывает информацию о текущем принтере по умолчанию. Но если этот принтер был сетевым, на это могло уйти чрезвычайно много времени. Абстракция, согласно которой сетевой принтер аналогичен локальному, причиняла пользователем проблемы в случае плохой связи.
Закон утверждает, что группы тратят гораздо больше времени и внимания на обсуждения косметических или тривиальных проблем, чем на серьезные и обширные.
Обычно приводится в пример работа комитета, одобряющего планы ядерной электростанции, который большую часть времени обсуждает структуру велопарковки, чем более важные вопросы проекта самой станции. Бывает сложно внести ценный вклад в обсуждение очень больших и сложных тем, не имея за плечами объемных знаний по этому вопросу. Однако людям хочется, чтобы их отмечали за внесение ценных замечаний. Отсюда происходит тенденция концентрации на небольших деталях, о которых легко рассуждать, но которые не обязательно важны для проекта в целом.
Вымышленный пример, приведенный выше, породил термин «эффект велосарая», описывающий потерю времени на обсуждение тривиальных деталей. Существует похожий термин «стрижка яков», описывающий, казалось бы, не связанную с проектом активность, являющуюся частью длинной цепи необходимых подготовительных этапов.
Философия Unix состоит в том, что компоненты ПО должны быть небольшими и концентрироваться на том, чтобы хорошо выполнять одну конкретную задачу. Это облегчает процесс построения систем путем набора из небольших, простых и хорошо определенных модулей, вместо того, чтобы использовать крупные, сложные, многофункциональные программы.
Современные практики, вроде «архитектуры микросервисов», можно считать применением этой философии – сервисы мелкие, сконцентрированы на выполнении одной конкретной задачи, что позволяет составлять сложное поведение из простых строительных блоков.
Подход к структуре команды и организации, который продвигает Spotify. По этой модели команды организуются вокруг функций программ, а не вокруг технологий.
Также модель продвигает концепции племен, гильдий, филиалов – других компонентов организационной структуры.
В проектировании любого языка общее время, потраченное на обсуждение особенности из этого списка, пропорционально двойке в степени номера позиции этой особенности в списке.
0. Семантика.
1. Синтаксис.
2. Лексический синтаксис.
3. Лексический синтаксис комментариев.
То есть, на каждый час, потраченный на семантику, приходится 8 часов, потраченных на синтаксис комментариев.
Как и закон тривиальности, закон Уодлера постулирует, что при проектировании языка количество времени, потраченное на структуры языка, непропорционально велико по сравнению с важностью этих структур.
Не будь козлом.
Этот сжатый, простой и всеобъемлющий закон, сформулированный Уилом Уитаном, направлен на увеличение гармонии и уважения в рамках профессиональной организации. Его можно применять в разговорах с коллегами, при проведении экспертной оценки кода, поиске возражений против других точек зрения, в критике, и в целом, в профессиональном общении людей.
Разработчик Netscape Джейми Завински однажды отметил: "Любая программа обрастает функциями, пока не сможет читать электронные письма. Если она не справляется с этим, ее заменяет другая, которая способна."
Эта шутка была забавной, поскольку намекала на программы, изначально не предназначенные для работы с почтовыми клиентами. Однако юмор исчез, когда стало очевидно, что многие приложения на Google Play требуют доступ к компонентам телефона и данным пользователя, которые не имеют отношения к их основным задачам.
Некоторые увидели в этом попытку отслеживания пользователей, но, возможно, это также отражает человеческую склонность делать что-то просто потому, что это технически возможно.
Лоуренс Питер прославился тем, что заявил, что в иерархии человек достигает должности, для которой он крайне некомпетентен. Но он также успел кое-что сказать о сложных проектах:
«Сложный проект станет слишком сложным, чтобы его могли понять даже его собственные разработчики».
Иными словами, если часть или все программное обеспечение сильно отличается от того, к чему привык пользователь, лучше всего изменить дизайн. В идеале стремиться к достижению постепенные улучшения, достаточно большие, чтобы произвести впечатление, но достаточно маленькие, чтобы оставаться знакомыми для пользователя.
гласит:
"Первые 90% кода занимают первые 90% времени разработки, а оставшиеся 10% кода — еще 90% времени."
Эта формулировка, приписываемая Тому Каргиллу, идеально отражает парадокс разработки: завершение проекта всегда оказывается сложнее и дольше, чем предполагалось изначально. Даже опытные разработчики сталкиваются с неожиданностями, особенно на финальных этапах, когда мелкие детали требуют значительных усилий.
Эту идею дополняет закон Хофштадтера:
"Это всегда занимает больше времени, чем вы ожидаете, даже если вы учитываете закон Хофштадтера."
В реальной жизни это правило знакомо любому, кто запускал коммерческий проект: всегда приходится тратить в два раза больше времени и денег, чем планировалось, чтобы достичь лишь части запланированной прибыли.
Особенно актуально это для разработчиков Ubuntu и Fedora, которые работают над выпуском новых версий каждые шесть месяцев. Возможно, им стоит пересматривать эти законы перед каждым циклом разработки
гласит: всегда найдется еще одна ошибка.
Исторически первая "ошибка" в компьютерной системе была буквальной — мотылек, застрявший в одном из реле компьютера MARK II, привел к его сбою.
Перенося эту метафору на современные технологии, можно утверждать, что, как бы тщательно ни тестировалась операционная система или программа, всегда остается незамеченный изъян, который обнаруживается, когда уже слишком поздно. Это неизбежная реальность, знакомая каждому пользователю компьютеров.
Закон Гроша — «получение добавочной экономии есть только квадратный корень от увеличения скорости — то есть, чтоб сделать вычисления в 10 раз дешевле, вы должны сделать их в 100 раз быстрее». Данное замечание о производительности компьютеров сделано Хербом Грошем в 1965 году. Это изречение чаще формулируется так:
Производительность компьютера увеличивается как квадрат стоимости. Если компьютер A стоит в два раза дороже, чем компьютер B, то вы должны ожидать, что компьютер A в четыре раза быстрее, чем компьютер B.
Закон также может быть истолкован в том значении, что компьютеры представляют собой пример экономии от масштаба: чем более дорог компьютер, тем отношение производительность/цена для него линейно лучше. Это означает, что недорогие компьютеры не могут конкурировать на рынке, поскольку их вычисления дороже. В конце концов, несколько огромных машин будут обслуживать вычислительные запросы всего мира. Предположительно, это могло быть побуждением для предсказания Томаса Дж. Уотсона, на то время, что общий глобальный рынок вычислительных задач составляет пять ЭВМ.
Современный пример: этот закон гласит, для того, чтобы иметь компьютер в сто раз более мощный, чем современный PC, владельцу пришлось бы заплатить только в десять раз больше.
Для кластеров первоначальный закон Гроша предполагает, что если кластер содержит 50 машин и к нему добавлено еще 50 машин (удвоение стоимости), то в результате 100-машинный кластер будет иметь учетверенную вычислительную мощность, что, очевидно, неверно. Напротив, даже линейное увеличение производительности — 100-машинный кластер сделать вдвое более мощным, чем 50-машинный кластер, будет проблемой.
Когда Google определялся с архитектурой компьютерной системы для своей услуги веб-поиска, то пришел к выводу, что расширение масштабов кластеров из больших и средних компьютеров (мейнфреймов) при росте бизнеса было бы слишком дорогим; и потому выбрал для вычислительных массивов дешевые процессоры и диски[
Закон Ван Лоона представляется «Степень технического развития всегда будет в обратном отношении к числу рабов, которые находятся в распоряжении страны». . Закон является плохо сформулированным заявлением, сделанным в книге Стюарта Чейза "Мужчины и машины", опубликованной в 1929 году. Автором может являться Хендрик Виллем ван Лоон
Назван в честь Линуса Торвальдса, создателя ядра Linux.
Согласно Эрику Рэймонду, закон Линуса гласит, что «при достаточном количестве глаз баги выплывают на поверхность» (англ. “given enough eyeballs, all bugs are shallow”); или, более формально, «при достаточном количестве бета-тестеров и сотрудников почти любая проблема будет быстро обнаружена и окажется для кого-то очевидной». Рэймонд сформулировал это правило в четвертой части своего эссе «Собор и Базар».
Это упоминается как «закон человеческой природы», хотя свидетельство Келли является анекдотическим.
Организация Machine Intelligence Research Institute выпустила документ с подробным описанием гораздо большего набора ИИ предсказаний: 95 предсказаний, извлеченных из базы данных 257 предсказаний ИИ, которая находит широкий спектр оценок значительно до и после предполагаемой продолжительности жизни предсказателя, таким образом противоречащий закону. MIRI утверждает более строгое правило «Маэс-Гарро»: «Предсказатель ожидает, что ИИ будет развиваться точно в конце его жизни».
Три закона Кларка были сформулированы известным английским изобретателем, писателем-фантастом и футурологом Артуром Кларком:
Первый из трех законов, изначально называвшийся просто «закон Кларка», был сформулирован автором в его книге «Черты будущего» (англ. Profiles of the Future) (1962). Утверждение, ныне называемое вторым законом, также впервые было упомянуто в этом издании, однако «вторым законом» Кларк назвал его только в последующей редакции своей книги в 1973 году. В этом же издании Кларк сформулировал третий закон, который сегодня известен более остальных. В очередной редакции той же своей книги, сделанной в 1999 году, Кларк добавил четвертый закон: «Для каждого эксперта существует аналогичный эксперт с противоположной точкой зрения» (буквально «… равный и противоположно направленный эксперт», что является аллюзией на третий закон Ньютона).
Айзек Азимов сформулировал дополнение к первому закону Кларка, касающееся несогласия непрофессионалов с ученым:
«Тем не менее, когда непрофессионалы сплачиваются вокруг идеи, отрицаемой уважаемым, но пожилым ученым, и поддерживают эту идею с пылом и энтузиазмом — то этот уважаемый, но пожилой ученый, в конечном счете, вероятно, прав».
Три зако́на роботехники в научной фантастике — обязательные правила поведения для роботов, впервые сформулированные Айзеком Азимовым в рассказе «Хоровод» (1942).
Законы робототехники Азимова построены по аналогии с категорическим императивом Канта и представлют собой наиболее известную попытку создания этических правил для роботов. По замыслу автора Три закона должны наложить этический оттенок на поведение машины.
Законы гласят:
- Робот не может причинить вред человеку или своим бездействием допустить, чтобы человеку был причинен вред.
- Робот должен повиноваться всем приказам, которые дает человек, кроме тех случаев, когда эти приказы противоречат Первому Закону.
- Робот должен заботиться о своей безопасности в той мере, в которой это не противоречит Первому или Второму Законам.
Трем Законам, а также возможным причинам и следствиям их нарушения, посвящен цикл рассказов Азимова о роботах. В некоторых из них, наоборот, рассматриваются непредвиденные последствия соблюдения роботами Трех Законов (например, «Зеркальное отражение»).
В одном из рассказов цикла персонаж Азимова приходит к заключению об этической основе Трех Законов: «…если хорошенько подумать, Три Закона роботехники совпадают с основными принципами большинства этических систем, существующих на Земле… попросту говоря, если Байерли исполняет все Законы роботехники, он — или робот, или очень воспитанный человек».
В 1986 году в романе «Роботы и Империя» (англ. Robots and Empire) Азимов предложил Нулевой Закон:
0. Робот не может причинить вред человечеству или своим бездействием допустить, чтобы человечеству был причинен вред.
Три закона роботехники — объединяющая тема для всей фантастики Азимова, включая не только цикл о роботах, но и некоторые другие произведения.
Три закона роботехники Азимова вплоть до 21 века являют собой наиболее известную попытку создания этических правил для роботов.
С 2014 года, с появлением перспектив реального применения искуственного интеллекта в технике, ведутся активные этические дискуссии вокруг автономного летального вооружения (боевых роботов), и в этих дискуссиях используются азимовские законы. Помимо работ самого Азимова, в обсуждениях используются этические основания, напрямую исходящие из категорического императива Канта, из которого и Азимов вывел свои законы.
Развитие ИИ — это бизнес, а бизнес, как известно, не заинтересован в развитии коренных мер безопасности — особенно философских. Вот несколько примеров: табачная индустрия, автомобильная промышленность, ядерная промышленность. Ни для одной из них изначально не было сказано, что серьезные меры безопасности необходимы, и все они препятствовали внешне налагаемым ограничениям, и ни одна из них не приняла абсолютный эдикт против причинения вреда людям.
Принципы чаще всего связаны с советами по проектированию программ.
В компаниях существует тенденция к повышению некомпетентных сотрудников до менеджеров с целью устранить их от рабочего процесса.
Управленческая концепция, разработанная Скоттом Адамсом (создателем комиксов про Дилберта), вдохновленная принципом Питера. Согласно принципу Дилберта, сотрудников, которых нельзя было считать компетентными, повышают до управленцев, чтобы ограничить возможный урон компании. Впервые Адамс объяснил этот принцип в статье для Wall Street Journal в 1995 году, а потом подробно описал его в книге 1996 года «Принцип Дилберта».
По большей части в жизни все распределяется неравномерно.
Принцип Парето утверждает, что в некоторых случаях за большую часть результатов отвечает меньшая часть вложений:
В 1940-х американский инженер румынского происхождения Джозеф Джуран, которого часто называют отцом управления качеством, начал применять принцип Парето к проблемам качества.
Также этот принцип известен, как правило 80/20, закон важнейшего малого, принцип дефицита факторов.
Примеры: в 2002 году Microsoft сообщила, что после исправления 20% наиболее часто встречающихся ошибок, будет исправлено 80% связанных с ними проблем и падений Windows и Office.
В иерархической системе у каждого индивидуума есть тенденция подниматься до уровня своей некомпетентности.
Управленческая концепция, созданная Лоуренсом Джонстоном Питером, отмечает тот факт, что людей, хорошо справляющихся с работой, повышают до тех пор, пока они не попадают на уровень, на котором уже не справляются («уровень некомпетентности»). Поскольку они забрались достаточно высоко, их уже с меньшей вероятностью уволят (если только они не сотворят какой-то полной ерунды), поэтому они будут оставаться на этой позиции, для которой им не хватает необходимых умений, поскольку их навыки поведения в организации не обязательно совпадают с навыками, необходимыми для успешной работы на данной должности.
Этот принцип особенно интересен инженерам, которые начинают работу с чисто технических ролей, но часто строят карьеру, ведущую к управлению другими инженерами – для чего требуется совершенно другой набор умений.
Консервативно относитесь к своей деятельности, и либерально ко вкладам других.
Этот принцип часто применяют к разработке серверных приложений. Согласно ему, данные, отправляемые вами другим, должны быть как можно меньшего размера и как можно лучше соответствовать стандарту, однако вы сами должны принимать на вход и не совсем стандартизированные данные, если у вас получится их обработать.
Цель принципа – создание надежных систем, способных переварить плохо оформленные данные, смысл которых все же можно понять. Однако у приема нестандартных данных на вход могут быть последствия, связанные с нарушением безопасности, в особенности, если прием таких данных не было хорошо протестирован.
Со временем практика приема нестандартных данных может привести к тому, что протоколы перестанут развиваться, поскольку те, кто реализуют обмен данными, начнут полагаться на либеральность программ, создавая новые функции.
Акроним, обозначающий следующие 5 принципов:
S: The Single Responsibility Principle [Принцип единственной ответственности]
O: The Open/Closed Principle [Принцип открытости/закрытости]
L: The Liskov Substitution Principle [Принцип подстановки Барбары Лисков]
I: The Interface Segregation Principle [Принцип разделения интерфейса]
D: The Dependency Inversion Principle [Принцип инверсии зависимостей]
Они представляют собой ключевые принципы объектно-ориентированного программирования. Подобные принципы проектирования должны помогать разработчикам создавать системы, которые легче поддерживать.
Каждый объект должен иметь одну ответственность и эта ответственность должна быть полностью инкапсулирована в класс.
Первый из принципов SOLID. Принцип утверждает, что каждый модуль или класс должен делать только одну вещь. На практике это значит, что небольшое единственное изменение функции программы должно потребовать изменения только в одном компоненте. К примеру, для изменения процедуры проверки пароля на сложность программу нужно исправить всего в одном месте.
Теоретически это придает коду надежности и упрощает его изменение. То, что у изменяемого компонента имеется единственная ответственность, должно означать, что будет проще тестировать это изменение. Изменение компонента проверки пароля на сложность из предыдущего примера должно повлиять только на функции, связанные со сложностью пароля. Гораздо труднее рассуждать о том, на что повлияет изменение компонента со множеством ответственностей.
Программные сущности должны быть открыты для расширения, но закрыты для изменения.
Второй из принципов SOLID. Принцип утверждает, что сущности (классы, модули, функции и т. п.) должны позволять расширять их поведение, но делать так, чтобы их текущее поведение изменить было нельзя.
Гипотетический пример: представим себе модуль, способный превратить документ в разметке Markdown в документ в разметке HTML. Если модуль можно расширить так, чтобы он научился обрабатывать новые возможности формата Markdown, не изменяя его внутренних функций, тогда модуль открыт для расширения. Если в модуле нельзя изменить обработку текущих функций Markdown, тогда модуль закрыт для изменения.
Принцип особенно тесно связан с объектно-ориентированным программированием, где можно проектировать объекты простые для расширения, но не стоит проектировать объекты, внутренности которых будут неожиданным образом меняться.
Должна быть возможность заменить тип на подтип, не ломая систему.
Третий из принципов SOLID. Принцип утверждает, что если компонент зависит от типа, тогда должна быть возможность использовать подтипы этого типа так, чтобы система не отказалась работать или не требовала подробностей этого подтипа.
К примеру, у нас есть метод, читающий XML-документ из структуры, обозначающей файл. Если метод использует базовый тип file, тогда в функции должна быть возможность использовать все, что происходит от файла. Если file поддерживает обратный поиск, и XML-парсер использует эту функцию, но производный тип «сетевой файл» отказывается работать с обратным поиском, то «сетевой файл» нарушает этот принцип.
Принцип особенно тесно связан с объектно-ориентированным программированием, где иерархии типов нужно очень тщательно моделировать, чтобы избежать путаницы для пользователя системы.
Программные сущности не должны зависеть от методов, которые они не используют.
Четвертый из принципов SOLID. Принцип утверждает, потребители компонента не должны зависеть от функций компонента, которые он не использует.
К примеру, у нас есть метод, читающий XML-документ из структуры, обозначающей файл. Ему нужно только считывать байты, двигаясь вперед или назад по файлу. Если этот метод придется обновлять из-за изменений не связанной с ним особенности файловой структуры (к примеру, из-за обновления модели разграничения доступа, представляющей безопасность файла), тогда этот принцип будет нарушен. Файлу лучше реализовать интерфейс «потока с возможностью поиска», а XML-методу – его использовать.
Принцип особенно тесно связан с объектно-ориентированным программированием, где интерфейсы, иерархии и абстрактные типы используются для минимизации связей между компонентами. Этот принцип заставляет использовать "утиная типизация", методология, устраняющая явные интерфейсы.
Модули верхних уровней не должны зависеть от модулей нижних уровней.
Пятый из принципов SOLID. Принцип утверждает, что управляющие компоненты высших уровней не должны знать деталей реализации их зависимостей.
К примеру, у нас есть программа, читающая метаданные с веб-сайта. Предположительно, ее главному компоненту должен быть известен компонент, скачивающий контент веб-страницы, и компонент, считывающий метаданные. Если мы учтем принцип инверсии зависимостей, то главный компонент будет зависеть только от абстрактного компонента, получающего байтовые данные, а он в свою очередь от абстрактного компонента, способного читать метаданные из потока байтов. Главный компонент ничего не будет знать про TCP/IP, HTTP, HTML и т.п.
Принцип довольно сложный, поскольку он инвертирует ожидаемую зависимость в системе. На практике он также означает, что отдельный управляющий компонент должен гарантировать правильную реализацию абстрактных типов (в предыдущем примере что-то должно поставлять модулю чтения метаданных компонент для скачивания файла по HTTP и для чтения данных из тэга meta HTML).
Каждая часть знания должна иметь единственное, непротиворечивое и авторитетное представление в рамках системы.
Принцип Don’t repeat yourself, или DRY, помогает разработчикам уменьшить повторяемость кода и держать информацию в одном месте. Он был упомянут в 1999 году Энди Хантом и Дэйвом Томасом в их книге «Прагматичный программист».
Противоположностью принципа DRY [англ. сухой] должен быть принцип WET [англ. мокрый] – «пишите все дважды» [Write Everything Twice] или «нам нравится печатать» [We Enjoy Typing].
На практике, если одна и та же информация дублируется у вас в двух или более местах, используйте принцип DRY, сливая их в одно место и повторно используя по необходимости.
Keep it simple, stupid [Не усложняй, дурик]
Принцип KISS говорит, что большинство систем работают лучше, если их не усложнять; следовательно, простота должна быть ключевой целью в разработке, а ненужной сложности нужно избегать. Зародился он в военно-морском флоте США в 1960, и фразу приписывают авиаконструктору Кларенсу Джонсону.
Лучше всего представить его на примере, когда Джонсон выдал команде инженеров-проектировщиков небольшой набор инструментов, и поручил им разработать самолет так, чтобы его в поле в боевых условиях мог починить средний механик при помощи только этого набора. Здесь stupid обозначает взаимоотношение между тем, как ломаются вещи, и сложностью доступных инструментов для их ремонта, а не умственные способности инженеров.
Акроним для You Ain't Gonna Need It [вам это не понадобится].
Всегда реализуйте функции только тогда, когда они вам реально нужны, а не тогда, когда вам кажется, что они вам понадобятся в будущем.
Автор техники экстремального программирования (XP) и книги «Установленное экстремальное программирование» Рон Джеффрис предполагает, что разработчики должны заниматься реализацией только такой функциональности, которая нужна прямо сейчас, и не пытаться предсказывать будущее, реализуя функциональность, которая может понадобиться позже.
Следование этому принципу должно уменьшить количество неиспользуемого кода в базе, а также траты сил и времени на функциональность, не приносящую пользы.
При́нцип Ланда́уэра — принцип, сформулированный в 1961 году Рольфом Ландауэром (IBM) и гласящий, что в любой вычислительной системе, независимо от ее физической реализации, при потере 1 бита информации выделяется теплота Q :
где kB — константа Больцмана, T — абсолютная температура вычислительной системы.
Выражением Шеннона — фон Неймана — Ландауэра (Shannon—von Neumann—Landauer, SNL) называют минимальную энергию Ebit, необходимую для обработки 1 бита (либо — минимальную высоту барьера, необходимую для разделения двух состояний электрона ESNL):
При T = 300 K энергия ESNL ≈ 0,017 эВ ≈ 2,7×10−21 Дж.
Несмотря на то, что увеличение энтропии при стирании одного бита чрезвычайно невелико, современные микросхемы имеют в себе миллиарды транзисторов, переключающихся на частотах до нескольких гигагерц (миллиардов раз в секунду), что увеличивает количество теплоты от стирания информации до измеримых величин.
В начале XXI века компьютеры при обработке одного бита рассеивали примерно в миллион раз больше тепла, чем предсказано принципом. Однако на начало 2010-х разница снизилась до нескольких тысяч, и предсказывается дальнейшее приближение к пределу Ландауэра в течение ближайших десятилетий.
Ограничения накладываемые принципом Ландауэра можно обойти путем реализации обратимых вычислений, при этом возрастают требования к объему памяти и количеству вычислений. Иногда также высказываются предположения, что обратимые вычисления будут медленнее.
Несмотря на то, что принцип Ландауэра признан в качестве физического закона, он до сих пор требует проверки экспериментальным путем на разных уровнях.
Универсальность принципа критиковалась в работах Еармана и Нортона (1998), а затем Шенкера (2000) и снова Нортона (2004, 2011), и защищалась П. Беннетом (2003) и Лэдимэном (2007)
В 2016 году исследователи из Университета Перуджи утверждали, что им удалось продемонстрировать прямое нарушение принципа Ландауэра, но, согласно Лазло Кишу, их результаты ошибочны, поскольку игнорируют главный источник рассеяния энергии, а именно – зарядовую энергию емкости входящего электрода.
В 2018 году была подтверждена справедливость принципа Ландауэра на квантовом уровне, в эксперименте было зафиксировано, что при стирании квантовой информации кубитов квантового компьютера также происходит тепловыделение.
В 2020 году было показано, что квантовые эффекты могут привести к увеличению рассеяния энергии по сравнению с пределом Ландауэра в 30 раз.
Также известны, как заблуждения сетевых вычислений. Это список предположений, касающихся распределенных вычислений, способных привести к отказам в работе ПО. Это следующие предположения:
Первые четыре перечислили Билл Джой и Том Лион в 1991 году, а Джеймс Гослинг впервые классифицировал их как «Заблуждения сетевых вычислений». Питер Дойч добавил 5, 6 и 7-е заблуждение. В конце 90-х Гослинг добавил 8-е.
Группу инженеров вдохновляли процессы, происходившие в то время в Sun Microsystems.
Эти заблуждения стоит тщательно учитывать при разработке надежного кода. Каждое из заблуждений может привести к неправильной логике, не способной справиться с реальностью и сложностью распределенных систем.
Исследование, описанное в статье про закон амдала, подчеркивает ее значимость в современном мире. Надеюсь, что теперь ты понял что такое закон амдала, теория разбитых окон, закон брукса, закон конвея, закон каннингема, число данбара, закон голла, закон гудхарта, бритва хэнлона, закон хофстадера, закон хатбера, цикл шумихи, закон хирама, закон кернигана, закон меткалфа, закон мура, закон мёрфи, бритва оккама, закон паркинсона, эффект преждевременной оптимизации, закон патта, закон рида, закон теслера, закон протекающих абстракций, закон тривиальности, философия unix, модель spotify, закон уодлера, закон уитона и для чего все это нужно, а если не понял, или есть замечания, то не стесняйся, пиши или спрашивай в комментариях, с удовольствием отвечу. Для того чтобы глубже понять настоятельно рекомендую изучить всю информацию из категории Разработка программного обеспечения и информационных систем
Ответы на вопросы для самопроверки пишите в комментариях, мы проверим, или же задавайте свой вопрос по данной теме.
Комментарии
Оставить комментарий
Разработка программного обеспечения и информационных систем
Термины: Разработка программного обеспечения и информационных систем