Логическая ошибка золотой молоток

Синонимы

• Золотой молот
• Исключительность
• Persimplex responsum
• Очень простой ответ

Объяснение

«Для того, у кого есть только молоток, всё будет казаться гвоздями». Данная ошибка происходит в случае, если предлагается подобное решение к каждой возникшей проблеме. Одним из примеров являются продавцы змеиного яда с их лекарством от всех болезней. Другим — стремление креационистов использовать Бога в качестве универсального объяснения.

См. также

• Почему креационизм не является научной теорией?
• Подавленное доказательство

Внешние ссылки

• Страница ЭвоВики данной логической ошибки [1].
• The Free Dictionary [2]

Примеры в утверждениях креационистов

• Библию следует понимать буквально

Что такое анти-паттерны?

Анти-паттерны — полная противоположность паттернам. Если паттерны проектирования —
это примеры практик хорошего программирования, то есть шаблоны решения определённых задач. То анти-паттерны — их полная противоположность, это — шаблоны ошибок, которые совершаются при решении различных задач. Частью практик хорошего программирования является именно избежание анти-паттернов. Не надо думать, что это такая непонятная теоретическая фигня — это конкретные проблемы, с которыми сталкивался практически каждый разработчик. Кто осведомлен, тот и вооружён! Рассмотрим же несколько расрпотранённых анти-паттернов в программировании.

Программирование копи-пастом (Copy and Paste Programming)

Данный анти-паттерн является, наверное, самым древним в программировании. Когда от программиста требуется написание двух схожих функций, самым «простым» решением является написание одной функции, её копирование и внесение некоторых изменений в копию. Какие проблемы это сулит? Во-первых, ухудшается переносимость кода — если потребуется подобный функционал в другом проекте, то надо будет искать все места, где программист накопипастил и переносить их по отдельности. Во-вторых, понижается качество кода — часто программист забывает вносить требуемые изменения в скопированный код. В-третьих, усложняется поддержка кода — так, как если в изначальном варианте был баг, который в будущем надо будет исправить, то этот баг попал во все то, что, опять-таки, накопипастил программист. Это приводит так же к возникновению различных множественных исправлений, которые будут возникать по мере нахождения бага в разных частях кода, для одного единственного бага. В-четвертых, code review значительно усложняется, так как кода становится больше, без видимой значительной выгоды и роста производительности труда. Главными причинами возникновения подобных ошибок являются — отсутствие мыслей про будущее разработки (программисты не продумывают свои действия), недостаток опыта (программисты берут готовые примеры и модифицируют, адаптируя под свои нужды). Решение же, является очень простым — создание общих решений и их использование. Об этом следует думать ещё при разработке решений небольших задач — возможно, что нам потребуется решить эту задачу где-нибудь ещё, или решить эту же задачу, но в другой интепретации.

«Брось, можно писать не только одну функцию!» или Спагетти-код (Spaghetti code)

Спагетти-код — слабо структурированная и плохо спроектированная система, запутанная и очень сложная для понимания. Такой код так же очень часто содержит в себе множество примеров анти-паттерна программирования копи-пастом. Подобный код в будущем не сможет разобрать даже его автор. В ООП спагетти-код может быть представлен в виде небольшого количества объектов с огромными, по размеру кода, методами. Причинами являются — разработка по принципу «Да ну, оно же работает! Целых пять тысяч строк!», малоэффективные code review, недостаток опыта в ООП разработке, удалённая работа отдельных программистов. Ипользовать спагетти-код повторно невозможно и нежелательно. Если в вашем проекте начинает возникать спагетти-код, а вам как раз надо расширить функционал, который он реализует — не ленитесь, рефакторьте спагетти полностью или напишите эту часть заново! Проиграв немного времени сейчас — вы получите огромный плюс в будущем. Или наоборот — проиграете, если оставите спагетти-код в проекте.

Золотой молоток (Golden hammer)

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

«Что за 42?» или Магические числа (Magic numbers)

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

«Что значит d:\proj\tests.dat?» или Жёсткое кодирование (Hard code)

Жёсткое кодирование — внедрение различных данных об окружении в реализацию. Например — различные пути к файлам, имена процессов, устройств и так далее. Этот анти-паттерн тесно связан с магическими числами, частенько они переплетаются. Захардкодить — жёстко прописать значение каких-либо данных в коде. Главная опасность, исходящая от этого анти-паттерна — непереносимость. В системе разработчика код будет исправно работать до перемещения или переименования файлов, изменения конфигурации устройств. На любой другой системе код может вовсе не заработать сразу же. Как правило, программист практически сразу забывает где и что он захардкодил, даже если делает это в целях отладки кода. Это делает выявление и локализацию данного анти-паттерна очень сложной. С этим надо бороться — оговорив запрет на жёсткое кодирование перед началом разработки и проводя тщательные code review.

