💻📖 hacker-laws-ru

Законы, теории, принципы и паттерны, которые будут полезны разработчикам (83f0cd2).

• 🇨🇳 中文 / Chinese Version - thanks Steve Xu!
• 🇰🇷 한국어 / Korean Version - thanks Doughnut!
• 🇹🇷 Türkçe / Turkish Version - thanks Umut Işık
• 🇺🇸 Original English Version - thanks Dave Kerr!

• Вступление
• Законы
  • Закон Амдаля
  • Закон Брукса
  • Закон Конвея
  • Число Данбара
  • Бритва Хэнлона
  • Закон Хофштадтера
  • Закон Цикла Хайпа & Закон Амары
  • Закон Хайра (в Законе неявных интерфейсов)
  • Закон Мура
  • Закон Паркинсона
  • Эффект Преждевременной Оптимизации
  • Закон Путта
  • Закон сохранения сложности (закон Теслера)
  • Закон Дырявых абстракций
  • Закон тривиальности
  • Философия Unix
  • Spotify модель
  • Закон Вадлера
• Принципы
  • Принцип Парето (Правило 80/20)
  • Принцип робастности (закон Постела)
  • SOLID
  • Принцип единой ответственности
  • Принцип открытости/закрытости
  • Принцип подстановки Барбары Лисков
  • Принцип разделения интерфейса
  • Принцип инверсии зависимостей
  • Принцип "не повторяйся"
  • YAGNI
• Список литературы
• TODO

Вступление

Есть много законов, которые люди обсуждают, когда речь идет о разработке. Этот сборник представляет собой ссылки и краткие обзоры некоторых из наиболее распространенных. Пожалуйста, делитесь и отправляйте PRs!

❗: Этот репозиторий содержит объяснение некоторых законов, принципов и закономерностей, но не выступает за какой-либо из них. Будь они должны применяться всегда будет предметом дискуссий, и в значительной степени зависит от того, что вы работаете.

Законы

Что ж, начнем!

Закон Амдаля

Закон Амдаля в Википедии

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

Лучше всего проиллюстрировано на примере. Если программа состоит из двух частей, часть А, которыя должна быть выполнена одним процессором, и часть B, которая может быть распараллелена, то мы видим, что добавление нескольких процессоров в систему, выполняющей программу, может иметь только ограниченное преимущество. Это потенциально может значительно улучшить скорость части B - но скорость части А будет оставаться неизменной.

На приведенном ниже рисунке показаны некоторые примеры возможных улучшений в скорости:

