💻📖 hacker-laws

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

• 🇺🇸 English Version / ВерÑ?иÑ? на Ð?нглийÑ?ком - оригинальнаÑ? верÑ?иÑ? о Dave Kerr.
• 🇨🇳 中文 / ВерÑ?иÑ? на КитайÑ?ком - Ñ?паÑ?ибо Steve Xu!
• 🇰🇷 한국어 / ВерÑ?иÑ? на КорейÑ?ком - Ñ?паÑ?ибо Doughnut!

• Ð’Ñ?тупление
• Законы
  • Закон Ð?мдала
  • Закон БрукÑ?а
  • Закон КонвеÑ?
  • Закон Каннингема
  • ЧиÑ?ло Данбара
  • Бритва Ð¥Ñ?нлона
  • Закон Хофштадтера
  • Цикл хайпа и закон Ð?мара
  • Закон Хайрама (Закон неÑ?вных интерфейÑ?ов)
  • Закон Мура
  • Закон ПаркинÑ?она
  • Закон Путта
  • Закон Ñ?охранениÑ? Ñ?ложноÑ?ти (закон ТеÑ?лера)
  • Закон негерметичных абÑ?тракций
  • Закон тривиальноÑ?ти
  • ФилоÑ?офиÑ? Unix
  • Модель Спотифай
  • Закон Вадлера
• Принципы
  • Принцип Парето (Правило 80/20)
  • Принцип уÑ?тойчивоÑ?ти (Закон ПоÑ?тела)
  • SOLID
  • Принцип единÑ?твенной ответÑ?твенноÑ?ти
  • Принцип открытоÑ?ти/закрытоÑ?ти
  • Принцип подÑ?тановки ЛиÑ?ков
  • Принцип разделениÑ? интерфейÑ?а
  • Принцип инверÑ?ии завиÑ?имоÑ?тей
  • Принцип DRY
  • Принцип YAGNI
  • Принцип KISS
• СпиÑ?ок литературы
• TODO

Ð’Ñ?тупление

СущеÑ?твует много законов, которые люди обÑ?уждают, говорÑ? о разработке. Этот репозиторий Ñ?обрал в Ñ?ебе Ñ?Ñ?ылки и обзоры наиболее раÑ?проÑ?транённых. ПожалуйÑ?та, делитеÑ?ÑŒ им и приÑ?ылайте PR'Ñ‹!

â?—: Этот репозиторий Ñ?одержит объÑ?Ñ?нениÑ? некоторых законов, принципов и паттернов, но не агитирует ни за один из них. ВопроÑ? о том, Ñ?тоит ли их применÑ?Ñ‚ÑŒ, вÑ?егда будет предметом Ñ?поров, и ответ на него в значительной Ñ?тепени завиÑ?ит от того, над чем вы работаете.

Законы

Ð?у, поехали!

Закон Ð?мдала

Закон Ð?мдала в Википедии

Закон Ð?мдала - Ñ?то формула, показывающаÑ? потенциал увеличениÑ? Ñ?короÑ?ти вычиÑ?лительных задач, которого можно доÑ?тичь путём увеличениÑ? реÑ?урÑ?ов Ñ?иÑ?темы. Обычно иÑ?пользуетÑ?Ñ? в параллельных вычиÑ?лениÑ?Ñ…. Он может предÑ?казать реальную выгоду от увеличениÑ? чиÑ?ла процеÑ?Ñ?оров, учитываÑ? ограничениÑ? раÑ?параллеливаниÑ? программы.

Давайте длÑ? наглÑ?дноÑ?ти приведём пример. ЕÑ?ли программа Ñ?оÑ?тоит из двух чаÑ?тей: чаÑ?ти Ð?, котораÑ? должна выполнÑ?Ñ‚ÑŒÑ?Ñ? одним процеÑ?Ñ?ором, и чаÑ?ти Б, котораÑ? может выполнÑ?Ñ‚ÑŒÑ?Ñ? параллельно, тогда мы увидим, что добавление неÑ?кольких процеÑ?Ñ?оров в Ñ?иÑ?тему может иметь ограниченное преимущеÑ?тво. Это потенциально может уÑ?корить выполнение чаÑ?ти Б, но Ñ?короÑ?Ñ‚ÑŒ выполнениÑ? чаÑ?ти Ð? оÑ?танетÑ?Ñ? неизменной.

Диаграмма ниже показывает неÑ?колько примеров потенциального увеличениÑ? Ñ?короÑ?ти:

(ИÑ?точник изображениÑ?: авторÑ?тво Daniels220, взÑ?то из Ð?нглийÑ?кой Википедии, Creative Commons Attribution-Share Alike 3.0 Unported, https://en.wikipedia.org/wiki/File:AmdahlsLaw.svg)

Как можно видеть, программа Ñ? возможноÑ?тью раÑ?параллеливаниÑ? на 50% принеÑ?ет очень мало пользы, вÑ?его 10 процеÑ?Ñ?орных единиц, тогда как программа Ñ? возможноÑ?тью раÑ?параллеливаниÑ? на 95% может привеÑ?ти к значительному улучшению Ñ?короÑ?ти на более чем Ñ‚Ñ‹Ñ?Ñ?чу процеÑ?Ñ?орных единиц.

Ð’ то времÑ? как Закон Мура замедлÑ?етÑ?Ñ?, а Ñ?короÑ?Ñ‚ÑŒ отдельных процеÑ?Ñ?оров уменьшаетÑ?Ñ?, раÑ?параллеливание Ñ?влÑ?етÑ?Ñ? ключом к повышению производительноÑ?ти. Этому можно Ñ?читать отличным примером графичеÑ?кое программирование. C Ñ?овременными вычиÑ?лениÑ?ми на оÑ?нове шейдеров отдельные пикÑ?ели или фрагменты могут отображатьÑ?Ñ? параллельно — вот почему Ñ?овременные графичеÑ?кие карты чаÑ?то имеют много Ñ‚Ñ‹Ñ?Ñ?ч процеÑ?Ñ?орных Ñ?дер (графичеÑ?ких процеÑ?Ñ?оров или шейдерных блоков).

Читайте также:

• Закон БрукÑ?а
• Закон Мура

Закон БрукÑ?а

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

ЕÑ?ли проект не укладываетÑ?Ñ? в Ñ?роки, то добавление рабочей Ñ?илы задержит его ещё больше.

СчитаетÑ?Ñ?, что чаÑ?то попытка уÑ?корить Ñ?дачу проекта, не укладывающегоÑ?Ñ? в Ñ?роки, за Ñ?чёт добавлениÑ? людей в команду, приведёт к ещё более позднему Ñ?року Ñ?дачи. БрукÑ? поÑ?Ñ?нÑ?ет, что Ñ?то излишнее упрощение. Тем не менее, оÑ?новнаÑ? мыÑ?ль заключаетÑ?Ñ? в том, что, Ñ? учетом роÑ?та рабочего времени программиÑ?тов и издержек коммуникации, в краткоÑ?рочной перÑ?пективе Ñ?короÑ?Ñ‚ÑŒ значительно Ñ?нижаетÑ?Ñ?.

РаÑ?проÑ?транённое выражение «ДевÑ?Ñ‚ÑŒ женщин не могут выноÑ?ить ребёнка за один меÑ?Ñ?ц» отÑ?ылает наÑ? как раз к закону БрукÑ?а. Ð’ чаÑ?тноÑ?ти, к тому факту, что некоторые виды работ нельзÑ? поделить на чаÑ?ти и запараллелить.

Эта мыÑ?ль Ñ?влÑ?етÑ?Ñ? центральной темой книги «The Mythical Man Month».

Читайте также:

• Death March
• СпиÑ?ок литературы: The Mythical Man Month

Закон КонвеÑ?

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

Этот закон предполагает, что техничеÑ?кие рамки Ñ?иÑ?темы будут отражать Ñ?труктуру организации. Обычно его упоминают в контекÑ?те улучшениÑ? организации. Ð’ законе КонвеÑ? говоритÑ?Ñ?, что, еÑ?ли организациÑ? разделена на небольшие отдельные команды, то и программное обеÑ?печение будет разделено подобным образом. ЕÑ?ли организациÑ? выÑ?троена вокруг «вертикалей», которые ориентированы на улучшение и Ñ?ервиÑ?, то Ñ?иÑ?тема программного обеÑ?печениÑ? будет отражать Ñ?то.

Читайте также:

• модель Спотифай

Закон Каннингема

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

Этот закон глаÑ?ит, что «лучшим Ñ?поÑ?обом получить правильный ответ в Интернете будет не задавать вопроÑ?, а размеÑ?тить ложный ответ».

Закон Каннингема можно также раÑ?Ñ?матривать как Ñ?квивалент французÑ?кой поговорки «prêcher le faux pour savoir le vrai» (буквально «лгать, чтобы выÑ?Ñ?нить правду»). ИзвеÑ?тно, что Шерлок ХолмÑ? иногда иÑ?пользовал Ñ?тот принцип (например, в «Знаке четырёх»). Ð’ комикÑ?е xkcd «Зов долга» (Duty Calls) иÑ?пользована Ñ?хожаÑ? концепциÑ?.

Читайте также:

• Когда в интернете опÑ?Ñ‚ÑŒ кто-то не прав

ЧиÑ?ло Данбара

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

ЧиÑ?ло Данбара — ограничение на количеÑ?тво поÑ?тоÑ?нных Ñ?оциальных Ñ?вÑ?зей, которые человек может поддерживать. О каждом человеке, включённом в Ñ?то чиÑ?ло Ñ?вÑ?зей, вы точно можете Ñ?казать, кто Ñ?то и как он Ñ?вÑ?зан Ñ? другими людьми. ЕÑ?Ñ‚ÑŒ разноглаÑ?иÑ? Ñ? точным чиÑ?лом.

Данбар предполагал, что человек может комфортно поддерживать только 150 Ñ?табильных Ñ?вÑ?зей. Он опиÑ?ал жизненную Ñ?итуацию, котораÑ? поможет определить чиÑ?ло таких Ñ?вÑ?зей в вашей жизни: количеÑ?тво людей, которые не Ñ?мутÑ?Ñ‚ ваÑ? Ñ?воим поÑ?влением и кому вы будете рады в качеÑ?тве Ñ?обутыльника, еÑ?ли Ñ?лучайно Ñ?толкнётеÑ?ÑŒ в баре. Это чиÑ?ло будет лежать где-то между 100 и 250.

Подобно отношениÑ?м между людьми, отношениÑ? разработчика Ñ? кодовой базой требуют уÑ?илий длÑ? поддержаниÑ?. Когда мы Ñ?талкиваемÑ?Ñ? Ñ? большим проектом или занимаемÑ?Ñ? ведением неÑ?кольких проектов, мы опираемÑ?Ñ? на Ñ?оглашениÑ?, политику и Ñ?моделированную процедуру маÑ?штабированиÑ?. ЧиÑ?ло Данбара важно принимать во внимание не только в вопроÑ?ах роÑ?та офиÑ?а, но и при определении размера команды или длÑ? принÑ?тиÑ? решениÑ? о том, в какой момент Ñ?труктура должна инвеÑ?тировать в инÑ?трументарий длÑ? поддержки и автоматизации логиÑ?тичеÑ?ких издержек. Ð’ контекÑ?те работы инженера чиÑ?ло указывает на количеÑ?тво проектов (или на уÑ?реднённую Ñ?ложноÑ?Ñ‚ÑŒ одного проекта), которые вы можете уверенно поддерживать единовременно.

Читайте также:

• Закон КонвеÑ?

Бритва Ð¥Ñ?нлона

Бритва Ð¥Ñ?нлона в Википедии

Ð?икогда не припиÑ?ывайте злому умыÑ?лу то, что адекватно объÑ?Ñ?нÑ?етÑ?Ñ? глупоÑ?тью.

Роберт Джей Ð¥Ñ?нлон

Этот принцип предполагает, что дейÑ?твие, приведшее к негативному результату, не Ñ?влÑ?етÑ?Ñ? результатом злого умыÑ?ла. Скорее, негативный результат Ñ?вÑ?зан Ñ? тем, что Ñ?то дейÑ?твие и/или его поÑ?ледÑ?твиÑ? были не до конца Ñ?Ñ?ны.

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

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

Любое дело вÑ?егда длитÑ?Ñ? дольше, чем ожидаетÑ?Ñ?, даже еÑ?ли учеÑ?Ñ‚ÑŒ закон Хофштадтера.

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

Кто-нибудь мог Ñ?Ñ?ылатьÑ?Ñ? на Ñ?тот закон, глÑ?дÑ? на оценку Ñ?роков выполнениÑ? чего-либо. КажетÑ?Ñ? очевидным, что мы не очень хороши в оценке Ñ?роков разработки.

Из книги «Gödel, Escher, Bach: An Eternal Golden Braid».

Читайте также:

• СпиÑ?ок литературы: Gödel, Escher, Bach: An Eternal Golden Braid

Цикл хайпа и закон Ð?мара

Цикл хайпа в Википедии

Мы Ñ?клонны переоценивать Ñ?ффект от технологии в краткоÑ?рочной перÑ?пективе и недооценивать Ñ?ффект в долгоÑ?рочной перÑ?пективе.

Рой Ð?мара

Цикл хайпа Ñ?влÑ?етÑ?Ñ? визуализацией кривых волнениÑ? и развитиÑ? технологии во времени. Впервые был предÑ?тавлен компанией Gartner. Лучше показать на примере:

(ИÑ?точник изображениÑ?: авторÑ?тво Jeremykemp, взÑ?то из Ð?нглийÑ?кой Википедии, 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-Ñ… годов. Ð’ поÑ?ледние годы Ñ?та тенденциÑ? немного изменилаÑ?ÑŒ, в чаÑ?тноÑ?ти из-за физичеÑ?ких ограничений на Ñ?тепень миниатюризации компонентов. И тем не менее, доÑ?тижениÑ? в облаÑ?ти раÑ?параллеливаниÑ? и потенциальные революционные изменениÑ? в технологии полупроводников, а также квантовые компьютеры могут означать, что закон Мура оÑ?танетÑ?Ñ? актуальным на протÑ?жении Ñ?ледующих деÑ?Ñ?тилетий.

Закон ПаркинÑ?она

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

Работа заполнÑ?ет вÑ?Ñ‘ времÑ?, отпущенное на неё.

Ð’ оригинальном контекÑ?те Ñ?тот закон был Ñ?формулирован в ходе изучениÑ? бюрократии. Это может иметь пеÑ?Ñ?имиÑ?тичный подтекÑ?Ñ‚ в Ñ?лучае применениÑ? к облаÑ?ти разработки программного обеÑ?печениÑ?. ТеориÑ? заключаетÑ?Ñ? в том, что команда будет неÑ?ффективна вплоть до близкого дедлайна. Затем будет Ñ?тремитьÑ?Ñ? закончить работу к крайнему Ñ?року.

ЕÑ?ли Ñ?тот закон Ñ?овмеÑ?тить Ñ? законом Хофштадтера, то картина окажетÑ?Ñ? ещё более пеÑ?Ñ?имиÑ?тичной — работа заполнит вÑ?Ñ‘ отведённое на неё времÑ? и вÑ?Ñ‘ равно займёт больше времени, чем ожидалоÑ?ÑŒ.

Читайте также:

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

Закон Путта

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

Ð’ технологиÑ?Ñ… доминируют два типа людей: те, кто понимает, что им не удаетÑ?Ñ?, и те, кто управлÑ?ет тем, что они не понимают.

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

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

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

Впрочем, Ñ?тоит подчеркнуть, что подобные законы Ñ?влÑ?ÑŽÑ‚Ñ?Ñ? обобщениÑ?ми и могут применÑ?Ñ‚ÑŒÑ?Ñ? лишь к организациÑ?м некоторых типов и не применÑ?Ñ‚ÑŒÑ?Ñ? к другим.

Читайте также:

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

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

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

Закон глаÑ?ит, что в Ñ?иÑ?теме Ñ?ущеÑ?твует определённый уровень Ñ?ложноÑ?ти, который невозможно уменьшить.

Ð’ Ñ?иÑ?теме изначально Ñ?ущеÑ?твует «непреднамереннаÑ?» Ñ?ложноÑ?Ñ‚ÑŒ. Это Ñ?ледÑ?твие плохой Ñ?труктуры, ошибок или плохого моделированиÑ? решениÑ? проблемы. Ð?епреднамереннаÑ? Ñ?ложноÑ?Ñ‚ÑŒ может быть уменьшена (или полноÑ?тью уÑ?транена). Однако определённаÑ? Ñ?ложноÑ?Ñ‚ÑŒ Ñ?влÑ?етÑ?Ñ? «еÑ?теÑ?твенной» и Ñ?вÑ?зана Ñ?о Ñ?ложноÑ?тью решаемой проблемы. Этот вид Ñ?ложноÑ?ти может перемещатьÑ?Ñ?, но её нельзÑ? уÑ?транить полноÑ?тью.

Одна интереÑ?наÑ? оÑ?обенноÑ?Ñ‚ÑŒ Ñ?того закона: предполагаетÑ?Ñ?, что даже при упрощении вÑ?ей Ñ?иÑ?темы целиком, еÑ?теÑ?твеннаÑ? Ñ?ложноÑ?Ñ‚ÑŒ не уменьшаетÑ?Ñ?, а перекладываетÑ?Ñ? на плечи пользователÑ?. Из-за Ñ?того уÑ?ложнÑ?етÑ?Ñ? поведение, ожидаемое от пользователÑ?.

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

Закон негерметичных абÑ?тракций в Википедии

Ð’Ñ?е нетривиальные абÑ?тракции, в какой-то Ñ?тепени, негерметичны.

ДжоÑ?л СпольÑ?ки

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

Примером может Ñ?лужить процеÑ?Ñ? загрузки файла и чтение его Ñ?одержимого. API файловой Ñ?иÑ?темы Ñ?влÑ?етÑ?Ñ? абÑ?тракцией низкоуровневых Ñ?иÑ?тем Ñ?дра, которые, в Ñ?вою очередь, Ñ?влÑ?ÑŽÑ‚Ñ?Ñ? абÑ?тракциÑ?ми над физичеÑ?кими процеÑ?Ñ?ами изменениÑ? данных на диÑ?ке (или флеш-памÑ?ти SSD). Ð’ большинÑ?тве Ñ?лучаев абÑ?тракциÑ? обработки файла в виде потока двоичных данных будет работать. Однако длÑ? магнитного накопителÑ? поÑ?ледовательное чтение данных будет значительно быÑ?трее чем рандомный доÑ?туп (из-за увеличениÑ? количеÑ?тва Ñ?лужебных ошибок). Ð?о в Ñ?лучае Ñ? SSD-диÑ?ком такие издержки отÑ?утÑ?твуют. ДлÑ? пониманиÑ? Ñ?того примера потребуетÑ?Ñ? разобратьÑ?Ñ? Ñ? оÑ?новами. Ð?апример, каталоги файлов в базе данных Ñ?труктурированы таким образом, чтобы Ñ?низить издержки при рандомном доÑ?тупе. «Утечки» абÑ?тракций должны быть предуÑ?мотренным разработчиком при реализации.

Пример выше Ñ?тановитÑ?Ñ? тем Ñ?ложнее, чем больше абÑ?тракций вводитÑ?Ñ?. ОперационнаÑ? Ñ?иÑ?тема Linux позволÑ?ет получать доÑ?туп к файлам по Ñ?ети, но локально предÑ?тавлена в виде «нормальных» файлов. Эта абÑ?тракциÑ? «протечёт», еÑ?ли в Ñ?ети произойдёт Ñ?бой. ЕÑ?ли разработчик будет раÑ?Ñ?матривать файлы как «нормальные» при работе через Ñ?еть, не предуÑ?мотрев возможноÑ?Ñ‚ÑŒ Ñ?боев и задержек, его решениÑ? будут в корне неверны.

Ð’ Ñ?татье, опиÑ?ывающей данный закон, говоритÑ?Ñ?, что иÑ?ходнаÑ? проблема потенциально уÑ?ложнÑ?етÑ?Ñ? в Ñ?лучаÑ?Ñ… чрезмерной завиÑ?имоÑ?ти от абÑ?тракций и плохого пониманиÑ? оÑ?новных процеÑ?Ñ?ов.

Читайте также:

• Закон Хайрама (Закон неÑ?вных интерфейÑ?ов)

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

• Медленный запуÑ?к Photoshop - проблема, Ñ? которой Ñ? Ñ?толкнулÑ?Ñ?. Photoshop медленно запуÑ?калÑ?Ñ?, иногда Ñ?то занимало неÑ?колько минут. Похоже, проблема была в том, что программа при запуÑ?ке Ñ?читывала информацию о дефолтном принтере. ЕÑ?ли принтер был Ñ?етевым, то Ñ?тот процеÑ?Ñ? мог занимать неприлично много времени. Ð?бÑ?тракциÑ? работы Ñ? Ñ?етевым принтером была той же, что длÑ? работы Ñ? локальным принтером. Ð?е был предуÑ?мотрен Ñ?ценарий Ñ?итуации Ñ? плохим качеÑ?твом подключениÑ? у клиента.

Закон тривиальноÑ?ти

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

Этот закон предполагает, что группы будут тратить больше времени на тривиальные или коÑ?метичеÑ?кие задачи, нежели на Ñ?ерьёзные и Ñ?ущеÑ?твенные.

Ð’ качеÑ?тве примера приводитÑ?Ñ? вымышленный комитет, работа которого заключалаÑ?ÑŒ в Ñ?оглаÑ?овании проекта атомной Ñ?лектроÑ?танции. Члены комитета проводÑ?Ñ‚ большую чаÑ?Ñ‚ÑŒ Ñ?воего времени за обÑ?уждением Ñ?труктуры велоÑ?ипедного навеÑ?а, а не гораздо более важного проекта Ñ?амой Ñ?лектроÑ?танции. Бывает трудно внеÑ?ти ценный вклад в диÑ?куÑ?Ñ?ию на очень большие и Ñ?ложные темы без выÑ?окой Ñ?тепени предметной Ñ?кÑ?пертизы или подготовки. Тем не менее, люди хотÑ?Ñ‚ вноÑ?ить ценный вклад. ОтÑ?юда возникает тенденциÑ? уделÑ?Ñ‚ÑŒ Ñ?лишком много времени мелким деталÑ?м, которые легко обоÑ?новываютÑ?Ñ?, но не обÑ?зательно имеют оÑ?обое значение.

Вымышленный пример, раÑ?Ñ?мотренный выше, привел к иÑ?пользованию термина «Bike Shedding» (еÑ?ли переводить доÑ?ловно, то получитÑ?Ñ? что-то вроде «Ñ?араÑ? длÑ? велоÑ?ипедов») в качеÑ?тве выражениÑ? длÑ? траты времени на тривиальные детали.

ФилоÑ?офиÑ? Unix

ФилоÑ?офиÑ? Unix в Википедии

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

Современные практики, такие как «Ð?рхитектура МикроÑ?ервиÑ?ов», могут раÑ?Ñ?матриватьÑ?Ñ? как применение Ñ?того закона. СервиÑ?Ñ‹ небольшие, Ñ?фокуÑ?ированы на одной Ñ?пецифичной задаче, что позволÑ?ет Ñ?оздать Ñ?ложное поведение путём Ñ?оÑ?тавлениÑ? проÑ?Ñ‚Ñ‹Ñ… Ñ?троительных блоков.

Модель Спотифай

Модель Спотифай в Википедии

Модель Спотифай — подход к организации команды и Ñ?труктуре компании, котораÑ? была популÑ?ризирована компанией-разработчиком Spotify. Ð’ Ñ?той модели команды организованы вокруг функций, а не технологий.

Модель Спотифай также популÑ?ризирует концепты «ОтрÑ?дов», «Племён», «Отделов» и «Гильдий», которые Ñ?влÑ?ÑŽÑ‚Ñ?Ñ? компонентами их организационной Ñ?труктуры: каждый из «отрÑ?дов» Ñ?фокуÑ?ирован на отдельной чаÑ?ти функциональноÑ?ти продукта, как то поиÑ?к или плейлиÑ?Ñ‚Ñ‹, что позволÑ?ет им Ñ?тановитьÑ?Ñ? Ñ?кÑ?пертами в Ñ?воих облаÑ?Ñ‚Ñ?Ñ…. Ð?а Ñ?ледующем уровне взаимодейÑ?твиÑ? «отрÑ?ды» Спотифай Ñ? общей или Ñ?хожей миÑ?Ñ?ией объединÑ?ÑŽÑ‚Ñ?Ñ? в «племена», проводÑ? периодичеÑ?кие (порой даже Ñ?понтанные) Ñ?обраниÑ? чтобы Ñ?корректировать общие цели. «Отделы» Ñ?оÑ?тоÑ?Ñ‚ из Ñ?отрудников одного профилÑ? (например, разработчики или теÑ?тировщики), которые регулÑ?рно вÑ?тречаютÑ?Ñ?, чтобы убедитьÑ?Ñ? в иÑ?пользовании новейших трендов и технологий, обмениватьÑ?Ñ? знаниÑ?ми и Ñ?ффективно переиÑ?пользовать Ñ?ущеÑ?твующие решениÑ?. «ГильдиÑ?» же предÑ?тавлÑ?ет Ñ?обой менее формальную и включающую в Ñ?ебÑ? большее количеÑ?тво людей группу: так, гильдиÑ? теÑ?тировщиков Ñ?оÑ?тоит не только из широкого круга теÑ?тировщиков (включаÑ? и автоматизаторов, и Ñ?пециалиÑ?тов по мануальному теÑ?тированию), но и из программиÑ?тов, которые хотÑ?Ñ‚ лучше понимать процеÑ?Ñ?Ñ‹ теÑ?тированиÑ? и вноÑ?ить Ñ?вой вклад в деÑ?тельноÑ?Ñ‚ÑŒ в Ñ?том направлении.

• Squad — отрÑ?д, Ñ?квивалент Ñ?крам-команды; автономен на Ñ?только, на Ñ?колько Ñ?то возможно;
• Tribe — племÑ?, организованы по принципу минимальной взаимозавиÑ?имоÑ?ти, чаще вÑ?его организуетÑ?Ñ? на уровне офиÑ?а до 100 человек;
• Chapter — отдел, объединÑ?ет людей по опыту или профилю;
• Guild — гильдиÑ?, Ñ?ообщеÑ?тво Ñ? обищим интереÑ?ами; не завиÑ?ит от Ñ?трутуры «племён»;
• PO — руководитель проекта (product owner).

Читайте также:

• СпиÑ?ок литературы: Spotify engineering culture

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

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

Ð’ любой конÑ?трукции Ñ?зыка времÑ?, затрачиваемое на обÑ?уждение функции из Ñ?того Ñ?пиÑ?ка, пропорционально двойке, возведённой в Ñ?тепень позиции в Ñ?пиÑ?ке.

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

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

Ð?налогично Закону тривиальноÑ?ти закон Вадлера глаÑ?ит, что при проектировании Ñ?зыка времÑ?, потраченное на Ñ?труктурные оÑ?обенноÑ?ти, непропорционально велико в Ñ?равнении Ñ? важноÑ?тью Ñ?тих функций.

Читайте также:

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

Принципы

Принципы больше похожи на гайдлайны длÑ? дизайна Ñ?иÑ?темы.

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

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

БольшинÑ?тво вещей в жизни раÑ?пределÑ?ÑŽÑ‚Ñ?Ñ? неравномерно.

Ð’ некоторых Ñ?лучаÑ?Ñ… оÑ?новной результат доÑ?тигаетÑ?Ñ? небольшими реÑ?урÑ?ами:

• 80% от общего объёма кода при разработке программного обеÑ?печениÑ? пишетÑ?Ñ? за 20% от выделÑ?емого времени (и напротив, Ñ?амые Ñ?ложные 20% кода отнимают 80% времени)
• 20% уÑ?илий дают 80% результата
• 20% работы обеÑ?печивают 80% дохода
• 20% багов приводÑ?Ñ‚ к 80% поломок

Ð’ 1940-Ñ… американо-румынÑ?кий инженер доктор Джозеф Юран, которому припиÑ?ывают Ñ?оздание контролÑ? качеÑ?тва, начал применÑ?Ñ‚ÑŒ принцип Парето в вопроÑ?ах качеÑ?тва.

Этот принцип также извеÑ?тен как правило 80/20.

Примеры из реальной жизни:

• Ð’ 2002 г. МайкроÑ?офт Ñ?ообщила, что поÑ?ле иÑ?правлениÑ? 20% багов, о которых Ñ?ообщалоÑ?ÑŒ чаще вÑ?его, 80% Ñ?вÑ?занных ошибок и поломок в Windows и MS Office проÑ?то пропадёт (ИÑ?точник).

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

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

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

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

Целью Ñ?того принципа Ñ?влÑ?етÑ?Ñ? поÑ?троение прочных Ñ?иÑ?тем, которые могут обработать плохо форматированный ввод, еÑ?ли Ñ?мыÑ?л Ñ?того ввода понÑ?тен. Впрочем, приём неправильного ввода имеет потенциальные поÑ?ледÑ?твиÑ? длÑ? безопаÑ?ноÑ?ти. ОÑ?обенно еÑ?ли процеÑ?Ñ? обработки такого ввода плохо протеÑ?тирован.

SOLID

Это акроним, который раÑ?шифровываетÑ?Ñ? Ñ?ледующим образом:

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

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

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

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

Каждый модуль или клаÑ?Ñ? должен иметь одну единÑ?твенную ответÑ?твенноÑ?Ñ‚ÑŒ.

Первый из пÑ?ти принципов SOLID. Этот принцип глаÑ?ит, что модуль или клаÑ?Ñ? должен делать вÑ?его одну вещь. Ð’ практичеÑ?ком Ñ?мыÑ?ле Ñ?то означает, что одно маленькое изменение при доработке программы должно требовать изменениÑ? только в одном компоненте. Ð?апример, изменение в механизме проверки Ñ?ложноÑ?ти паролÑ? должно потребовать изменениÑ? только в одной чаÑ?ти программы.

ТеоретичеÑ?ки Ñ?то должно делать код более надёжным и проÑ?тым длÑ? изменений. Знание, что изменённый компонент неÑ?Ñ‘Ñ‚ на Ñ?ебе единÑ?твенную ответÑ?твенноÑ?Ñ‚ÑŒ, означает, что теÑ?тирование Ñ?того изменениÑ? будет проÑ?тым. ВозвращаÑ?Ñ?ÑŒ к предыдущему примеру, изменениÑ? в компоненте проверки Ñ?ложноÑ?ти паролÑ? должны повлиÑ?Ñ‚ÑŒ только на чаÑ?Ñ‚ÑŒ программы, отвечающую за проверку паролÑ?. Гораздо Ñ?ложнее раÑ?Ñ?уждать о влиÑ?нии изменениÑ? в компоненте, у которого Ñ?разу неÑ?колько функций.

Читайте также:

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

Принцип открытоÑ?ти/закрытоÑ?ти

Принцип открытоÑ?ти/закрытоÑ?ти в Википедии

СущноÑ?ти должны быть открыты длÑ? раÑ?ширениÑ?, но закрыты длÑ? изменениÑ?.

Второй из пÑ?ти принципов SOLID. Этот принцип говорит, что Ñ?ущноÑ?ти (клаÑ?Ñ?Ñ‹, модули, функции и прочее) должны иметь возможноÑ?Ñ‚ÑŒ раÑ?ширÑ?Ñ‚ÑŒ Ñ?воё поведение, но их Ñ?ущеÑ?твующее поведение не должно изменÑ?Ñ‚ÑŒÑ?Ñ?.

Ð’ качеÑ?тве гипотетичеÑ?кого примера предÑ?тавьте модуль, который превращает разметку Markdown в HTML-документ. ЕÑ?ли можно добавить в модуль обработку новых возможноÑ?тей Markdown без изменениÑ? оÑ?новного поведениÑ? модулÑ?, то он будет Ñ?читатьÑ?Ñ? открытым длÑ? раÑ?ширениÑ?. ЕÑ?ли пользователь не может изменить в модуле Ñ?тандартную обработку Ñ?интакÑ?иÑ?а Markdown, то такой модуль будет Ñ?читатьÑ?Ñ? закрытым длÑ? изменений.

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

Читайте также:

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

Принцип подÑ?тановки Барбары ЛиÑ?ков

Принцип подÑ?тановки Барбары ЛиÑ?ков в Википедии

Должна быть возможноÑ?Ñ‚ÑŒ заменить тип на подтип без поломки Ñ?иÑ?темы.

(от редактора)

Ð?аÑ?ледующий клаÑ?Ñ? должен дополнÑ?Ñ‚ÑŒ, а не замещать поведение базового клаÑ?Ñ?а.

Третий из пÑ?ти принципов SOLID. Этот принцип указывает, что, еÑ?ли компонент завиÑ?ит от определённого типа, то должна быть возможноÑ?Ñ‚ÑŒ иÑ?пользовать подтип Ñ?того типа (производную от типа) без поломки вÑ?ей Ñ?иÑ?темы или необходимоÑ?ти знать детали того, что Ñ?то за подтип.

Ð’ качеÑ?тве примера предÑ?тавьте, что у наÑ? еÑ?Ñ‚ÑŒ метод, который читает XML-документ из файла. ЕÑ?ли метод иÑ?пользует в качеÑ?тве оÑ?новы тип 'file', то мы должны иметь возможноÑ?Ñ‚ÑŒ иÑ?пользовать в функции и любое производное от 'file'. ЕÑ?ли 'file' поддерживает поиÑ?к в обратном порÑ?дке, а парÑ?ер XML иÑ?пользует Ñ?ту возможноÑ?Ñ‚ÑŒ, и при Ñ?том подтип 'network file' выдаёт ошибку при попытке поиÑ?ка в обратном порÑ?дке, тогда подтип 'network file' нарушает опиÑ?ываемый принцип.

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

Читайте также:

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

Принцип разделениÑ? интерфейÑ?а

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

Программные Ñ?ущноÑ?ти не должны завиÑ?еть от методов, которые они не иÑ?пользуют.

Четвёртый из пÑ?ти принципов SOLID. Этот принцип говорит, что клиенты компонента не должны завиÑ?еть от функций Ñ?того компонента, еÑ?ли они не иÑ?пользуют их непоÑ?редÑ?твенно.

ПредÑ?тавьте, например, что у наÑ? еÑ?Ñ‚ÑŒ компонент, читающий XML из файла. Он должен только читать байты, двигаÑ?Ñ?ÑŒ вперёд или назад по файлу. ЕÑ?ли Ñ?тот метод потребуетÑ?Ñ? изменить потому, что в файловую Ñ?труктуру внеÑ?ены неÑ?вÑ?занные Ñ? ним изменениÑ? (например, обновление Ñ?иÑ?темы безопаÑ?ноÑ?ти длÑ? доÑ?тупа к файлу), тогда принцип будет нарушен.

Этот принцип оÑ?обо актуален длÑ? объектно-ориентированного программированиÑ?, где интерфейÑ?Ñ‹, иерархии и абÑ?трактные типы должны Ñ?тремитьÑ?Ñ? к минимизации зацеплениÑ? между разными компонентами. УтинаÑ? типизациÑ? — методологиÑ?, котораÑ? обеÑ?печивает Ñ?облюдение Ñ?того принципа при помощи иÑ?ключениÑ? Ñ?вных интерфейÑ?ов.

Читайте также:

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

Принцип инверÑ?ии завиÑ?имоÑ?тей

Принцип инверÑ?ии завиÑ?имоÑ?тей в Википедии

Ð’Ñ‹Ñ?окоуровневые модули не должны завиÑ?еть от низкоуровневой реализации.

ПÑ?тый из принципов SOLID. Из Ñ?того принципа Ñ?ледует, что выÑ?ший уровень управлÑ?ющих компонентов не должен знать о деталÑ?Ñ… реализации завиÑ?имоÑ?тей.

Ð’ качеÑ?тве примера предÑ?тавьте, что у наÑ? еÑ?Ñ‚ÑŒ программа, котораÑ? Ñ?читывает мета-данные Ñ? Ñ?айта. Мы предполагаем, что главный компонент должен знать о компоненте, занимающимÑ?Ñ? Ñ?качиванием контента Ñ? Ñ?айта, а затем и о компоненте, Ñ?читывающем мета-данные. ЕÑ?ли мы примем во внимание инверÑ?ию завиÑ?имоÑ?тей, то оÑ?новной компонент будет завиÑ?еть только от абÑ?трактного компонента, который может извлекать байтовые данные, а затем от абÑ?трактного компонента, который мог бы Ñ?читывать метаданные из байтового потока. ОÑ?новной компонент не будет знать о TCP/IP, HTTP, HTML и прочем.

Этот принцип Ñ?ложный. Может показатьÑ?Ñ?, что он «инвертирует» вероÑ?тные завиÑ?имоÑ?ти Ñ?иÑ?темы (отÑ?юда и название). Ð?а практике Ñ?то также означает, что отдельный управлÑ?ющий компонент должен гарантировать, что иÑ?пользуютÑ?Ñ? правильные реализации абÑ?трактных типов (например, в предыдущем примере нечто должно по-прежнему предоÑ?тавлÑ?Ñ‚ÑŒ компоненту чтениÑ? метаданных загрузчик файлов HTTP и Ñ?редÑ?тво чтениÑ? метатегов HTML). Это также каÑ?аетÑ?Ñ? таких шаблонов, как ИнверÑ?иÑ? управлениÑ? и Внедрение завиÑ?имоÑ?ти.

Читайте также:

• Объектно-ориентированное программирование
• SOLID
• Inversion of Control
• Dependency Injection

Принцип DRY

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

КаждаÑ? чаÑ?Ñ‚ÑŒ знаниÑ? должна иметь единÑ?твенное, непротиворечивое и авторитетное предÑ?тавление в рамках Ñ?иÑ?темы.

DRY Ñ?то акроним от фразы Don't Repeat Yourself («Ð?е повторÑ?й Ñ?ебÑ?»). Этот принцип призван помочь разработчикам избежать повторений в коде и хранить информацию в одном меÑ?те. Был впервые опиÑ?ан в 1999 году в книге The Pragmatic Developer Эндрю Ханта и Дейва ТомаÑ?а.

Принципу DRY полноÑ?тью противоположен принцип WET — Write Everything Twice или We Enjoy Typing (Пиши вÑ?Ñ‘ дважды или Мы любим печатать).

Ð?а практике, еÑ?ли у ваÑ? еÑ?Ñ‚ÑŒ два одинаковых куÑ?ка кода в двух или более меÑ?тах, то вы можете воÑ?пользоватьÑ?Ñ? принципом DRY и объединить их в один, переиÑ?пользуÑ? там, где он необходим.

Читайте также:

• СпиÑ?ок литературы: The Pragmatic Developer

Принцип YAGNI

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

Ð?кроним You Aren't Gonna Need It (англ. Вам Ñ?то не понадобитÑ?Ñ?).

Ð’Ñ?егда имплементируйте функционал, когда он вам дейÑ?твительно нужен, и не делайте Ñ?того, когда лишь предвидите необходимоÑ?Ñ‚ÑŒ в нем.

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

Данный принцип ЭкÑ?тремального ПрограммированиÑ? предполагает, что разработчики имплементируют лишь тот функционал, который необходим длÑ? выполнениÑ? текущих требований, и Ñ?тремÑ?Ñ‚Ñ?Ñ? не предÑ?казывать будущие требованиÑ?, имплементируÑ? то, что может понадобитьÑ?Ñ? позже.

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

Читайте также:

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

Принцип KISS

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

KISS Ñ?то акроним от фразы Keep it simple, stupid («СохранÑ?й проÑ?тоту») или Keep it stupid simple («СохранÑ?й вещи до глупого проÑ?тыми»). Принцип KISS утверждает, что большинÑ?тво Ñ?иÑ?тем работают лучше вÑ?его, еÑ?ли они оÑ?таютÑ?Ñ? проÑ?тыми, а не уÑ?ложнÑ?ÑŽÑ‚Ñ?Ñ?. ПоÑ?тому в облаÑ?ти проектированиÑ? проÑ?тота должна быть одной из ключевых целей, и Ñ?ледует избегать ненужной Ñ?ложноÑ?ти.

Ð?а практике:

• Разбивайте задачи на подзадачи которые не должны по вашему мнению длитьÑ?Ñ? более 4-12 чаÑ?ов напиÑ?аниÑ? кода
• Разбивайте задачу на множеÑ?тво более маленьких задач, каждаÑ? задача должна решатьÑ?Ñ? одним или парой клаÑ?Ñ?ов
• СохранÑ?йте ваши методы маленькими. Каждый метод должен Ñ?оÑ?тоÑ?Ñ‚ÑŒ не более чем из 30-40 Ñ?трок. Каждый метод должен решать одну маленькую задачу, а не множеÑ?тво Ñ?лучаев. ЕÑ?ли в вашем методе множеÑ?тво уÑ?ловий, разбейте его на неÑ?колько. Это повыÑ?ит читаемоÑ?Ñ‚ÑŒ, позволит легче поддерживать код и быÑ?трее находить ошибки в нём. Ð’Ñ‹ полюбите улучшать код.
• СохранÑ?йте ваши клаÑ?Ñ?Ñ‹ маленькими. ЗдеÑ?ÑŒ применÑ?етÑ?Ñ? та же техника что и Ñ? методами.
• Придумайте решение задачи Ñ?начала, потом напишите код. Ð?икогда не поÑ?тупайте иначе. Многие разработчики придумывают решение задачи во времÑ? напиÑ?аниÑ? кода и в Ñ?том нет ничего плохого. Ð’Ñ‹ можете делать так и при Ñ?том придерживатьÑ?Ñ? выше обозначенного правила. ЕÑ?ли вы можете в уме разбивать задачу на более мелкие чаÑ?ти, когда вы пишете код, делайте Ñ?то любыми Ñ?поÑ?обами. И не бойтеÑ?ÑŒ перепиÑ?ывать код ещё и ещё и ещё… Ð’ Ñ?чёт не идёт чиÑ?ло Ñ?трок, до тех пор пока вы Ñ?читаете что можно ещё меньше/ещё лучше.
• Ð?е бойтеÑ?ÑŒ избавлÑ?Ñ‚ÑŒÑ?Ñ? от кода. Изменение Ñ?тарого кода и напиÑ?ание нового решениÑ? два очень важных момента. ЕÑ?ли вы Ñ?толкнулиÑ?ÑŒ Ñ? новыми требованиÑ?ми, или не были оповещены о них ранее, тогда порой лучше придумать новое более изÑ?щное решение решающее и Ñ?тарые и новые задачи.

Читайте также:

• СпиÑ?ок литературы: Apache Kiss Principle

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

ЕÑ?ли ваÑ? заинтереÑ?овали перечиÑ?ленные концепции, то вам могут понравитьÑ?Ñ? Ñ?ледующие материалы:

• Закон Ð?мдала, Supercomputer Software Department
• Закон Ð?мдала, Герман Горелкин, 11 декабрÑ? 2018
• The Mythical Man Month - Frederick P. Brooks Jr. - КлаÑ?Ñ?ичеÑ?кий труд о разработке ПО. Закон БрукÑ?а в центре повеÑ?твованиÑ?.
• Gödel, Escher, Bach: An Eternal Golden Braid - Douglas R. Hofstadter. - Эту книгу Ñ?ложно клаÑ?Ñ?ифицировать. Закон Хофштадтера опиÑ?ан именно в Ñ?той книге.
• Spotify engineering culture
• How to Build Your Own “Spotify Modelâ€?
• The Pragmatic Developer
• Extreme Programming Installed - Ron Jeffries, Ann Anderson, Chet Hendrikson - Покрывает ключевые принципы методологии Ñ?кÑ?тремального программированиÑ?.
• Philip Hanik. Kiss Principle

TODO

Привет! ЕÑ?ли вы Ñ?то читаете, то вы перешли по Ñ?Ñ?ылке на Ñ?татью, котораÑ? ещё не напиÑ?ана. ПроÑ?тите за Ñ?то! Я работаю над Ñ?тим.

Ð?е Ñ?теÑ?нÑ?йтеÑ?ÑŒ заводить issue Ñ? пожеланиÑ?ми или приÑ?ылайте Pull Request Ñ?о Ñ?воими правками или новыми темами.

Они внеÑ?ли Ñ?вой вклад

Большое Ñ?паÑ?ибо Ñ?тим прекраÑ?ным людÑ?м (что значат emoji?):

Alexandr Kizilow 🖋

Natalia Ryzhova 🖋

Anastasia Lopatina 🖋

Nikita Slimov 🖋

Realetive 🖋

Ivan Prodaiko 🖋