Мягкое кодирование (Soft code)

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

Ненужная сложность (Accidental complexity)

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

Лодочный якорь (Boat anchor)

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

Изобретение велосипеда (Reinventing the wheel)

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

Изобретение одноколёсного велосипеда (Reinventing the square wheel)

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

«От твоего кода дурно пахнет» или Поток лавы (Lava flow)

На каком либо этапе разработки вы можете осознать, что некоторая часть кода очень давно не менялась и вообще недокументирована, или такому коду сопутствует комментарий вида «// Не знаю, как оно работает, но оно работает. Не удалять и не менять!». Если ничего не предпринимать, то такой код и останется в проекте. Но и рефакторить, разбирать его довольно сложно, особенно ели его автор уже не работает над проектом. Проще предусмотреть возникновение такого мёртвого кода, при разработке надо руководствоваться тем, что код в будущем возможно будет немного оптимизирован или дописан, но никак не переписан полностью. Главными причинами возникновения потоков лавы являются — написание больших частей проекта одним программистом, отсутствие code review, ошибки в проектировании архитектуры.

«А если i+1?» или Программирование перебором (Programming by permutation)

Многие начинающие программисты пытаются решать некоторые задачи методом перебора — не брутфорсом решения, а именно подбором параметров, порядка вызова функций и так далее. Все эти игры с +1, -1 к параметрам и подобные штучки устраняют только симптомы, и не дают понимания сути происходящего. А если программист не понимает происходящего, то он не сможет предусмотреть все варианты развития событий и обязательно о чём-то забудет. Он потратит время на подбор работающего для него решения и позднее потратит время для переделки этого решения. Все подобные подобранные решения вылазят боком и хорошо ещё — если в процессе разработки или отладки. К подобному ни в коем случае нельзя привыкать, достигая успеха на небольших задачках. Если программист не может решать задачи другим путём — он некомпетентен и ему не следует доверять разработку — вам же будет хуже.

«Как это вы передали строку вместо числа?!» или Слепая вера (Blind faith)

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

Бездумное комментирование

Результат «работы» данного анти-паттерна — большое количество лишних и неинформативных комментариев. Код не следует комментировать ради комментирования! Ведь комментарии — очень полезный инструмент, который должен помочь задокументировать нужную информацию для облегчения понимания кода, как автору в будущем, так и другим разработчикам. Ни в коем случае нельзя допускать диалога разработчиков в комментариях — лучше перенести данную функцию с комментариев на специализированные инструменты для code review, или на личное обсуждение.

Божественный объект (God Object)

«Мне нужен такой-то функционал. — Используй MegaCoreObject! — И ещё, мне нужен и… — Я же сказал, используй MegaCoreObject!»

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

Выводы

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

Самый страшный враг знания — не его отсутствие,
а иллюзия его наличия (с) Стивен Хокинг

До этого момента мы уже успели рассмотреть некоторые популярные ошибки проектирования и дизайна программ и систем. Как правило, описанные ранее антипаттерны могли случаться из-за отсутствия должного опыта и квалификации конкретного разработчика, сегодняшний же наш разговор о недуге, который косит в первую очередь опытных и закалённых программистов. Сегодня мы поговорим про «Золотой молоток» (Golden Hammer; по-другим версиям также можно встретить следующие названия: Молоток Маслоу, Закон молотка и т.д.).

Итак, Золотой молоток — это антипаттерн повсеместного использовании единственного решения. По сути, использование подобного подхода может быть не только в разработке и даже в областях далёких от программирования. К слову, сам термин явился миру за долго до появления определения антипаттерн.

На поверхности дело может обстоять следующим образом: разработчик, который однажды сталкивается с проблемой и находит крепкое рабочее решение — пытается пронести данный способ через всю жизнь, вездесущно затягивая в текущие и все будущие проекты. Полагаясь на логику, что хорошая работа в прошлом гарантирует тот же результат и в будущем. И, если в слесарном деле, допустим, одним гаечным ключом можно обслуживать все дома района, то в IT данная практика может выйти боком. Уверенность в серебряной пуле (это тонкая отсылка к книге Фредерика Брукса 🙂 ), любовь и религиозная «преданность» к конкретной технологии — это когнитивная реакция нашего мозга на новое и неизвестное. Людям более свойственно натянуть за уши исходные требования на свои знания и устоявшуюся реализацию, чем учить заново или придумывать что-то с нуля. И в этом-то и самая большая опасность молотка для профессионального разработчика.

