Для чего нужны законы развития компьютерных систем?

S-программы самые простые: их функциональность формально определяется спецификацией и выводится из нее. Именно такие программы нравятся учебникам.

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

P-программы — это реальные решения проблем. Это переносит нас на территорию «модели модели внутри теории…».

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

Критическое различие между S-программами и P-программами заключается в том, что в P-программах внимание сосредоточено на том, насколько хорошо решение работает в реальном контексте. Если реальные результаты отличаются от желаемых, проблема не изменилась, но программа должна измениться. Для любой программы, взаимодействующей с реальным миром таким образом, есть еще один факт жизни, который нельзя игнорировать: мир тоже меняется.

Таким образом, P-программы, скорее всего, будут претерпевать бесконечные изменения или становиться все менее и менее эффективными и рентабельными.

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

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

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

Принимая во внимание, что S-программы теоретически всегда могут быть доказуемы правильными, определение «правильности» для E-программ основано на результатах, которые они вызывают в реальном мире. Это кое-что говорит нам об ограничениях формальных методов: что они могут и чего не могут сделать для нас.

Корректность и доказательство корректности (E-) программы могут быть формально правильными, но бесполезными, или неверными в том смысле, что они не удовлетворяют какой-либо заявленной спецификации, но вполне пригодными для использования, даже удовлетворительными. Формальные методы представления и доказательства занимают место во вселенной (P- и E-) программ, но их роль меняется. Интерес представляет подробное поведение программы в рабочих условиях.

Раздел II.F статьи содержит еще одно интересное утверждение, над которым можно долго думать: «всегда можно продолжать процесс разбиения системы (E- или P-программы) до тех пор, пока все модули не будут реализуемы как S-программы." Полученные модули можно на данный момент считать полными и правильными.

Как развиваются программы

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

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

Последовательность выпусков происходит с поколением системы. В более широком масштабе у нас также есть последовательные поколения системных последовательностей

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

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

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

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

Это реально? Как руководители, наблюдающие за проектами с высоты 50 000 футов, действительно могут понять, что происходит? Разве не только разработчики знают правду? Руководитель, разбирающийся в системах и программном обеспечении, может быть эффективным, если понимает динамику и законы эволюции программы:

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

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

Информированная стратегия

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

Закон непрерывных изменений гласит, что (P- и E-) программы никогда не бывают «законченными», и мы должны ожидать постоянных изменений. Изменения необходимы даже для того, чтобы стоять на месте — программа, которая не меняется, чтобы идти в ногу с изменениями в реальном мире, распадается.

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

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

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

Последствия этих четырех законов и…

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

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

Заключительный раздел документа (V. Прикладная динамика) представляет собой тематическое исследование того, как знание этих законов можно использовать для управления процессами долгосрочного планирования. Lehman анализирует выпуски System X (пакетной операционной системы общего назначения) до одного, рассматривая количество модулей, добавляемых и изменяемых в каждом выпуске, как показатель сложности. Глядя на среднее количество модулей, изменяемых в день во время релиза, можно увидеть, что релизы, которые повышают скорость, как правило, были «чрезвычайно» хлопотными и сопровождались значительной очисткой.Точно так же выпуски, которые превышали нормальный инкрементальный базовый уровень роста модулей (количество новых модулей), также имели тенденцию оставлять основу низкого качества, и за ними должен был следовать исправляющий выпуск. Таким образом становится возможным наблюдать за текущими темпами изменений и дополнений, а также оценивать вероятные лежащие в их основе тенденции качества и то, что можно сделать в ближайшем будущем.

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

Последнее слово

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

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

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

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

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

Это очень большой пост, поэтому я включил индекс, если вы хотите что-то пропустить:

Закон Мерфи

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

Если что-то может пойти не так, так оно и будет.

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

Защитное программирование, контроль версий, гибельные сценарии (для этих проклятых атак зомби-серверов), TDD, MDD и т. д. — все это хорошие методы защиты от этого закона.

Закон Брука

Большинство разработчиков сознательно или неосознанно имеют опыт работы с законом Брука, который гласит:

Добавление рабочей силы к позднему программному проекту делает его более поздним.

Если проект задерживается, простое добавление рабочей силы, скорее всего, приведет к катастрофическим последствиям. Поиск и анализ уровня эффективности программирования, методологии программного обеспечения, технической архитектуры и т. д. почти всегда дает лучшие результаты. Или нет, что, вероятно, означает, что закон Хофштадтера также действует.

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

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