(Image Reference: By Daniels220 at English Wikipedia, Creative Commons Attribution-Share Alike 3.0 Unported, https://en.wikipedia.org/wiki/File:AmdahlsLaw.svg)

Как вы можете заметить, даже программа, которая на 50% распараллеливается, принесет очень мало пользы, кроме 10 процессорных единиц, тогда как программа, которая на 95% распараллеливается, все же может достичь значительных улучшений скорости с более чем тысячей процессорных блоков.

Поскольку [закон Мура] замедляется, а ускорение отдельных процессоров замедляется, распараллеливание является ключом к повышению производительности. Графическое программирование является отличным примером - с современными вычислениями на основе шейдеров отдельные пиксели или фрагменты могут отображаться параллельно - вот почему современные графические карты часто имеют много тысяч процессорных ядер (графических процессоров или шейдерных блоков).

Смотрите также:

• Закон Брукса
• Закон Мура

Закон Брукса

Закон Брукса в Википедии

Добавление человеческих ресурсов к концу разработки проекта только замедлит процесс.

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

Распространенная фраза в {notes} «Девять женщин не могут родить ребенка за один месяц» относится к закону Брукса, в частности к тому факту, что некоторые виды работ не делятся и не распределяются по параллелям.

Это центральная тема книги '[Мифический человеко-месяц]'.

Смотрите также:

• Марш смерти
• Список для чтения: Мифический человеко месяц

Закон Конвея

Закон Конвея в Википедии

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

Смотрите также:

• Spotify модель

Число Данбара

Число Данбара в Википедии

"Число Данбара - ограничение на количество постоянных социальных связей, которые человек может поддерживать. Поддержание таких связей предполагает знание отличительных черт индивида, его характера, а также социального положения, что требует значительных интеллектуальных способностей." Существуют разногласия по точной цифре. "... [Данбар] предположил, что люди могут комфортно поддерживать только 150 стабильных отношений." Он поставил ряд в более социальный контекст, "количество людей, которые не вызвали бы у вас неловкости если бы они без спроса присоеденились к вам в баре." Лежит в диапазоне от 100 до 230, чаще всего считается равным 150.

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

Смотрите также:

• Закон Конвея

Бритва Хэнлона

Бритва Хэнлона в Википедии

Никогда не приписывай злости то, что (адекватно, просто) объясняется глупостью.

Роберт Дж. Хэнлон

Этот принцип предполагает, что действия, приводящие к отрицательному результату, не были результатом злого умысла. Вместо этого отрицательный результат, скорее всего, объясняется тем, что эти действия и / или воздействие не полностью понято.

Закон Хофштадтера

Закон Хофштадтера в Википедии

Это всегда занимает больше времени, чем вы ожидаете, даже если принять во внимание Закон Хофштадтера.

Дуглас Хофштадтер

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

Это из книги '[Гёдель, Эшер, Бах: эта бесконечная гирлянда]'.

Смотрите также:

• Список для чтения: Гёдель, Эшер, Бах: эта бесконечная гирлянда

Закон Цикла Хайпа & Закон Амары

Закон Цикла Хайпа в Википедии

Мы склонны переоценивать влияние технологии в краткосрочной перспективе, и недооценивать эффект в долгосрочной перспективе.

(Рой Амара)

Hype Cycle - это визуальное представление о волнении и развитии технологий с течением времени, первоначально созданных Гартнером. Лучше всего показывать визуально:

(Image Reference: By Jeremykemp at English Wikipedia, CC BY-SA 3.0, https://commons.wikimedia.org/w/index.php?curid=10547051)

Короче говоря, этот цикл предполагает, что, как правило, взрыв ажиотажа вокруг новой технологии и ее потенциального воздействия. Компании часто прыгают в эти технологии, и иногда оказываются разочарованы результатами. Это может быть потому, что технология еще не достаточно зрелая, или реальные приложения еще не полностью реализованы. После определенного количества времени, возможности увеличения технологии и практические возможности использования его увеличения, и компании могут, наконец, стать продуктивными. Цитата Роя Амары кратко резюмирует это: «Мы склонны переоценивать влияние технологии в краткосрочной перспективе и недооценивать в долгосрочной перспективе».

Закон Хайра (Закон неявных интерфейсов)

Закон Хайрама в Интернете

При достаточном количестве пользователей в API, не имеет значения, что вы обещаете в договоре: все наблюдаемые поведения вашей системы будет зависит от кого-то.

(Хайрам Райт)

Закон Хайра гласит, что, когда у вас есть достаточно большое количество пользователей API, все поведение в API (даже те, которые не определяются как часть общественного договора), в конечном счете будут зависить от кого-то. Тривиальный примером может быть нефункциональные элементы, такие как время отклика на API. Более тонкий пример может быть пользователи, которые полагаются на применение регулярных выражений к сообщению об ошибке, чтобы определить * тип * погрешности в API. Даже если в публичном контракте API ничего не говорится о содержании сообщения, указав, что пользователи должны использовать связанный код ошибки, некоторые пользователи могут использовать сообщение, и изменение сообщения существенно нарушает API для этих пользователей.

Смотрите также:

• Закон Дырявых абстракций
• XKCD 1172

Закон Мура

Закон Мура в Википедии

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

Прогноз Мура, часто используемый для иллюстрации явной скорости, с которой улучшились полупроводниковые и чиповые технологии, доказывал свою высокую точность с 1970-х до конца 2000-х годов. В последние годы эта тенденция немного изменилась, отчасти из-за [физических ограничений на степень миниатюризации компонентов]. Тем не менее, достижения в области распараллеливания и потенциально революционные изменения в полупроводниковых технологиях и квантовых вычислениях могут означать, что закон Мура может и дальше оставаться в силе на десятилетия.

Закон Паркинсона

Закон Паркинсона в Википедии

Общий объём работы всегда будет увеличиваться, чтобы заполнить собой всё отпущенное на работу время.

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

Если этот закон объединить с [Законом Хофштадтера], будет достигнута еще более пессимистическая точка зрения - работа расширится, чтобы заполнить время, доступное для ее завершения, и * все же займет больше времени, чем ожидалось *

Смотрите также:

• Закон Хофштадтера

Эффект Преждевременной Оптимизации

Преждевременная оптимизация на WikiWikiWeb

Преждевременная оптимизация является корнем всего зла.

(Дональд Кнут)

В работе Дональда Кнута [Структурированное программирование с помощью Go To выражений], он писал: "Программисты тратят огромное количество времени, думая о скорости некритических частей их программ, и эти попытки повышения эффективности фактически оказывают сильное негативное воздействие. Мы должны забыть о малой эффективности, скажем, около 97% времени: ** преждевременная оптимизация есть корень всех зол ** Но мы не должны упустить наши возможности в этих критических 3%."

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

Закон Путта

Закон Путта в Википедии

В технологиях доминируют два типа людей: те, кто понимает, что им не удается, и те, кто управляет тем, что они не понимают.

Закон Путта часто сопровождается следствием Путта:

Каждая техническая иерархия со временем развивает инверсию компетенций.

Эти заявления предполагают, что из-за различных критериев отбора и тенденций в организации групп, будет ряд квалифицированных людей на рабочих уровнях технических организаций, а также ряд людей на руководящих должностях, которые не знают о сложностях и проблемах работы, которой они управляют. Это может быть связано с такими явлениями, как [Принцип Петра] или [Закон Дилберта].

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

Смотрите также:

• Принцип Питера
• [Закон Дилберта].

Закон сохранения сложности (закон Теслера)

Закон сохранения сложности в Википедии

Этот закон гласит, что в системе существует определенная сложность, которую нельзя уменьшить.

Некоторая сложность в системе «непреднамеренная». Это является следствием плохой структуры, ошибок или просто плохого моделирования, которую нужно решить. Непреднамеренная сложность может быть уменьшена (или устранена). Однако некоторая сложность является «внутренней» как следствие сложности, присущей решаемой проблеме. Эта сложность может быть перемещена, но не устранена.

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

Закон негерметичных абстракций

Закон негерметичных абстракций на Joel on Software

Все нетривиальные абстракции, в некоторой степени, имеют утечки.

(Джоэл Спольски)

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

Примером может быть загрузка файла и чтение его содержимого. API файловой системы - это абстракция систем ядра более низкого уровня, которые сами являются абстракцией над физическими процессами, связанными с изменением данных на магнитном диске (или флэш-памяти для SSD). В большинстве случаев будет работать абстракция обработки файла как потока двоичных данных. Тем не менее для магнитного накопителя последовательное чтение данных будет * значительно * быстрее, чем при произвольном доступе (из-за увеличения объема служебных ошибок страниц), а для накопителя SSD эти издержки присутствовать не будут. Для понимания этого случая необходимо будет понять основные детали (например, файлы индексов базы данных структурированы так, чтобы уменьшить накладные расходы при произвольном доступе), детали реализации абстракции «утечки» которых, возможно, должны быть известны разработчику.

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

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

Смотрите также:

• Закон Хайрама

Реальные примеры:

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

Закон тривиальности

Закон тривиальности в Википедии

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

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

Вымышленный выше пример привел к использованию термина «Bike Shedding» в качестве выражения траты времени на тривиальные детали

Unix Философия

Unix, Философия в Википедии

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

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

Spotify модель

Spotify модель на Spotify Labs

Модель Spotify - это подход к команде и организационной структуре, который был популяризирован Spotify. В этой модели команды организованы вокруг функций, а не технологий.

Модель Spotify также популяризирует концепции Племен, Гильдий, Глав, которые являются другими компонентами их организационной структуры.

Закон Вадлера

Закон Вадлера на wiki.haskell.org

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

0. Семантика
1. Синтаксис
2. Лексический синтаксис
3. Лексический синтаксис комментариев

(Короче говоря, за каждый час, потраченный на семантику, будет потрачено 8 часов на синтаксис комментариев).

Подобно Закону Тривиальности, Закон Вадлера гласит, что при разработке языка количество времени, затрачиваемого на языковые структуры, непропорционально велико по сравнению с важностью этих функций.

Смотрите также:

• Закон тривиальности

Принципы

Принципы, как правило, будут руководящими, в отношении дизайна.

Принцип Парето (80/20)

Принцип Парето в Википедии

Большинство вещей в жизни не распределяются равномерно.

Принцип Парето предполагает, что в некоторых случаях большинство результатов получается из меньшего количества входных данных:

• 80% определенной части программного обеспечения может быть написано за 20% от общего выделенного времени (и наоборот, самые сложные 20% кода занимают 80% времени)
• 20% усилий дает 80% результата
• 20% работы создает 80% от выручки
• 20% ошибок вызывают 80% сбоев
• 20% функций вызывают 80% использования

В 1940-х годах американо-румынский инженер д-р Джозеф Джуран, которого многие считают отцом контроля качества, [начал применять принцип Парето к вопросам качества].

Этот принцип также известен как: Правило 80/20, Закон жизненно важных факторов и Принцип разреженности факторов.

Реальные примеры:

• В 2002 году Microsoft сообщила, что, исправив 20% самых распространенных ошибок, 80% связанных с этим ошибок и сбоев в Windows и Office будут устранены ([Ссылка]).

Принцип устойчивости (Закон Постела)

Принцип устойчивости в Википедии

Будьте консервативны в том, что вы делаете, либеральным в том, что вы принимаете от других.

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

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

SOLID

Это аббревиатура, которая расшифровывается как:

• S: [Принцип единственной ответственности]
• O: Принцип открытости/закрытости
• L: Принцип подстановки Барбары Лисков
• I: Принцип разделения интерфейса
• D: Принцип инверсии зависимостей

Это ключевые принципы [Объектно-ориентированного программирования]. Такие принципы проектирования должны помочь разработчикам создавать более поддерживаемые системы.

Принцип единой ответственности

Принцип единой ответственности в Википедии

Каждый модуль или класс должен иметь только одну зону ответственности.

Первый из 'SOLID' принципов. Этот принцип предполагает, что модули или классы должны выполнять одно и только одно. В более практическом смысле это означает, что одно небольшое изменение функции программы должно потребовать изменения только одного компонента. Например, изменение способа проверки сложности пароля должно потребовать изменения только в одной части программы.

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

Смотрите также:

• Объектно-ориентированное программирование
• SOLID

Open / Closed Принцип

Открытый / Закрытый Принцип в Википедии

Объекты должны быть открыты для расширения и закрытыми для модификации.

Второй из 'SOLID' принципов. Этот принцип гласит, что объекты (которые могут быть классами, модулями, функциями и т.д.) должны быть доступны для расшириения, но не должны быть доступны для изменения.

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

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

Смотрите также:

• Объектно-ориентированное программирование
• SOLID

Принцип подстановки Лискова

Принцип подстановки Лискова в Википедии

Должна быть возможность заменить тип подтипом, не нарушая систему.

Третий из 'SOLID' принципов. Этот принцип гласит, что если компонент полагается на тип, то он должен иметь возможность использовать подтипы этого типа без сбоя системы или необходимости знать детали того, что представляет собой этот подтип.

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

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

Смотрите также:

• Объектно-ориентированное программирование
• SOLID

Принцип разделения интерфейса

Принцип разделения интерфейса в Википедии

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

Четвертый из 'SOLID' принципов. Этот принцип гласит, что пользователи компонента не должны зависеть от функций этого компонента, который он на самом деле не использует.

В качестве примера, представим, что у нас есть метод, который читает XML-документ из структуры, которая представляет собой файл.Нужно только читать байты, двигаться вперед или назад в файле. Если этот метод необходимо обновить из-за изменения несвязанной структуры функции файла (например, обновление модели доступов, используемой для обеспечения безопасности файла), то этотвызов будет признан недействительным. Было бы лучше, если бы файл реализовал интерфейс 'seekable-stream', а ридер XML использовал бы его.

Этот принцип имеет особое значение для объектно-ориентированного программирования, где интерфейсы, иерархии и абстрактные типы используются для [минимизации связи] между различными компонентами. Утиная типизация - это методология, которая применяет этот принцип, устраняя явные интерфейсы.

Смотрите также:

• Объектно-ориентированное программирование
• SOLID
• Утиная типизация
• Заключение

Принцип обращения зависимостей

Принцип обращения зависимостей on Wikipedia

Модули высшего уровня не должны зависеть от реализаций низшего уровня.

Пятый из 'SOLID' принципов. Этот принцип гласит, что инструменты более высокого уровня не должны знать подробностей их зависимостей.

В качестве примера представим, что у нас есть программа, которая читает метаданные с веб-сайта. Мы предполагаем, что основной компонент должен знать о компоненте для загрузки содержимого веб-страницы, а затем о компоненте, который может читать метаданные. Если бы мы приняли во внимание инверсию зависимостей, основной компонент зависел бы только от абстрактного компонента, который может извлекать байтовые данные, а затем от абстрактного компонента, который мог бы считывать метаданные из байтового потока. Основной компонент не будет знать о TCP / IP, HTTP, HTML и т. Д.

Этот принцип сложен, так как может показаться, что он «инвертирует» ожидаемые зависимости системы (отсюда и название). На практике это также означает, что отдельный инструмент должен гарантировать, что используются правильные реализации абстрактных типов (например, в предыдущем примере something должен по-прежнему предоставлять компоненту чтения метаданных загрузчика файлов HTTP и средство чтения метатегов HTML). Затем это касается таких шаблонов, как Инверсия контроля и Внедрение зависимости.

Смотрите также:

• Объектно-ориентированное программирование
• SOLID
• Инверсия контроля
• Внедрение зависимости

DRY Принцип

DRY Принцип в Википедии

Каждая часть знаний должна иметь единое, однозначное, независимое представление в рамках системы.

DRY является аббревиатурой и означает Не повторяйся. Этот принцип направлен на то, чтобы помочь разработчикам сокращать повторение кода и хранить информацию в одном месте. Принцип был упомянут в 1999 году Эндрю Хантом и Дэйвом Томасом в книге Программист-прагматик

Существует противоположный от DRY принцип WET (Write Everything Twice or We Enjoy Typing).

На практике, если у вас есть один и тот же фрагмент информации в двух (или более) разных местах, вы можете использовать DRY, чтобы поместить фрагмент в одно место и использовать его, когда возникнет желание/необходимость.

Смотрите также:

• Программист-прагматик

YAGNI

YAGNI в Википедии

Это аббревиатура You Aren't Gonna Need It(с англ. - «Вам это не понадобится»).

Всегда имплементируйте функционал, когда он вам действительно нужен, и не делайте этого, когда лишь предвидите необходимость в нем.

(Рон Джеффрис) (Соавтор методологии экстремального программирования и автор книги "Extreme Programming Installed")

Данный принцип Экстремального Программирования (XP) предлагает разработчикам имплементировать лишь тот функционал, который необходим для выполнения текущих требований, и избегать попыток предсказать будующее, путём реализаци функциональных возможностей, которые возможно понадобятся позже.

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

Смотрите также:

• Список литературы: Extreme Programming Installed

Список литературы

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

• The Mythical Man Month - Frederick P. Brooks Jr.(https://www.goodreads.com/book/show/13629.The_Mythical_Man_Month) - A classic volume on software engineering. Закон Брукса is a central theme of the book.
• [Гёдель, Эшер, Бах: эта бесконечная гирлянда - Дуглас Р. Хофштадтер] - Эту книгу трудно классифицировать. Закон Хофштадтера из книги.

TODO

Привет! Если вы оказались здесь, вы нажали ссылку на тему, которую я еще не написал, извините за это - работа в процессе!

Не стесняйтесь [Сообщить об ошибках] запросить более подробную информацию, или [Открыть Pull Request], чтобы представить предложенное вами определение темы..

Они внесли свой вклад

Большое спасибо этим людям:

Андрей 🖋

Евгений 🖋