Кроме страха перед неизвестным и новым, причиной антипаттерна Золотой молоток может также служить полное незнание альтернативных вариантов. Каждое серьёзное инфраструктурное или проектировочное решение должно быть подкреплено каким-либо исследованием и обоснованием. Нужно для себя раз и навсегда принять как данность, что не бывает единственного верного способа решения той или иной проблемы. Это касается не только выбора какой-либо технологии вашего стека, но и может быть более низкоуравневым решением — вплоть до языка программирования или даже типа и вида транспорта (связи между узлами какой-либо системы).

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

Симптомами Golden Hammer может выступить тот факт, что перед разработкой никто не взвешивал никаких рисков и не проводил анализа или обоснования выбора того или иного пути решения проблемы. Если вы упираетесь в какие-то ограничения и рамки, вызванные вашим любимым инструментом и эти искусственные блоки подталкивают вас к усложнению внутренних частей системы — подумайте, возможно, существуют и другие варианты выхода из сложившейся ситуации. Старайтесь узнать свой технологический стек не только точечно, а ещё и в ширину (горизонтально), чтобы иметь базовые представление о хороших и плохих сторонах какого-либо из направлений\технологии. Не зацикливайтесь на удобных и знакомых вариантах — пробуйте разное, следите за тенденциями, читайте свежую литературу, смотрите обзоры и рейтинги. Не забывайте о собственных Pet-проектах, которые также дают этот важный бесценный опыт.

Впереди нас ждёт статья про hard- и soft- код, а также обзоры других неприятных в разной степени антишаблонов. Немного терпения, други!

Золотой молоток: инструмент, который может разбить вашу карьеру

Золотой молоток – таким поэтичным именем обозначают одну из форм узкого мышления, когда человек раз за разом выбирает для решения различных проблем один и тот же, привычный для него инструмент. Явление также известно как «закон инструмента» или «молоток Маслоу».

Первым в 1964 году определение явлению составил философ Абрахам Каплан: «Дайте маленькому мальчику молоток, и он обнаружит, что по всем предметам вокруг просто необходимо постучать». Большую популярность приобрело меткое высказывание Абрахама Маслоу из книги 1966 года «Психология науки»: «Когда у тебя в руках молоток, все задачи кажутся гвоздями». Возможно, ученые позаимствовали данную идею из народных источников: схожее по смыслу понятие ‒ «бирмингемская отвертка» ‒ существовало еще за столетие до «молотков». Позже широкое распространение получил также термин «наблюдение Баруха» ‒ по имени Бернарда Баруха, одиозного американского финансиста с Уолл-стрит.

Абрахам Маслоу

Причины возникновения явления «золотой молоток» лежат в области когнитивной психологии. Придерживаться определенной точки зрения ‒ что может быть естественней для простого человека! Раз составив мнение о каком-либо предмете, мы склонны в дальнейшем полагаться на уже сложившиеся убеждения и допущения вместо того, чтобы попробовать подойти к новому вопросу с иной оптикой. Даже если вопрос явно многозначен – ради сохранения энергии и душевного равновесия мы скорее предпочтем интерпретировать его более односторонне (а значит – заведомо ошибочно), в соответствии со своими устоявшимися взглядами. Еще один фактор ‒ успех предыдущего опыта. Обратная сторона удачного выполнения задачи ‒ это стремление решать и последующие вопросы теми же методами. Однако нет гарантий, что технология, которая работала в определенной сфере, окажется подходящей в другой, пусть даже смежной области.

Панацея от всех бед

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

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

Бирмингемская отвертка становится камнем преткновения и во многих других профессиональных сферах, но особое внимание проблеме уделяют современные программисты. Она была обозначена еще в 1998 году группой авторов книги «Антипаттерны: Рефакторинг программного обеспечения, архитектуры и проекта в кризис», которая была высоко оценена в том числе Джоном Влисидисом, инженером IBM.

Пример золотого молотка в IT:

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

Что сделано молотком, не вырубишь топором

Какие опасности таит в себе золотой молоток? Если в повседневной жизни использование одинаковых паттернов приводит к индивидуальным бытовым или психологическим проблемам, то на производственном и корпоративном уровнях единообразие решения всех задач может обернуться финансовым крахом. Не зря молоток – золотой!

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