Этот закон — конечно же — не следует путать с законом Леонарда Хофштадтера из теории Большого взрыва. Хотя для некоторых из вас его цитата будет иметь смысл.

Правило гласит:

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

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

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

Закон Конвея

Любая часть программного обеспечения отражает организационную структуру, которая его создала.

Или еще точнее:

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

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

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

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

Закон Постела, также известный как принцип устойчивости

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

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

В сегодняшней напряженной политической обстановке закон Постеля является объединяющим фактором.

Принцип Парето, также известный как правило 80-20

Для многих явлений 80 % последствий вытекают из 20 % причин.

Это принцип, лежащий в основе горькой правды о том, что 80% ошибок в коде возникают из-за 20% кода.
Иными словами, 80% работы в компании выполняется 20% персонала. Проблема в том, что вы не всегда имеете четкое представление о том, какие именно 20%.

Принцип Питера

Довольно удручающий и временами разочаровывающий закон, особенно если вам посчастливилось иметь непосредственный опыт.

В иерархии каждый сотрудник стремится подняться до своего уровня некомпетентности.

Просто прочитайте «Дилберта» (или посмотрите «Офис»), чтобы увидеть несколько примеров этого в действии.
Что касается Дилберта, то он далеко не мой любимый!

Принцип Керхгофа

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

Это основной принцип, лежащий в основе криптографии с открытым ключом.

Закон Линуса

Этот закон, названный в честь Линуса Торвальдса, создателя Linux, гласит:

При достаточном количестве просмотров все ошибки неглубокие.

Этот закон был описан с использованием знаменитого эссе "Собор и базар", объясняющего контраст между двумя разными моделями разработки свободного программного обеспечения:

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

Вывод? Чем более широко доступен исходный код для публичного тестирования, проверки и экспериментирования, тем быстрее будут обнаружены все виды ошибок.

Закон Мура

Мощность компьютеров на единицу стоимости удваивается каждые 24 месяца.

Самая популярная версия гласит:

Количество транзисторов в интегральной схеме удвоится примерно через 18 месяцев.

Скорость обработки компьютеров будет удваиваться каждые два года!

Закон Вирта

Программное обеспечение становится медленнее, чем оборудование работает быстрее.

Возьмите этот закон Мура!

Правило девяноста-девяноста

Первые 90% кода занимают 10% времени. Оставшиеся 10 % занимают оставшиеся 90 % времени

Это правда. Кто с этим не согласен?

Принцип оптимизации Кнута

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

Сначала вы пишете код, затем выявляете узкие места, а затем исправляете!

Закон Норвига

Любая технология, уровень проникновения которой превышает 50 %, никогда больше не удвоится (ни через сколько месяцев).

Заключение

Мне нравятся эти "законы", поскольку у каждого из них есть своя история, своя предыстория. И как консультант или архитектор вы должны с ними ознакомиться. Так что для меня и, возможно, для вас у меня есть список самых используемых и самых известных законов в разработке программного обеспечения!

Я пропустил ваш любимый закон? Согласны ли вы (или нет) с каждым законом или имеете (забавный) опыт с одним из них? Какой твой любимый? Дайте мне знать, используя раздел комментариев!

Это широко известное изречение восходит к философу и монаху четырнадцатого века по имени Уильям Оккам. Бритва Оккама часто формулируется как:

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

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

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

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

Однако я стараюсь помнить, что подавляющее большинство действий, совершаемых людьми, которые могут показаться злонамеренными, совершаются непреднамеренно. Скорее, потому, что они не знают ничего лучшего. В этом суть пословицы, известной как «Бритва Хэнлона», которая гласит:

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

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

Принцип Парето

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

"80% следствий проистекают из 20% причин."

Случалось ли вам сталкиваться с ситуацией, когда ваше приложение содержит сотни ошибок, но когда вы отслеживаете одну из них, непропорционально большое количество указанных ошибок просто возникает и исчезает? Если да (и, вероятно, так и было), то вы испытали принцип Парето в действии. Многие из проблем, с которыми мы сталкиваемся, будь то кодирование, общение с клиентами или просто жизнь, имеют небольшой набор общих корневых проблем, которые, если их решить или облегчить, могут привести к исчезновению большинства или всех проблем, которые мы видим.

Короче говоря, самый быстрый способ решить сразу много проблем — найти и устранить их общую причину.

Эффект Даннинга-Крюгера

Исследователи Дэвид Даннинг и Джастин Крюгер, проводя эксперимент в 1999 году, наблюдали явление, известное как эффект Даннинга-Крюгера:

"Неквалифицированные люди склонны ошибочно оценивать свои способности как более компетентные, чем они есть на самом деле".

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

Закон Линуса

Автор и разработчик Эрик С. Рэймонд разработал этот закон, названный им в честь Линуса Торвальдса. Закон Линуса гласит:

"Учитывая достаточное количество глазных яблок, все ошибки неглубокие."

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

Принцип устойчивости (также известный как закон Постеля)

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

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

Этот принцип также называется законом Постела Джона Постела, пионера Интернета, который первоначально записал его как часть RFC 760. Его стоит помнить, хотя бы по той простой причине, что он мягко напоминает, что часто лучший код — это отсутствие кода в самом начале. все.

Закон Иглсона

Вы когда-нибудь долго не участвовали в проекте, а потом возвращались к нему и задавались вопросом: "Какой идиот написал эту хрень?" только чтобы узнать, что идиотом был ты?

Закон Иглсона довольно точно описывает эту ситуацию:

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

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

Принцип Питера

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

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

Принцип Питера часто саркастически сводится к следующему: «Менеджеры поднимаются до уровня своей некомпетентности». Идея этого принципа выглядит так:

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

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

Вы когда-нибудь замечали, что выполнение чего-то всегда занимает больше времени, чем вы думаете? То же самое сделал Дуглас Хофштадтер, написавший основополагающую книгу по когнитивной науке и самореференции под названием «Гедель, Эшер, Бах: вечная золотая коса». В этой книге он предложил закон Хофштадтера:

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

Всегда — ключевое слово: ничто никогда не идет по плану, поэтому лучше потратить дополнительное время на оценку того, что может пойти не так, потому что так оно и есть.

Правило 90-90

Поскольку что-то всегда идет не так, а люди, как известно, плохо оценивают собственный уровень навыков, Том Каргилл, инженер Bell Labs, в 1980-х годах предложил то, что впоследствии стало называться правилом 90-90:

"На первые 90 процентов кода приходится первые 90 процентов времени разработки. Остальные 10 процентов кода составляют остальные 90 процентов времени разработки."

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

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

Возможно, самое проницательное наблюдение, которое можно применить к искусству оценки, принадлежит британскому военно-морскому историку К. Н. Паркинсону. Он в шутку предложил поговорку под названием «Закон Паркинсона», которая первоначально понималась как:

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

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

Закон Сейра

Экономист и профессор Чарльз Иссауи предложил идею, которая стала известна как закон Сейра, названный в честь коллеги-профессора Колумбийского университета. Формулировка этого закона Иссави выглядит следующим образом:

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

Короче говоря, чем менее значимо что-то, тем яростнее люди будут об этом спорить.

Закон тривиальности Паркинсона (он же Bikeshedding)

Закон Сейра непосредственно переходит в другой закон, применимый к собраниям, и здесь мы снова сталкиваемся с идеями К.Н. Паркинсон. Закон тривиальности Паркинсона гласит:

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

Паркинсон представил ситуацию, в которой группе людей поручили спроектировать ядерный реактор. Затем указанный комитет тратит непропорционально много времени на проектирование велопарковки реактора, поскольку у любого обычного человека будет достаточно жизненного опыта, чтобы понять, как должна выглядеть велопарковка. Ясно, что «основные» функции реактора более важны, но они настолько сложны, что ни один обычный человек не разберется в них во всех подробностях.Следовательно, время (и мнения) тратятся на идеи, которые могут понять все, но которые явно более тривиальны.

Закон аргументативного понимания

Последний закон полностью выдумал я и использую для обозначения как закона Сейра, так и закона тривиальности Паркинсона. Я называю это Законом Аргументативного Понимания:

"Чем больше люди что-то понимают, тем охотнее они об этом спорят и тем энергичнее они это делают".

Обзор

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

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

Пропустил ли я какие-либо законы, которые вы считаете основополагающими для процесса создания программного обеспечения, или какую-либо деятельность, связанную с указанным процессом (например, оценки, встречи и т. д.)? Поделитесь в комментариях!

Карла Тарди — технический редактор и продюсер цифрового контента с более чем 25-летним опытом работы в ведущих инвестиционных банках и компаниях по управлению капиталом.

