solarrust / hacker-laws

💻📖 hacker-laws

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

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

В�?тупление

Суще�?твует много законов, которые люди об�?уждают, говор�? о разработке. Этот репозиторий �?обрал в �?ебе �?�?ылки и обзоры наиболее ра�?про�?транённых. Пожалуй�?та, делите�?ь им и при�?ылайте 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».

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

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

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

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

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

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

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

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

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

Закон Каннингема можно также ра�?�?матривать как �?квивалент француз�?кой поговорки «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 у таких юзеров.

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

Закон Мура

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

Количе�?тво транзи�?торов в интегральной �?хеме удваивает�?�? примерно каждые два года.

Ча�?то и�?пользуемый дл�? иллю�?трации �?коро�?ти, �? которой улучшают�?�? технологии производ�?тва полупроводников и чипов, прогноз Мура был очень точным �? 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

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

Семантика

Синтак�?и�?

Лек�?иче�?кий �?интак�?и�?

Лек�?иче�?кий �?интак�?и�? комментариев

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

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

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

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

Принципы

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

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

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

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

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

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

В 1940-х американо-румын�?кий инженер доктор Джозеф Юран, которому припи�?ывают �?оздание контрол�? каче�?тва, начал примен�?ть принцип Парето в вопро�?ах каче�?тва.

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

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

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

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

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

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

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

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

SOLID

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вы�?окоуровневые модули не должны зави�?еть от низкоуровневой реализации.

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

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

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

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

Принцип 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 �?трок. Каждый метод должен решать одну маленькую задачу, а не множе�?тво �?лучаев. Е�?ли в вашем методе множе�?тво у�?ловий, разбейте его на не�?колько. Это повы�?ит читаемо�?ть, позволит легче поддерживать код и бы�?трее находить ошибки в нём. Вы полюбите улучшать код.
Сохран�?йте ваши кла�?�?ы маленькими. Зде�?ь примен�?ет�?�? та же техника что и �? методами.
Придумайте решение задачи �?начала, потом напишите код. �?икогда не по�?тупайте иначе. Многие разработчики придумывают решение задачи во врем�? напи�?ани�? кода и в �?том нет ничего плохого. Вы можете делать так и при �?том придерживать�?�? выше обозначенного правила. Е�?ли вы можете в уме разбивать задачу на более мелкие ча�?ти, когда вы пишете код, делайте �?то любыми �?по�?обами. И не бойте�?ь перепи�?ывать код ещё и ещё и ещё… В �?чёт не идёт чи�?ло �?трок, до тех пор пока вы �?читаете что можно ещё меньше/ещё лучше.
�?е бойте�?ь избавл�?ть�?�? от кода. Изменение �?тарого кода и напи�?ание нового решени�? два очень важных момента. Е�?ли вы �?толкнули�?ь �? новыми требовани�?ми, или не были оповещены о них ранее, тогда порой лучше придумать новое более из�?щное решение решающее и �?тарые и новые задачи.

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