{"id":13660160,"url":"https://github.com/solarrust/hacker-laws","last_synced_at":"2025-10-06T20:30:33.147Z","repository":{"id":40685848,"uuid":"188625414","full_name":"solarrust/hacker-laws","owner":"solarrust","description":"💻📖 Законы, теории, принципы и модели, которые полезно знать разработчику.","archived":false,"fork":true,"pushed_at":"2021-03-29T03:37:53.000Z","size":1493,"stargazers_count":1013,"open_issues_count":13,"forks_count":80,"subscribers_count":45,"default_branch":"master","last_synced_at":"2024-10-01T12:01:32.744Z","etag":null,"topics":["codding","computerscience","development","laws","patterns","principles"],"latest_commit_sha":null,"homepage":"https://solarrust.github.io/hacker-laws/","language":null,"has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":"dwmkerr/hacker-laws","license":"mit","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/solarrust.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":".github/contributing.md","funding":".github/FUNDING.yml","license":"LICENSE","code_of_conduct":".github/CODE_OF_CONDUCT.md","threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null},"funding":{"github":null,"patreon":"solar_rust","open_collective":null,"ko_fi":null,"tidelift":null,"community_bridge":null,"liberapay":null,"issuehunt":null,"otechie":null,"custom":null}},"created_at":"2019-05-26T00:40:34.000Z","updated_at":"2024-09-26T14:46:09.000Z","dependencies_parsed_at":null,"dependency_job_id":null,"html_url":"https://github.com/solarrust/hacker-laws","commit_stats":null,"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/solarrust%2Fhacker-laws","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/solarrust%2Fhacker-laws/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/solarrust%2Fhacker-laws/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/solarrust%2Fhacker-laws/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/solarrust","download_url":"https://codeload.github.com/solarrust/hacker-laws/tar.gz/refs/heads/master","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":235547083,"owners_count":19007620,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["codding","computerscience","development","laws","patterns","principles"],"created_at":"2024-08-02T05:01:17.608Z","updated_at":"2025-10-06T20:30:27.537Z","avatar_url":"https://github.com/solarrust.png","language":null,"readme":"# 💻📖 hacker-laws\n[![All Contributors](https://img.shields.io/badge/all_contributors-6-purple.svg?style=flat-square)](#они-внесли-свой-вклад)\n\nЗаконы, теории, принципы и модели, которые полезно знать разработчику.\n\n- 🇺🇸 [English Version / Версия на Английском](https://github.com/dwmkerr/hacker-laws) - оригинальная версия о [Dave Kerr](https://github.com/dwmkerr).\n- 🇨🇳 [中文 / Версия на Китайском](https://github.com/nusr/hacker-laws-zh) - спасибо [Steve Xu](https://github.com/nusr)!\n- 🇰🇷 [한국어 / Версия на Корейском](https://github.com/codeanddonuts/hacker-laws-kr) - спасибо [Doughnut](https://github.com/codeanddonuts)!\n\n---\n\n\u003c!-- vim-markdown-toc GFM --\u003e\n\n* [Вступление](#вступление)\n* [Законы](#законы)\n    * [Закон Амдала](#закон-амдала)\n    * [Закон Брукса](#закон-брукса)\n    * [Закон Конвея](#закон-конвея)\n    * [Закон Каннингема](#закон-каннингема)\n    * [Число Данбара](#число-данбара)\n    * [Бритва Хэнлона](#бритва-хэнлона)\n    * [Закон Хофштадтера](#закон-хофштадтера)\n    * [Цикл хайпа и закон Амара](#цикл-хайпа-и-закон-амара)\n    * [Закон Хайрама (Закон неявных интерфейсов)](#закон-хайрама-закон-неявных-интерфейсов)\n    * [Закон Мура](#закон-мура)\n    * [Закон Паркинсона](#закон-паркинсона)\n    * [Закон Путта](#закон-путта)\n    * [Закон сохранения сложности (закон Теслера)](#закон-сохранения-сложности-закон-теслера)\n    * [Закон негерметичных абстракций](#закон-негерметичных-абстракций)\n    * [Закон тривиальности](#закон-тривиальности)\n    * [Философия Unix](#философия-unix)\n    * [Модель Спотифай](#модель-спотифай)\n    * [Закон Вадлера](#закон-вадлера)\n* [Принципы](#принципы)\n    * [Принцип Парето (Правило 80/20)](#принцип-парето-правило-8020)\n    * [Принцип устойчивости (Закон Постела)](#принцип-устойчивости-закон-постела)\n    * [SOLID](#solid)\n    * [Принцип единственной ответственности](#принцип-единственной-ответственности)\n    * [Принцип открытости/закрытости](#принцип-открытостизакрытости)\n    * [Принцип подстановки Лисков](#принцип-подстановки-лисков)\n    * [Принцип разделения интерфейса](#принцип-разделения-интерфейса)\n    * [Принцип инверсии зависимостей](#принцип-инверсии-зависимостей)\n    * [Принцип DRY](#принцип-dry)\n    * [Принцип YAGNI](#принцип-yagni)\n    * [Принцип KISS](#принцип-kiss)\n* [Список литературы](#список-литературы)\n* [TODO](#todo)\n\n\u003c!-- vim-markdown-toc --\u003e\n\n---\n\n## Вступление\n\nСуществует много законов, которые люди обсуждают, говоря о разработке. Этот репозиторий собрал в себе ссылки и обзоры наиболее распространённых. Пожалуйста, делитесь им и присылайте PR'ы!\n\n❗: Этот репозиторий содержит объяснения некоторых законов, принципов и паттернов, но не _агитирует_ ни за один из них. Вопрос о том, стоит ли их применять, всегда будет предметом споров, и ответ на него в значительной степени зависит от того, над чем вы работаете.\n\n## Законы\n\nНу, поехали!\n\n### Закон Амдала\n\n[Закон Амдала в Википедии](https://ru.wikipedia.org/wiki/%D0%97%D0%B0%D0%BA%D0%BE%D0%BD_%D0%90%D0%BC%D0%B4%D0%B0%D0%BB%D0%B0)\n\n\u003e Закон Амдала - это формула, показывающая потенциал увеличения скорости вычислительных задач, которого можно достичь путём увеличения ресурсов системы. Обычно используется в параллельных вычислениях. Он может предсказать реальную выгоду от увеличения числа процессоров, учитывая ограничения распараллеливания программы.\n\nДавайте для наглядности приведём пример. Если программа состоит из двух частей: части А, которая должна выполняться одним процессором, и части Б, которая может выполняться параллельно, тогда мы увидим, что добавление нескольких процессоров в систему может иметь ограниченное преимущество. Это потенциально может ускорить выполнение части Б, но скорость выполнения части А останется неизменной.\n\nДиаграмма ниже показывает несколько примеров потенциального увеличения скорости:\n\n![Диаграмма: Закон Амдала](./images/amdahls_law.png)\n\n**(Источник изображения: авторство Daniels220, взято из Английской Википедии, Creative Commons Attribution-Share Alike 3.0 Unported, [https://en.wikipedia.org/wiki/File:AmdahlsLaw.svg](https://en.wikipedia.org/wiki/File:AmdahlsLaw.svg))**\n\nКак можно видеть, программа с возможностью распараллеливания на 50% принесет очень мало пользы, всего 10 процессорных единиц, тогда как программа с возможностью распараллеливания на 95% может привести к значительному улучшению скорости на более чем тысячу процессорных единиц.\n\nВ то время как [Закон Мура](#закон-мура) замедляется, а скорость отдельных процессоров уменьшается, распараллеливание является ключом к повышению производительности. Этому можно считать отличным примером графическое программирование. C современными вычислениями на основе шейдеров отдельные пиксели или фрагменты могут отображаться параллельно — вот почему современные графические карты часто имеют много тысяч процессорных ядер (графических процессоров или шейдерных блоков).\n\nЧитайте также:\n- [Закон Брукса](#закон-брукса)\n- [Закон Мура](#закон-мура)\n\n-----\n\n### Закон Брукса\n\n[Закон Брукса в Википедии](https://ru.wikipedia.org/wiki/%D0%9C%D0%B8%D1%84%D0%B8%D1%87%D0%B5%D1%81%D0%BA%D0%B8%D0%B9_%D1%87%D0%B5%D0%BB%D0%BE%D0%B2%D0%B5%D0%BA%D0%BE-%D0%BC%D0%B5%D1%81%D1%8F%D1%86#%D0%97%D0%B0%D0%BA%D0%BE%D0%BD_%D0%91%D1%80%D1%83%D0%BA%D1%81%D0%B0)\n\n\u003e Если проект не укладывается в сроки, то добавление рабочей силы задержит его ещё больше.\n\nСчитается, что часто попытка ускорить сдачу проекта, не укладывающегося в сроки, за счёт добавления людей в команду, приведёт к ещё более позднему сроку сдачи. Брукс поясняет, что это излишнее упрощение. Тем не менее, основная мысль заключается в том, что, с учетом роста рабочего времени программистов и издержек коммуникации, в краткосрочной перспективе скорость значительно снижается.\n\nРаспространённое выражение «Девять женщин не могут выносить ребёнка за один месяц» отсылает нас как раз к закону Брукса. В частности, к тому факту, что некоторые виды работ нельзя поделить на части и запараллелить.\n\nЭта мысль является центральной темой книги «[The Mythical Man Month](#список-литературы)».\n\nЧитайте также:\n\n- [Death March](#todo)\n- [Список литературы: The Mythical Man Month](#список-литературы)\n\n---\n\n### Закон Конвея\n\n[Закон Конвея в Википедии](https://ru.wikipedia.org/wiki/%D0%97%D0%B0%D0%BA%D0%BE%D0%BD_%D0%9A%D0%BE%D0%BD%D0%B2%D0%B5%D1%8F)\n\nЭтот закон предполагает, что технические рамки системы будут отражать структуру организации. Обычно его упоминают в контексте улучшения организации. В законе Конвея говорится, что, если организация разделена на небольшие отдельные команды, то и программное обеспечение будет разделено подобным образом. Если организация выстроена вокруг «вертикалей», которые ориентированы на улучшение и сервис, то система программного обеспечения будет отражать это.\n\nЧитайте также:\n\n- [модель Спотифай](#модель-спотифай)\n\n---\n\n### Закон Каннингема\n\n[Закон Каннингема в Википедии](https://meta.wikimedia.org/wiki/Cunningham%27s_Law/ru)\n\nЭтот закон гласит, что «лучшим способом получить правильный ответ в Интернете будет не задавать вопрос, а разместить ложный ответ».\n\nЗакон Каннингема можно также рассматривать как эквивалент французской поговорки «prêcher le faux pour savoir le vrai» (буквально «лгать, чтобы выяснить правду»). Известно, что Шерлок Холмс иногда использовал этот принцип (например, в «Знаке четырёх»). В комиксе xkcd «Зов долга» ([Duty Calls](https://xkcd.com/386/)) использована схожая концепция.\n\nЧитайте также:\n\n- [Когда в интернете опять кто-то не прав](https://pikabu.ru/story/kogda_v_internete_opyat_ktoto_ne_prav_4530754)\n\n---\n\n### Число Данбара\n\n[Число Данбара в Википедии](https://ru.wikipedia.org/wiki/%D0%A7%D0%B8%D1%81%D0%BB%D0%BE_%D0%94%D0%B0%D0%BD%D0%B1%D0%B0%D1%80%D0%B0)\n\n\u003e Число Данбара — ограничение на количество постоянных социальных связей, которые человек может поддерживать. О каждом человеке, включённом в это число связей, вы точно можете сказать, кто это и как он связан с другими людьми. \n\u003e Есть разногласия с точным числом.\n\nДанбар предполагал, что человек может комфортно поддерживать только 150 стабильных связей. Он описал жизненную ситуацию, которая поможет определить число таких связей в вашей жизни: количество людей, которые не смутят вас своим появлением и кому вы будете рады в качестве собутыльника, если случайно столкнётесь в баре. Это число будет лежать где-то между 100 и 250.\n\nПодобно отношениям между людьми, отношения разработчика с кодовой базой требуют усилий для поддержания. Когда мы сталкиваемся с большим проектом или занимаемся ведением нескольких проектов, мы опираемся на соглашения, политику и смоделированную процедуру масштабирования. Число Данбара важно принимать во внимание не только в вопросах роста офиса, но и при определении размера команды или для принятия решения о том, в какой момент структура должна инвестировать в инструментарий для поддержки и автоматизации логистических издержек. В контексте работы инженера число указывает на количество проектов (или на усреднённую сложность одного проекта), которые вы можете уверенно поддерживать единовременно.\n\nЧитайте также:\n\n- [Закон Конвея](#закон-конвея)\n\n### Бритва Хэнлона\n\n[Бритва Хэнлона в Википедии](https://ru.wikipedia.org/wiki/%D0%91%D1%80%D0%B8%D1%82%D0%B2%D0%B0_%D0%A5%D1%8D%D0%BD%D0%BB%D0%BE%D0%BD%D0%B0)\n\n\u003e Никогда не приписывайте злому умыслу то, что адекватно объясняется глупостью.\n\u003e\n\u003e Роберт Джей Хэнлон\n\nЭтот принцип предполагает, что действие, приведшее к негативному результату, не является результатом злого умысла. Скорее, негативный результат связан с тем, что это действие и/или его последствия были не до конца ясны.\n\n---\n\n### Закон Хофштадтера\n\n[Закон Хофштадтера в Википедии](https://ru.wikipedia.org/wiki/%D0%A5%D0%BE%D1%84%D1%88%D1%82%D0%B0%D0%B4%D1%82%D0%B5%D1%80,_%D0%94%D1%83%D0%B3%D0%BB%D0%B0%D1%81#%D0%97%D0%B0%D0%BA%D0%BE%D0%BD_%D0%A5%D0%BE%D1%84%D1%88%D1%82%D0%B0%D0%B4%D1%82%D0%B5%D1%80%D0%B0)\n\n\u003e Любое дело всегда длится дольше, чем ожидается, даже если учесть закон Хофштадтера.\n\u003e\n\u003e Дуглас Хофштадтер\n\nКто-нибудь мог ссылаться на этот закон, глядя на оценку сроков выполнения чего-либо. Кажется очевидным, что мы не очень хороши в оценке сроков разработки. \n\nИз книги «[Gödel, Escher, Bach: An Eternal Golden Braid](#список-литературы)».\n\nЧитайте также:\n\n- [Список литературы: Gödel, Escher, Bach: An Eternal Golden Braid](#список-литературы)\n\n---\n\n### Цикл хайпа и закон Амара\n\n[Цикл хайпа в Википедии](https://ru.wikipedia.org/wiki/Gartner#%D0%A6%D0%B8%D0%BA%D0%BB_%D1%85%D0%B0%D0%B9%D0%BF%D0%B0)\n\n\u003e Мы склонны переоценивать эффект от технологии в краткосрочной перспективе и недооценивать эффект в долгосрочной перспективе.\n\u003e\n\u003e Рой Амара\n\nЦикл хайпа является визуализацией кривых волнения и развития технологии во времени. Впервые был представлен компанией Gartner. Лучше показать на примере:\n\n![Цикл хайпа](./images/gartner_hype_cycle.png)\n\n**(Источник изображения: авторство Jeremykemp, взято из Английской Википедии, CC BY-SA 3.0, https://commons.wikimedia.org/w/index.php?curid=10547051)**\n\nЕсли коротко, этот цикл показывает, что вокруг новой технологии обычно наблюдается взрыв ажиотажа относительно её потенциального воздействия. Команды часто поспешно _прыгают с головой_ в эту новую технологию, но в итоге разочаровываются результатом. Это может быть связано с тем, что технология ещё недостаточно развита или приложения в реальном мире ещё не до конца реализованы. По прошествии времени возможности технологии возрастают, и практическая польза от неё увеличивается. Что позволяет командам продуктивно использовать эту технологию. Рой Амара сформулировал это наиболее ёмко: «Мы склонны переоценивать эффект от технологии в краткосрочной перспективе и недооценивать эффект в долгосрочной перспективе».\n\n---\n\n### Закон Хайрама (Закон неявных интерфейсов)\n\n[Закон Хайрама онлайн](http://www.hyrumslaw.com/)\n\n\u003e При достаточном количестве пользователей API\n\u003e не имеет особого значения, что вы пишете в документации:\n\u003e любые наблюдаемые варианты поведения вашей системы\n\u003e будут на кого-то влиять.\n\u003e\n\u003e Хайрам Райт\n\nЗакон Хайрама гласит, что, когда у вас есть _достаточно большое количество пользователей_ API, любое действия этого API (даже неопределённые в рамках публичной документации) в конечном итоге повлияют на кого-то. Тривиальный пример: нефункциональный элемент, такой, как время ответа API. Менее значительный пример: пользователи, которые опираются на использование регулярных выражений при определении **типа** ошибки API. Даже если публичная документация API не говорит ничего о тексте сообщения ошибки, явно указывая, что нужно смотреть на код ошибки, _некоторые_ пользователи могут использовать текст сообщения, и изменение этого текста приводит к поломке API у таких юзеров.\n\nЧитайте также:\n\n- [Закон дырявых абстракций](#закон-дырявых-абстракций)\n- [XKCD 1172](https://xkcd.com/1172/)\n\n---\n\n### Закон Мура\n\n[Закон Мура в Википедии](https://ru.wikipedia.org/wiki/%D0%97%D0%B0%D0%BA%D0%BE%D0%BD_%D0%9C%D1%83%D1%80%D0%B0)\n\n\u003e Количество транзисторов в интегральной схеме удваивается примерно каждые два года.\n\nЧасто используемый для иллюстрации скорости, с которой улучшаются технологии производства полупроводников и чипов, прогноз Мура был очень точным с 1970-х и до 2000-х годов. В последние годы эта тенденция немного изменилась, в частности из-за [физических ограничений на степень миниатюризации компонентов](https://ru.wikipedia.org/wiki/%D0%A2%D1%83%D0%BD%D0%BD%D0%B5%D0%BB%D1%8C%D0%BD%D1%8B%D0%B9_%D1%8D%D1%84%D1%84%D0%B5%D0%BA%D1%82). И тем не менее, достижения в области распараллеливания и потенциальные революционные изменения в технологии полупроводников, а также квантовые компьютеры могут означать, что закон Мура останется актуальным на протяжении следующих десятилетий.\n\n---\n\n### Закон Паркинсона\n\n[Закон Паркинсона в Википедии](https://ru.wikipedia.org/wiki/%D0%97%D0%B0%D0%BA%D0%BE%D0%BD_%D0%9F%D0%B0%D1%80%D0%BA%D0%B8%D0%BD%D1%81%D0%BE%D0%BD%D0%B0)\n\n\u003e Работа заполняет всё время, отпущенное на неё.\n\nВ оригинальном контексте этот закон был сформулирован в ходе изучения бюрократии. Это может иметь пессимистичный подтекст в случае применения к области разработки программного обеспечения. Теория заключается в том, что команда будет неэффективна вплоть до близкого дедлайна. Затем будет стремиться закончить работу к крайнему сроку. \n\nЕсли этот закон совместить с [законом Хофштадтера](#закон-хофштадтера), то картина окажется ещё более пессимистичной — работа заполнит всё отведённое на неё время и **всё равно займёт больше времени, чем ожидалось**.\n\nЧитайте также:\n\n- [Законом Хофштадтера](#закон-хофштадтера)\n\n---\n\n### Закон Путта\n\n[Закон Путта в Википедии](https://en.wikipedia.org/wiki/Putt%27s_Law_and_the_Successful_Technocrat)\n\n\u003e В технологиях доминируют два типа людей: те, кто понимает, что им не удается, и те, кто управляет тем, что они не понимают.\n\nЗакон Путта часто сопровождается следствием Путта:\n\n\u003e Каждая техническая иерархия со временем развивает инверсию компетенций.\n\nИз этого закона следует, что из-за разницы в критериях отбора и тенденциях в процессах организации групп, на разных рабочих уровнях технических организаций будет некоторое число высококвалифицированных людей и людей, занимающих руководящие позиции, которые не будут понимать сложности и проблемы той работы, которой занимаются. Это можно связать с [Принципом Парето](#принцип-парето-правило-8020) и [Законом Дилберта](#TODO).\n\nВпрочем, стоит подчеркнуть, что подобные законы являются обобщениями и могут применяться лишь к организациям _некоторых_ типов и не применяться к другим.\n\nЧитайте также:\n\n- [Принцип Парето](#принцип-парето-правило-8020)\n- [Закон Дилберта](#TODO).\n\n---\n\n\n### Закон сохранения сложности (закон Теслера)\n\n[Закон сохранения сложности в Википедии](https://en.wikipedia.org/wiki/Law_of_conservation_of_complexity)\n\nЗакон гласит, что в системе существует определённый уровень сложности, который невозможно уменьшить.\n\nВ системе изначально существует «непреднамеренная» сложность. Это следствие плохой структуры, ошибок или плохого моделирования решения проблемы. Непреднамеренная сложность может быть уменьшена (или полностью устранена). Однако определённая сложность является «естественной» и связана со сложностью решаемой проблемы. Этот вид сложности может перемещаться, но её нельзя устранить полностью. \n\nОдна интересная особенность этого закона: предполагается, что даже при упрощении всей системы целиком, естественная сложность не уменьшается, а _перекладывается на плечи пользователя_. Из-за этого усложняется поведение, ожидаемое от пользователя.\n\n---\n\n### Закон негерметичных абстракций\n\n[Закон негерметичных абстракций в Википедии](https://en.wikipedia.org/wiki/Leaky_abstraction)\n\n\u003e Все нетривиальные абстракции, в какой-то степени, негерметичны.\n\u003e \n\u003e  Джоэл Спольски\n\nЭтот закон гласит, что абстракции, используемые в некоторых случаях для упрощения сложных систем, могут «вытекать» из элементов базовой системы. Это заставляет абстракцию вести себя неожиданным образом.\n\nПримером может служить процесс загрузки файла и чтение его содержимого. API файловой системы является _абстракцией_ низкоуровневых систем ядра, которые, в свою очередь, являются абстракциями над физическими процессами изменения данных на диске (или флеш-памяти SSD). В большинстве случаев абстракция обработки файла в виде потока двоичных данных будет работать. Однако для магнитного накопителя последовательное чтение данных будет *значительно* быстрее чем рандомный доступ (из-за увеличения количества служебных ошибок). Но в случае с SSD-диском такие издержки отсутствуют. Для понимания этого примера потребуется разобраться с основами. Например, каталоги файлов в базе данных структурированы таким образом, чтобы снизить издержки при рандомном доступе. «Утечки» абстракций должны быть предусмотренным разработчиком при реализации.\n\nПример выше становится тем сложнее, чем _больше_ абстракций вводится. Операционная система Linux позволяет получать доступ к файлам по сети, но локально представлена в виде «нормальных» файлов. Эта абстракция «протечёт», если в сети произойдёт сбой. Если разработчик будет рассматривать файлы как «нормальные» при работе через сеть, не предусмотрев возможность сбоев и задержек, его решения будут в корне неверны.\n\nВ статье, описывающей данный закон, говорится, что исходная проблема потенциально _усложняется_ в случаях чрезмерной зависимости от абстракций и плохого понимания основных процессов.\n\nЧитайте также:\n\n- [Закон Хайрама (Закон неявных интерфейсов)](#закон-хайрама-закон-неявных-интерфейсов)\n\nРеальный пример:\n\n- [Медленный запуск Photoshop](https://forums.adobe.com/thread/376152) - проблема, с которой я столкнулся. Photoshop медленно запускался, иногда это занимало несколько минут. Похоже, проблема была в том, что программа при запуске считывала информацию о дефолтном принтере. Если принтер был сетевым, то этот процесс мог занимать неприлично много времени. Абстракция работы с сетевым принтером была той же, что для работы с локальным принтером. Не был предусмотрен сценарий ситуации с плохим качеством подключения у клиента.  \n\n---\n\n### Закон тривиальности\n\n[Закон тривиальности в Википедии](https://ru.wikipedia.org/wiki/%D0%97%D0%B0%D0%BA%D0%BE%D0%BD_%D1%82%D1%80%D0%B8%D0%B2%D0%B8%D0%B0%D0%BB%D1%8C%D0%BD%D0%BE%D1%81%D1%82%D0%B8)\n\nЭтот закон предполагает, что группы будут тратить больше времени на тривиальные или косметические задачи, нежели на серьёзные и существенные.\n\nВ качестве примера приводится вымышленный комитет, работа которого заключалась в согласовании проекта атомной электростанции. Члены комитета проводят большую часть своего времени за обсуждением структуры велосипедного навеса, а не гораздо более важного проекта самой электростанции. Бывает трудно внести ценный вклад в дискуссию на очень большие и сложные темы без высокой степени предметной экспертизы или подготовки. Тем не менее, люди хотят вносить ценный вклад. Отсюда возникает тенденция уделять слишком много времени мелким деталям, которые легко обосновываются, но не обязательно имеют особое значение.\n\nВымышленный пример, рассмотренный выше, привел к использованию термина «Bike Shedding» (_если переводить дословно, то получится что-то вроде «сарая для велосипедов»_) в качестве выражения для траты времени на тривиальные детали.\n\n---\n\n### Философия Unix\n\n[Философия Unix в Википедии](https://ru.wikipedia.org/wiki/%D0%A4%D0%B8%D0%BB%D0%BE%D1%81%D0%BE%D1%84%D0%B8%D1%8F_Unix)\n\nФилософия Unix заключается в том, что компонент программного обеспечения должен быть небольшого размера и сфокусирован на идеальном исполнении одной специфичной задачи. Это может упростить создание систем путем компоновки небольших, простых, четко определенных модулей, а не путём использования больших, сложных, многоцелевых программ.\n\nСовременные практики, такие как «Архитектура Микросервисов», могут рассматриваться как применение этого закона. Сервисы небольшие, сфокусированы на одной специфичной задаче, что позволяет создать сложное поведение путём составления простых строительных блоков.\n\n---\n\n### Модель Спотифай\n\n[Модель Спотифай в Википедии](https://ru.wikipedia.org/wiki/Spotify_Model)\n\nМодель Спотифай — подход к организации команды и структуре компании, которая была популяризирована компанией-разработчиком Spotify. В этой модели команды организованы вокруг функций, а не технологий.\n\nМодель Спотифай также популяризирует концепты «Отрядов», «Племён», «Отделов» и «Гильдий», которые являются компонентами их организационной структуры: каждый из «отрядов» сфокусирован на отдельной части функциональности продукта, как то поиск или плейлисты, что позволяет им становиться экспертами в своих областях. На следующем уровне взаимодействия «отряды» Спотифай с общей или схожей миссией объединяются в «племена», проводя периодические (порой даже спонтанные) собрания чтобы скорректировать общие цели. «Отделы» состоят из сотрудников одного профиля (например, разработчики или тестировщики), которые регулярно встречаются, чтобы убедиться в использовании новейших трендов и технологий, обмениваться знаниями и эффективно переиспользовать существующие решения. «Гильдия» же представляет собой менее формальную и включающую в себя большее количество людей группу: так, гильдия тестировщиков состоит не только из широкого круга тестировщиков (включая и автоматизаторов, и специалистов по мануальному тестированию), но и из программистов, которые хотят лучше понимать процессы тестирования и вносить свой вклад в деятельность в этом направлении.\n\n![Модель Спотифай](./images/spotify.jpg)\n\n- __Squad__ — отряд, эквивалент скрам-команды; автономен на столько, на сколько это возможно;\n- __Tribe__ — племя, организованы по принципу минимальной взаимозависимости, чаще всего организуется на уровне офиса до 100 человек;\n- __Chapter__ — отдел, объединяет людей по опыту или профилю;\n- __Guild__ — гильдия, сообщество с обищим интересами; не зависит от струтуры «племён»;\n- __PO__ — руководитель проекта (product owner).\n\nЧитайте также:\n\n- [Список литературы: Spotify engineering culture](#список-литературы)\n\n---\n\n### Закон Вадлера\n\n[Закон Вадлера на wiki.haskell.org](https://wiki.haskell.org/Wadler's_Law)\n\n\u003e В любой конструкции языка время, затрачиваемое на обсуждение функции из этого списка, пропорционально двойке, возведённой в степень позиции в списке.\n\u003e \n\u003e 0. Семантика\n\u003e 1. Синтаксис\n\u003e 2. Лексический синтаксис\n\u003e 3. Лексический синтаксис комментариев\n\u003e \n\u003e (Короче говоря, на каждый час, потраченный на семантику, придётся 8 часов обсуждения синтаксиса комментариев).\n\nАналогично [Закону тривиальности](#закон-тривиальности) закон Вадлера гласит, что при проектировании языка время, потраченное на структурные особенности, непропорционально велико в сравнении с важностью этих функций. \n\nЧитайте также:\n\n- [Закон тривиальности](#закон-тривиальности)\n\n---\n\n## Принципы\n\nПринципы больше похожи на гайдлайны для дизайна системы.\n\n### Принцип Парето (Правило 80/20)\n\n[Принцип Парето в Википедии](https://ru.wikipedia.org/wiki/%D0%97%D0%B0%D0%BA%D0%BE%D0%BD_%D0%9F%D0%B0%D1%80%D0%B5%D1%82%D0%BE)\n\n\u003e Большинство вещей в жизни распределяются неравномерно.\n\nВ некоторых случаях основной результат достигается небольшими ресурсами:\n\n- 80% от общего объёма кода при разработке программного обеспечения пишется за 20% от выделяемого времени (и напротив, самые сложные 20% кода отнимают 80% времени)\n- 20% усилий дают 80% результата\n- 20% работы обеспечивают 80% дохода\n- 20% багов приводят к 80% поломок\n\nВ 1940-х американо-румынский инженер доктор Джозеф Юран, которому приписывают создание контроля качества, [начал применять принцип Парето в вопросах качества](https://en.wikipedia.org/wiki/Joseph_M._Juran).\n\nЭтот принцип также известен как правило 80/20.  \n\nПримеры из реальной жизни:\n\n- В 2002 г. Майкрософт сообщила, что после исправления 20% багов, о которых сообщалось чаще всего, 80% связанных ошибок и поломок в Windows и MS Office просто пропадёт ([Источник](https://www.crn.com/news/security/18821726/microsofts-ceo-80-20-rule-applies-to-bugs-not-just-features.htm)).\n\n---\n\n### Принцип устойчивости (Закон Постела)\n\n[Принцип устойчивости в Википедии](https://en.wikipedia.org/wiki/Robustness_principle)\n\n\u003e Будьте консервативны в том, что вы делаете и либеральны в том, что принимаете от других.\n\nЭтот принцип часто применяется при разработке серверных приложений. То, что вы посылаете другим, должно быть минималистичным и совместимым насколько это возможно. Но вы должны предусмотреть обработку несовместимого ввода. \n\nЦелью этого принципа является построение прочных систем, которые могут обработать плохо форматированный ввод, если смысл этого ввода понятен. Впрочем, приём неправильного ввода имеет потенциальные последствия для безопасности. Особенно если процесс обработки такого ввода плохо протестирован.  \n\n---\n\n### SOLID\n\nЭто акроним, который расшифровывается следующим образом:\n\n* S: [Принцип единственной ответственности](#принцип-единственной-ответственности)\n* O: [Принцип открытости/закрытости](#принцип-открытостизакрытости)\n* L: [Принцип подстановки Барбары Лисков](#принцип-подстановки-барбары-лисков)\n* I: [Принцип разделения интерфейса](#принцип-разделения-интерфейса)\n* D: [Принцип инверсии зависимостей](#принцип-инверсии-зависимостей)\n\nЭто ключевые принципы [Объектно-ориентированного программирования](#todo). Такие принципы проектирования должны помочь разработчикам создавать более простые в поддержке и обслуживании системы.\n\n### Принцип единственной ответственности\n\n[Принцип единственной ответственности в Википедии](https://ru.wikipedia.org/wiki/%D0%9F%D1%80%D0%B8%D0%BD%D1%86%D0%B8%D0%BF_%D0%B5%D0%B4%D0%B8%D0%BD%D1%81%D1%82%D0%B2%D0%B5%D0%BD%D0%BD%D0%BE%D0%B9_%D0%BE%D1%82%D0%B2%D0%B5%D1%82%D1%81%D1%82%D0%B2%D0%B5%D0%BD%D0%BD%D0%BE%D1%81%D1%82%D0%B8)\n\n\u003e Каждый модуль или класс должен иметь одну единственную ответственность. \n\nПервый из пяти принципов [SOLID](#solid). Этот принцип гласит, что модуль или класс должен делать всего одну вещь. В практическом смысле это означает, что одно маленькое изменение при доработке программы должно требовать изменения только в одном компоненте. Например, изменение в механизме проверки сложности пароля должно потребовать изменения только в одной части программы.\n\nТеоретически это должно делать код более надёжным и простым для изменений. Знание, что изменённый компонент несёт на себе единственную ответственность, означает, что _тестирование_ этого изменения будет простым. Возвращаясь к предыдущему примеру, изменения в компоненте проверки сложности пароля должны повлиять только на часть программы, отвечающую за проверку пароля. Гораздо сложнее рассуждать о влиянии изменения в компоненте, у которого сразу несколько функций.\n\nЧитайте также: \n\n- [Объектно-ориентированное программирование](#todo)\n- [SOLID](#solid)\n\n---\n\n### Принцип открытости/закрытости\n\n[Принцип открытости/закрытости в Википедии](https://ru.wikipedia.org/wiki/%D0%9F%D1%80%D0%B8%D0%BD%D1%86%D0%B8%D0%BF_%D0%BE%D1%82%D0%BA%D1%80%D1%8B%D1%82%D0%BE%D1%81%D1%82%D0%B8/%D0%B7%D0%B0%D0%BA%D1%80%D1%8B%D1%82%D0%BE%D1%81%D1%82%D0%B8)\n\n\u003e Сущности должны быть открыты для расширения, но закрыты для изменения.\n\nВторой из пяти принципов [SOLID](#solid). Этот принцип говорит, что сущности (классы, модули, функции и прочее) должны иметь возможность _расширять_ своё поведение, но их существующее поведение не должно _изменяться_.\n\nВ качестве гипотетического примера представьте модуль, который превращает разметку Markdown в HTML-документ. Если можно добавить в модуль обработку новых возможностей Markdown без изменения основного поведения модуля, то он будет считаться открытым для расширения. Если пользователь _не_ может изменить в модуле стандартную обработку синтаксиса Markdown, то такой модуль будет считаться _закрытым_ для изменений.\n\nЭтот принцип имеет особое значение для объектно-ориентированного программирования, в рамках которого мы можем создавать модули, простые в расширении, но должны избегать создания объектов, поведение которых меняется неожиданным образом.\n\nЧитайте также: \n\n- [Объектно-ориентированное программирование](#todo)\n- [SOLID](#solid)\n\n---\n\n### Принцип подстановки Барбары Лисков\n\n[Принцип подстановки Барбары Лисков в Википедии](https://ru.wikipedia.org/wiki/%D0%9F%D1%80%D0%B8%D0%BD%D1%86%D0%B8%D0%BF_%D0%BF%D0%BE%D0%B4%D1%81%D1%82%D0%B0%D0%BD%D0%BE%D0%B2%D0%BA%D0%B8_%D0%91%D0%B0%D1%80%D0%B1%D0%B0%D1%80%D1%8B_%D0%9B%D0%B8%D1%81%D0%BA%D0%BE%D0%B2)\n\n\u003e Должна быть возможность заменить тип на подтип без поломки системы.\n\n_(от редактора)_\n\u003e Наследующий класс должен дополнять, а не замещать поведение базового класса.\n\nТретий из пяти принципов [SOLID](#solid). Этот принцип указывает, что, если компонент зависит от определённого типа, то должна быть возможность использовать подтип этого типа (производную от типа) без поломки всей системы или необходимости знать детали того, что это за подтип.\n\nВ качестве примера представьте, что у нас есть метод, который читает XML-документ из файла. Если метод использует в качестве основы тип 'file', то мы должны иметь возможность использовать в функции и любое производное от 'file'. Если 'file' поддерживает поиск в обратном порядке, а парсер XML использует эту возможность, и при этом подтип 'network file' выдаёт ошибку при попытке поиска в обратном порядке, тогда подтип 'network file' нарушает описываемый принцип.\n\nЭтот принцип имеет особое значение для объектно-ориентированного программирования, где иерархия типов должна проектироваться аккуратно, чтобы не запутать пользователей системы.\n\nЧитайте также: \n\n- [Объектно-ориентированное программирование](#todo)\n- [SOLID](#solid)\n\n---\n\n### Принцип разделения интерфейса\n\n[Принцип разделения интерфейса в Википедии](https://ru.wikipedia.org/wiki/%D0%9F%D1%80%D0%B8%D0%BD%D1%86%D0%B8%D0%BF_%D1%80%D0%B0%D0%B7%D0%B4%D0%B5%D0%BB%D0%B5%D0%BD%D0%B8%D1%8F_%D0%B8%D0%BD%D1%82%D0%B5%D1%80%D1%84%D0%B5%D0%B9%D1%81%D0%B0)\n\n\u003e Программные сущности не должны зависеть от методов, которые они не используют.\n\nЧетвёртый из пяти принципов [SOLID](#solid). Этот принцип говорит, что клиенты компонента не должны зависеть от функций этого компонента, если они не используют их непосредственно.\n\nПредставьте, например, что у нас есть компонент, читающий XML из файла. Он должен только читать байты, двигаясь вперёд или назад по файлу. Если этот метод потребуется изменить потому, что в файловую структуру внесены несвязанные с ним изменения (например, обновление системы безопасности для доступа к файлу), тогда принцип будет нарушен. \n\nЭтот принцип особо актуален для объектно-ориентированного программирования, где интерфейсы, иерархии и абстрактные типы должны стремиться к минимизации [зацепления](#todo) между разными компонентами. [Утиная типизация](#todo) — методология, которая обеспечивает соблюдение этого принципа при помощи исключения явных интерфейсов.\n\nЧитайте также:\n\n- [Объектно-ориентированное программирование](#todo)\n- [SOLID](#solid)\n- [Утиная типизация](#todo)\n- [Зацепление](#todo)\n\n---\n\n### Принцип инверсии зависимостей\n\n[Принцип инверсии зависимостей в Википедии](https://ru.wikipedia.org/wiki/%D0%9F%D1%80%D0%B8%D0%BD%D1%86%D0%B8%D0%BF_%D0%B8%D0%BD%D0%B2%D0%B5%D1%80%D1%81%D0%B8%D0%B8_%D0%B7%D0%B0%D0%B2%D0%B8%D1%81%D0%B8%D0%BC%D0%BE%D1%81%D1%82%D0%B5%D0%B9)\n\n\u003e Высокоуровневые модули не должны зависеть от низкоуровневой реализации.\n\nПятый из принципов [SOLID](#solid). Из этого принципа следует, что высший уровень управляющих компонентов не должен знать о деталях реализации зависимостей.\n\nВ качестве примера представьте, что у нас есть программа, которая считывает мета-данные с сайта. Мы предполагаем, что главный компонент должен знать о компоненте, занимающимся скачиванием контента с сайта, а затем и о компоненте, считывающем мета-данные. Если мы примем во внимание инверсию зависимостей, то основной компонент будет зависеть только от абстрактного компонента, который может извлекать байтовые данные, а затем от абстрактного компонента, который мог бы считывать метаданные из байтового потока. Основной компонент не будет знать о TCP/IP, HTTP, HTML и прочем.\n\nЭтот принцип сложный. Может показаться, что он «инвертирует» вероятные зависимости системы (отсюда и название). На практике это также означает, что отдельный управляющий компонент должен гарантировать, что используются правильные реализации абстрактных типов (например, в предыдущем примере _нечто_ должно по-прежнему предоставлять компоненту чтения метаданных загрузчик файлов HTTP и средство чтения метатегов HTML). Это также касается таких шаблонов, как [Инверсия управления](#todo) и [Внедрение зависимости](#todo).\n\nЧитайте также:\n\n- [Объектно-ориентированное программирование](#todo)\n- [SOLID](#solid)\n- [Inversion of Control](#todo)\n- [Dependency Injection](#todo)\n\n---\n\n### Принцип DRY\n\n[Принцип DRY в Википедии](https://ru.wikipedia.org/wiki/Don%E2%80%99t_repeat_yourself)\n\n\u003e Каждая часть знания должна иметь единственное, непротиворечивое и авторитетное представление в рамках системы.\n\nDRY это акроним от фразы _Don't Repeat Yourself_ («Не повторяй себя»). Этот принцип призван помочь разработчикам избежать повторений в коде и хранить информацию в одном месте. Был впервые описан в 1999 году в книге [The Pragmatic Developer](https://en.wikipedia.org/wiki/The_Pragmatic_Programmer) Эндрю Ханта и Дейва Томаса.\n\n\u003e Принципу DRY полностью противоположен принцип _WET_ — Write Everything Twice или We Enjoy Typing (Пиши всё дважды или Мы любим печатать).\n\nНа практике, если у вас есть два одинаковых куска кода в двух или более местах, то вы можете воспользоваться принципом DRY и объединить их в один, переиспользуя там, где он необходим.\n\nЧитайте также:\n\n- [Список литературы: The Pragmatic Developer](https://en.wikipedia.org/wiki/The_Pragmatic_Programmer)\n\n---\n\n### Принцип YAGNI\n\n[Принцип YAGNI в Википедии](https://ru.wikipedia.org/wiki/YAGNI)\n\nАкроним _**Y**ou **A**ren't **G**onna **N**eed **I**t_ (англ. Вам это не понадобится).\n\n\u003e Всегда имплементируйте функционал, когда он вам действительно нужен, и не делайте этого, когда лишь предвидите необходимость в нем.\n\u003e\n\u003e ([Рон Джеффриз](https://twitter.com/RonJeffries)) (Соавтор методологии экстремального программирования и автор книги \"Extreme Programming Installed\")\n\nДанный принцип _Экстремального Программирования_ предполагает, что разработчики имплементируют лишь тот функционал, который необходим для выполнения текущих требований, и стремятся не предсказывать будущие требования, имплементируя то, что может понадобиться позже.\n\nСоблюдение принципа должно уменьшить количество неиспользуемого кода и избежать затрат усилий и времени на функционал, который не имеет ценности.\n\nЧитайте также:\n\n- [Список литературы: Extreme Programming Installed](#список-литературы)\n\n---\n\n### Принцип KISS\n\n[Принцип KISS в Википедии](https://en.wikipedia.org/wiki/KISS_principle)\n\nKISS это акроним от фразы _Keep it simple, stupid_ («Сохраняй простоту») или _Keep it stupid simple_ («Сохраняй вещи до глупого простыми»). Принцип KISS утверждает, что большинство систем работают лучше всего, если они остаются простыми, а не усложняются. Поэтому в области проектирования простота должна быть одной из ключевых целей, и следует избегать ненужной сложности.\n\nНа практике:\n- Разбивайте задачи на подзадачи которые не должны по вашему мнению длиться более 4-12 часов написания кода\n- Разбивайте задачу на множество более маленьких задач, каждая задача должна решаться одним или парой классов\n- Сохраняйте ваши методы маленькими. Каждый метод должен состоять не более чем из 30-40 строк. Каждый метод должен решать одну маленькую задачу, а не множество случаев. Если в вашем методе множество условий, разбейте его на несколько. Это повысит читаемость, позволит легче поддерживать код и быстрее находить ошибки в нём. Вы полюбите улучшать код.\n- Сохраняйте ваши классы маленькими. Здесь применяется та же техника что и с методами.\n- Придумайте решение задачи сначала, потом напишите код. Никогда не поступайте иначе. Многие разработчики придумывают решение задачи во время написания кода и в этом нет ничего плохого. Вы можете делать так и при этом придерживаться выше обозначенного правила. Если вы можете в уме разбивать задачу на более мелкие части, когда вы пишете код, делайте это любыми способами. И не бойтесь переписывать код ещё и ещё и ещё… В счёт не идёт число строк, до тех пор пока вы считаете что можно ещё меньше/ещё лучше.\n- Не бойтесь избавляться от кода. Изменение старого кода и написание нового решения два очень важных момента. Если вы столкнулись с новыми требованиями, или не были оповещены о них ранее, тогда порой лучше придумать новое более изящное решение решающее и старые и новые задачи.\n\nЧитайте также:\n\n- [Список литературы: Apache Kiss Principle](#список-литературы)\n\n---\n\n## Список литературы\n\nЕсли вас заинтересовали перечисленные концепции, то вам могут понравиться следующие материалы:\n\n- [Закон Амдала](http://ssd.sscc.ru/en/content/%D0%B7%D0%B0%D0%BA%D0%BE%D0%BD-%D0%B0%D0%BC%D0%B4%D0%B0%D0%BB%D0%B0), Supercomputer Software Department\n- [Закон Амдала](https://medium.com/german-gorelkin/amdahls-law-79a8edb040e2), Герман Горелкин, 11 декабря 2018\n- [The Mythical Man Month - Frederick P. Brooks Jr.](https://www.goodreads.com/book/show/13629.The_Mythical_Man_Month) - Классический труд о разработке ПО. [Закон Брукса](#закон-брукса) в центре повествования.\n- [Gödel, Escher, Bach: An Eternal Golden Braid - Douglas R. Hofstadter.](https://www.goodreads.com/book/show/24113.G_del_Escher_Bach) - Эту книгу сложно классифицировать. [Закон Хофштадтера](#закон-хофштадтера) описан именно в этой книге.\n- [Spotify engineering culture](https://labs.spotify.com/2014/03/27/spotify-engineering-culture-part-1/)\n- [How to Build Your Own “Spotify Model”](https://medium.com/the-ready/how-to-build-your-own-spotify-model-dce98025d32f)\n- [The Pragmatic Developer](https://en.wikipedia.org/wiki/The_Pragmatic_Programmer)\n- [Extreme Programming Installed - Ron Jeffries, Ann Anderson, Chet Hendrikson](https://www.goodreads.com/en/book/show/67834) - Покрывает ключевые принципы методологии экстремального программирования.\n- [Philip Hanik. Kiss Principle](http://people.apache.org/~fhanik/kiss.html)\n\n## TODO\n\nПривет! Если вы это читаете, то вы перешли по ссылке на статью, которая ещё не написана. Простите за это! Я работаю над этим.\n\nНе стесняйтесь [заводить issue](https://github.com/solarrust/hacker-laws/issues) с пожеланиями или [присылайте Pull Request](https://github.com/solarrust/hacker-laws/pulls) со своими правками или новыми темами. \n\n---\n\n## Они внесли свой вклад\n\nБольшое спасибо этим прекрасным людям ([что значат emoji?](https://allcontributors.org/docs/en/emoji-key)):\n\n\u003c!-- ALL-CONTRIBUTORS-LIST:START - Do not remove or modify this section --\u003e\n\u003c!-- prettier-ignore --\u003e\n\u003ctable\u003e\n  \u003ctr\u003e\n    \u003ctd align=\"center\"\u003e\u003ca href=\"https://aceof.github.io/\"\u003e\u003cimg src=\"https://avatars2.githubusercontent.com/u/16652418?v=4\" width=\"100px;\" alt=\"Alexandr Kizilow\"/\u003e\u003cbr /\u003e\u003csub\u003e\u003cb\u003eAlexandr Kizilow\u003c/b\u003e\u003c/sub\u003e\u003c/a\u003e\u003cbr /\u003e\u003ca href=\"#content-ACEof\" title=\"Content\"\u003e🖋\u003c/a\u003e\u003c/td\u003e\n    \u003ctd align=\"center\"\u003e\u003ca href=\"https://github.com/natashta\"\u003e\u003cimg src=\"https://avatars1.githubusercontent.com/u/15847929?v=4\" width=\"100px;\" alt=\"Natalia Ryzhova\"/\u003e\u003cbr /\u003e\u003csub\u003e\u003cb\u003eNatalia Ryzhova\u003c/b\u003e\u003c/sub\u003e\u003c/a\u003e\u003cbr /\u003e\u003ca href=\"#content-natashta\" title=\"Content\"\u003e🖋\u003c/a\u003e\u003c/td\u003e\n    \u003ctd align=\"center\"\u003e\u003ca href=\"https://github.com/rikkalo\"\u003e\u003cimg src=\"https://avatars1.githubusercontent.com/u/3524991?v=4\" width=\"100px;\" alt=\"Anastasia Lopatina\"/\u003e\u003cbr /\u003e\u003csub\u003e\u003cb\u003eAnastasia Lopatina\u003c/b\u003e\u003c/sub\u003e\u003c/a\u003e\u003cbr /\u003e\u003ca href=\"#content-rikkalo\" title=\"Content\"\u003e🖋\u003c/a\u003e\u003c/td\u003e\n    \u003ctd align=\"center\"\u003e\u003ca href=\"https://github.com/nksoff\"\u003e\u003cimg src=\"https://avatars2.githubusercontent.com/u/1710024?v=4\" width=\"100px;\" alt=\"Nikita Slimov\"/\u003e\u003cbr /\u003e\u003csub\u003e\u003cb\u003eNikita Slimov\u003c/b\u003e\u003c/sub\u003e\u003c/a\u003e\u003cbr /\u003e\u003ca href=\"#content-nksoff\" title=\"Content\"\u003e🖋\u003c/a\u003e\u003c/td\u003e\n    \u003ctd align=\"center\"\u003e\u003ca href=\"https://github.com/Realetive\"\u003e\u003cimg src=\"https://avatars1.githubusercontent.com/u/2073959?v=4\" width=\"100px;\" alt=\"Realetive\"/\u003e\u003cbr /\u003e\u003csub\u003e\u003cb\u003eRealetive\u003c/b\u003e\u003c/sub\u003e\u003c/a\u003e\u003cbr /\u003e\u003ca href=\"#content-Realetive\" title=\"Content\"\u003e🖋\u003c/a\u003e\u003c/td\u003e\n    \u003ctd align=\"center\"\u003e\u003ca href=\"https://github.com/IvanProdaiko94\"\u003e\u003cimg src=\"https://avatars2.githubusercontent.com/u/16734177?v=4\" width=\"100px;\" alt=\"Ivan Prodaiko\"/\u003e\u003cbr /\u003e\u003csub\u003e\u003cb\u003eIvan Prodaiko\u003c/b\u003e\u003c/sub\u003e\u003c/a\u003e\u003cbr /\u003e\u003ca href=\"#content-IvanProdaiko94\" title=\"Content\"\u003e🖋\u003c/a\u003e\u003c/td\u003e\n  \u003c/tr\u003e\n\u003c/table\u003e\n\n\u003c!-- ALL-CONTRIBUTORS-LIST:END --\u003e\n","funding_links":["https://patreon.com/solar_rust"],"categories":["Others"],"sub_categories":[],"project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fsolarrust%2Fhacker-laws","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fsolarrust%2Fhacker-laws","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fsolarrust%2Fhacker-laws/lists"}