Маргарита является сертифицированным специалистом по финансовому планированию (CFP®), сертифицированным консультантом по пенсионному планированию (CRPC®), сертифицированным специалистом по пенсионному доходу (RICP®) и сертифицированным консультантом по социально ответственным инвестициям (CSRIC). Она работает в сфере финансового планирования более 20 лет и проводит дни, помогая своим клиентам обрести ясность, уверенность и контроль над своей финансовой жизнью.

Что такое закон Мура?

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

Ключевые выводы

• Закон Мура гласит, что количество транзисторов в микрочипе удваивается примерно каждые два года, хотя стоимость компьютеров снижается вдвое.
• В 1965 году Гордон Э. Мур, один из основателей Intel, сделал наблюдение, известное как закон Мура.
• Другой принцип закона Мура гласит, что рост числа микропроцессоров экспоненциальный.

Смотрите сейчас: что такое закон Мура?

Понимание закона Мура

В 1965 году Гордон Э. Мур, соучредитель компании Intel (INTC), предположил, что количество транзисторов, которые можно разместить в данной единице пространства, будет удваиваться примерно каждые два года.

Гордон Мур не называл свое наблюдение "законом Мура" и не собирался создавать "закон". Мур сделал это заявление, отметив новые тенденции в производстве чипов в Intel. В конце концов догадка Мура превратилась в предсказание, которое, в свою очередь, стало золотым правилом, известным как закон Мура.

В течение десятилетий, последовавших за первоначальным наблюдением Гордона Мура, закон Мура руководил полупроводниковой промышленностью при долгосрочном планировании и определении целей для исследований и разработок (НИОКР). Закон Мура был движущей силой технологических и социальных изменений, производительности и экономического роста, характерных для конца двадцатого и начала двадцать первого веков.

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

Почти 60 лет; Все еще сильно

Спустя более 50 лет мы ощущаем непреходящее влияние и преимущества закона Мура во многих отношениях.

Вычисления

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

Электроника

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

Выгода для всех секторов

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

Неизбежный конец закона Мура

Эксперты сходятся во мнении, что в 2020-х годах компьютеры должны достичь физических пределов закона Мура. Высокие температуры транзисторов в конечном итоге сделают невозможным создание схем меньшего размера. Это связано с тем, что для охлаждения транзисторов требуется больше энергии, чем количество энергии, которое уже проходит через транзисторы. В интервью 2005 года сам Мур признал, что «тот факт, что материалы состоят из атомов, является фундаментальным ограничением, и это не так уж и далеко. Мы преодолеваем некоторые довольно фундаментальные ограничения, поэтому однажды мы собираемся нужно перестать делать вещи меньше."

Создать невозможное?

Тот факт, что закон Мура приближается к своей естественной смерти, возможно, наиболее болезненно проявляется у самих производителей чипов; поскольку эти компании обременены задачей создания все более мощных чипов вопреки реальным физическим трудностям. Даже Intel соревнуется сама с собой и со своей отраслью, создавая то, что в конечном итоге может оказаться невозможным.

В 2012 году корпорация Intel смогла похвастаться выпуском 22-нанометрового процессора с самыми маленькими и самыми современными транзисторами в массовом производстве. В 2014 году Intel выпустила еще более компактный и мощный 14-нм чип; и сегодня компания изо всех сил пытается вывести на рынок свой 10-нм чип.

Для сравнения, один нанометр равен одной миллиардной части метра, что меньше длины волны видимого света. Диаметр атома колеблется от 0,1 до 0,5 нанометра.

Особые соображения

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

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

Что такое закон Мура?

В 1965 году Джордж Мур заявил, что примерно каждые два года количество транзисторов в микросхемах удваивается. Это явление, обычно называемое законом Мура, предполагает, что вычислительный прогресс со временем станет значительно быстрее, меньше и эффективнее. Закон Мура, широко известный как одна из основных теорий 21 века, имеет важные последствия для будущего технического прогресса — наряду с его возможными ограничениями.

Как закон Мура повлиял на вычислительную технику?

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

Закону Мура приходит конец?

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

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

Хотя информатика не совсем похожа на физику, где существуют наблюдаемые законы природы, исследователи обнаружили ряд "законов". Они могут показаться старомодными, но они являются основой, на которой строятся инновации. Проверьте это!

Закон Мура

Закон Мура, пожалуй, самый известный «закон» в компьютерном мире. Он назван в честь основателя Intel Гордона Мура. В статье 1965 года он заметил, что количество транзисторов в интегральной схеме удваивается примерно каждые два года.Это означало, что чипы обладали большей функциональностью, чем раньше, по той же цене. Другими словами, со временем чипы делали больше за меньшие деньги.

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

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