При этом профессиональные паттерны поведения в свою очередь нередко воздействуют на личную сферу жизни человека. Врачи известны своим особым, «врачебным» юмором. Учителя и военные пытаются демонстрировать авторитет не только в окружении подчиненных, но и в домашнем кругу. Французы подметили, что déformation professionnelle (профессиональная деформация) ‒ еще одна, не самая положительная сторона явления, когда привычные инструменты применяют не по назначению и не к месту.

Гвоздодер

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

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

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

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

Золотой молоток

Связанные понятия

Экстрема́льное программи́рование (англ. Extreme Programming, XP) — одна из гибких методологий разработки программного обеспечения. Авторы методологии — Кент Бек, Уорд Каннингем, Мартин Фаулер и другие.

Пять почему — техника, используемая для изучения причинно-следственных связей, лежащих в основе той или иной проблемы. Основной задачей техники является поиск первопричины возникновения дефекта или проблемы с помощью повторения одного вопроса — «Почему?». Каждый последующий вопрос задаётся к ответам на предыдущий вопрос. Количество «5» подобрано эмпирическим путём и считается достаточным для нахождения решения типичных проблем.

Функциональная закреплённость (функциональная фиксированность) — психологический феномен, открытый и описанный Карлом Дункером.

Код с запашко́м (код с душко́м, дурно пахнущий код англ. code smell) — термин, обозначающий код с признаками (запахами) проблем в системе. Был введён Кентом Беком и использован Мартином Фаулером в его книге Рефакторинг. Улучшение существующего кода.

Разрешение лексической многозначности (word sense disambiguation, WSD) — это неразрешенная проблема обработки естественного языка, которая заключается в задаче выбора значения (или смысла) многозначного слова или словосочетания в зависимости от контекста, в котором оно находится. Данная задача возникает в дискурсивном анализе, при оптимизации релевантности результатов поисковыми системами, при разрешении анафорических отсылок, в исследовании лингвистической когерентность текста, при анализе умозаключений…

Принцип единственной ответственности (англ. The Single Responsibility Principle, SRP) — принцип ООП, обозначающий, что каждый объект должен иметь одну ответственность и эта ответственность должна быть полностью инкапсулирована в класс. Все его поведения должны быть направлены исключительно на обеспечение этой ответственности.

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

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

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

Усиление интеллекта (УИ) (англ. Intelligence amplification, Cognitive augmentation, Machine augmented intelligence) — совокупность средств и методов, обеспечивающих максимально возможную производительность интеллекта человека; эффективное использование информационных технологий для усиления человеческого интеллекта. Теория УИ активно разрабатывалась в 1950-е и 1960-е годы пионерами кибернетики и информатики.

Предметно-ориентированное проектирование (реже проблемно-ориентированное, англ. Domain-driven design, DDD) — это набор принципов и схем, направленных на создание оптимальных систем объектов. Сводится к созданию программных абстракций, которые называются моделями предметных областей. В эти модели входит бизнес-логика, устанавливающая связь между реальными условиями области применения продукта и кодом.

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

Агентное моделирование (англ. agent-based model (ABM))— метод имитационного моделирования, исследующий поведение децентрализованных агентов и то, как такое поведение определяет поведение всей системы в целом. В отличие от системной динамики аналитик определяет поведение агентов на индивидуальном уровне, а глобальное поведение возникает как результат деятельности множества агентов (моделирование «снизу вверх»).

Программи́рование ме́тодом копи́рования-вста́вки, C&P-программирование или копипаста в программировании — процесс создания программного кода с часто повторяющимися частями, произведёнными операциями копировать-вставить (англ. copy-paste). Обычно этот термин используется в уничижительном понимании для обозначения недостаточных навыков компьютерного программирования или отсутствия выразительной среды разработки, в которой, как правило, можно использовать подключаемые библиотеки.

Структу́рное программи́рование — парадигма программирования, в основе которой лежит представление программы в виде иерархической структуры блоков.

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

Закон Парето (принцип Парето, принцип 80/20) — эмпирическое правило, названное в честь экономиста и социолога Вильфредо Парето, в наиболее общем виде формулируется как «20 % усилий дают 80 % результата, а остальные 80 % усилий — лишь 20 % результата». Может использоваться как базовая установка в анализе факторов эффективности какой-либо деятельности и оптимизации её результатов: правильно выбрав минимум самых важных действий, можно быстро получить значительную часть от планируемого полного результата…

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

Иску́сственный интелле́кт (ИИ; англ. artificial intelligence, AI) — свойство интеллектуальных систем выполнять творческие функции, которые традиционно считаются прерогативой человека; наука и технология создания интеллектуальных машин, особенно интеллектуальных компьютерных программ.

«Серебряной пули нет» (англ. «No Silver Bullet») — широко обсуждавшаяся статья Фредерика Брукса об инженерии программного обеспечения, написанная им в 1986 году. Брукс утверждает, что «ни в одной технологии или в управленческой технике не существует универсального метода, увеличивающего на порядок производительность, надёжность и простоту». Он также утверждает, что «мы не можем ожидать увеличения прибыли в два раза каждые два года» при разработке программного обеспечения, как это происходит с разработкой…

Агентно-ориентированный подход (в дальнейшем АОП) к программированию — разновидность представления программ или парадигма программирования, в которой основополагающими концепциями являются понятия агента и его ментальное поведение, зависящее от среды, в которой он находится. Концепция была предложена Шохемом (англ. Yoav Shoham) в 1990 г..

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

Поиск с возвратом, бэктрекинг (англ. backtracking) — общий метод нахождения решений задачи, в которой требуется полный перебор всех возможных вариантов в некотором множестве М. Как правило позволяет решать задачи, в которых ставятся вопросы типа: «Перечислите все возможные варианты …», «Сколько существует способов …», «Есть ли способ …», «Существует ли объект…» и т. п.

Канба́н-доска́ является одним из инструментов, который может использоваться при внедрении метода управления разработкой «Канбан».

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

Ошибки первого рода — «ложная тревога» (англ. type I errors, α errors, false positive) и ошибки второго рода — «пропуск цели» (англ. type II errors, β errors, false negative) в математической статистике — это ключевые понятия задач проверки статистических гипотез.

Адаптивный кейс-менеджмент ACM (англ. Adaptive Case Management, Dynamic Case Management, Advanced Case Management) — концепция динамического управления бизнес-процессами предприятия.

Покер планирования (англ. Planning Poker, а также англ. Scrum poker) — техника оценки, основанная на достижении договорённости, главным образом используемая для оценки сложности предстоящей работы или относительного объёма решаемых задач при разработке программного обеспечения. Это разновидность метода Wideband Delphi.

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

В программировании сборка мусора (англ. garbage collection) — одна из форм автоматического управления памятью. Специальный процесс, называемый сборщиком мусора (англ. garbage collector), периодически освобождает память, удаляя объекты, которые уже не будут востребованы приложениями.

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

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

«Вычислительные машины и разум» (англ. Computing Machinery and Intelligence) — основополагающая работа в области искусственного интеллекта, написанная английским учёным Аланом Тьюрингом и опубликованная в 1950 году в журнале «Mind», дающая широкой аудитории представление о том, что в настоящее время называется тестом Тьюринга.

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

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

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

Шесть шляп мышления (англ. Six Thinking Hats) — система организации мышления, разработанная Эдвардом де Боно, которая описывает инструменты структурирования групповой дискуссии и индивидуальной умственной деятельности с использованием шести цветных шляп. Идея латерального мышления и основанный на ней метод Шести Шляп обеспечили средства планирования подробного, последовательного и в результате более эффективного группового мыслительного процесса.

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

Ме́тод проб и оши́бок (в просторечии также: метод (научного) тыка) — является врождённым эмпирическим методом мышления человека. Также этот метод называют методом перебора вариантов.

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

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

Когнити́вные измере́ния — это принципы разработки синтаксиса, пользовательских интерфейсов и других особенностей языков программирования, описанные исследователями Томасом Грином и Марианом Петре. Измерения могут использоваться для оценки юзабилити существующих языков или для рекомендаций по дизайну новых.

Автома́тное программи́рование — это парадигма программирования, при использовании которой программа или её фрагмент осмысливается как модель какого-либо формального автомата. Известна также и другая «парадигма автоматного программирования, состоящая в представлении сущностей со сложным поведением в виде автоматизированных объектов управления, каждый из которых представляет собой объект управления и автомат». При этом о программе, как в автоматическом управлении, предлагается думать как о системе…

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

Вопросно-ответная система (QA-система; от англ. QA — англ. Question-answering system) — информационная система, способная принимать вопросы и отвечать на них на естественном языке, другими словами, это система с естественно-языковым интерфейсом.

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

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