Закон Меткалфа

По мере того, как устройства дешевеют, их покупают все больше людей. И чем больше людей их покупают, тем ценнее становится сеть устройств.

Закон Меткалфа приписывается Бобу Меткалфу, одному из создателей сетевого протокола Ethernet. Он предположил, что если есть N пользователей телекоммуникационной сети, ценность сети равна N 2 . Каждый новый человек, который подключается к телефонной сети, увеличивает количество возможных подключений, исключая такие вещи, как языковые различия. То же самое касается сайтов социальных сетей. Если вы являетесь участником Facebook, вы, вероятно, присоединились, потому что все ваши друзья есть на Facebook.

Закон Рида

В соответствии с законом Меткалфа закон Рида, разработанный ученым-компьютерщиком Дэвидом П. Ридом, гласит, что полезность больших сетей может увеличиваться экспоненциально с размером сети. Другими словами, количество возможных подгрупп сети равно 2 N - N - 1, где N - количество людей, пользующихся сетью. Этот закон является причиной того, что вещи могут стать вирусными в социальных сетях. Это также объясняет популярность социальных сетей. Чем больше людей присоединяется к ним, тем больше они могут общаться с другими людьми, разделяющими их интересы, что повышает ценность сети.

Как объясняет сам Рид:

Это изменение ценности, вызванное масштабированием, можно наблюдать в истории Интернета. В самом раннем использовании Интернета преобладала его роль терминальной сети, позволяющей многим терминалам выборочно получать доступ к небольшому количеству дорогостоящих хостов с разделением времени. По мере роста Интернета гораздо большая часть использования и ценности Интернета стала сосредоточена на парном обмене сообщениями электронной почты, файлами и т. Д. В соответствии с законом Меткалфа. А когда в начале 90-х Интернет начал набирать обороты, в трафике стали доминировать «группы новостей» (интернет-дискуссионные группы), созданные пользователями списки рассылки, веб-сайты с особыми интересами и т. д., следуя экспоненциальному закону GFN. Хотя ранее доминирующие функции не теряли ценности и не снижались по мере роста масштабов Интернета, ценность и использование услуг, которые масштабировались в соответствии с новыми доминирующими законами масштабирования, росли быстрее. Таким образом, многие виды транзакций и сотрудничества, которые проводились за пределами Интернета, были поглощены ростом функций Интернета, и они стали новым полем для конкуренции.

Закон Бекстрома

У Рода Бекстрома более сложная модель сетевой полезности. Закон Бекстрома определяет ценность сети как прибыль за вычетом затрат, суммированных с общим числом участников сети.

Тейлор Бьюли, пишущий для Forbes, приводит хороший конкретный пример:

Вот пример. Допустим, вы покупаете на Amazon товары на 100 долларов каждый месяц в течение года. Вы, вероятно, могли бы купить эти вещи в автономном режиме примерно по той же цене, но вы могли бы доплатить за бензин, чтобы доехать до магазина, и альтернативную стоимость вашего времени. Если бы стоимость обычной коммерции составляла 50 долларов в месяц помимо 100 долларов, которые вы тратите на книги, то ценность сети Amazon для вас составила бы 600 долларов в год. Вычтите из этой суммы стоимость подключения к сети Amazon, возможно, 40 долларов США в месяц за подключение к Интернету и компьютерное оборудование, и вы получите примерно 120 долларов США.

Закон Брукса

От мира сетей к миру разработки программного обеспечения отвечает Фред Брукс, автор классической книги Мифический человеко-месяц. Закон Брукса, взятый из книги, должен послужить предупреждением любому менеджеру по продукту. "Добавление рабочей силы к позднему проекту делает его более поздним."

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

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

Дуглас Хофштадтер популяризировал концепцию рекурсии в своей классической книге, получившей Пулитцеровскую премию, Гедель, Эшер, Бах: вечная золотая коса. Хотя книга не совсем о компьютерах, она оказала большое влияние на компьютерную индустрию. Хофштадтер придумал свой собственный юмористический закон, известный как закон Хосфтадтера: "Это всегда занимает больше времени, чем вы ожидаете, даже если принять во внимание закон Хофштадтера".

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

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

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

  
• Управление Nba 2k21 на джойстике ps4
  
• Как поставить звездочку над числом в Excel
  
• Отметьте все вопросы, относящиеся к понятию компьютерной архитектуры
  
• Как запустить файл go
  
• Как сделать скриншот на планшете bq