Что такое хорошая метафора программирования? [закрыто]

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

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

Я действительно хотел бы найти лучший там. Я хотел бы быть в состоянии легко объяснить кому-то, о чем мой выбор карьеры. Конечно, хотя бы общая идея.

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

Например:

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

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

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

Я не хочу ставить программирование на трон или что-то еще, это просто лучшая метафора, которую я могу придумать.

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

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

И иногда вам приходится погружаться еще глубже и объяснять правила дорожного движения, например, на какую сторону ехать или что делать на красном сигнале. А иногда вам даже нужно точно объяснить, как работает руль или педаль газа.

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

Я пишу очень, очень подробные инструкции для очень, очень тупой машины.

Я использую метафору «Мы пишем рецепты вязания », которая дружит с бабушкой.

Обоснование:

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

Не очень хорошая аналогия, но когда люди говорят мне починить их машину, я говорю: «Я парень, который проектирует автомобили. Я не механик!»

В детстве я прочитал действительно хорошее описание программирования: это все равно, что рассказывать роботу, как выполнять обычную повседневную задачу, например ходить в школу. Таким образом, вы можете сказать это «Иди в школу!», Но он не знает как. Таким образом, вы говорите: «выходите на улицу, поверните налево, продолжайте идти, пока не придете в школу, не поверните налево, войдите и сядьте». Но на пути есть дорога! Таким образом, вы должны сказать ему: «Остановитесь у дороги, проверьте, что нет движения, перейдите дорогу и продолжайте идти» где-то посередине там. А как насчет дверей? Таким образом, вы добавляете «проверьте, открыта ли школьная дверь. Если это не так, откройте ее». там. В конце концов, у вас есть программа, которая может рассказать вашему роботу, как самостоятельно добраться до школы.

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

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

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

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

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

Слот - автомат . Вы кладете все свои монеты и нажимаете на рычаг. Иногда вы выигрываете крупно, иногда сидите там часами и ничего не происходит. Иногда кто-то просто случайно проходит мимо, один раз тянет рычаг и выигрывает джекпот.

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

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

Строительство зданий

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

• Изменения тем дешевле и дешевле, чем раньше вы их вносите. То есть вы можете переместить одну линию на бумаге сейчас или на 10 тонн в цементе позже.
• Здание без надлежащего плана будет иметь тенденцию разрушаться
• Строители пытаются реализовать то, что хочет клиент. Если клиент точно не описывает, как он хочет, чтобы здание выглядело (или есть какой-то другой сбой в коммуникации), это будет дорогостоящим, чтобы измениться.
• Есть определенные законы физики, которые нельзя согнуть. Подобно тому, как 2-й этаж шириной в триста футов не может быть построен на 1-м этаже шириной в 100 футов, функция X не может быть построена без надежной подсистемы Y.

Конечно, как любая метафора, она имеет свои ограничения. Некоторые недостатки с этим:

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

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

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

Это Элла Фицджеральд и граф Бэйси, исполняющие песню One O'Clock Jump. Песня представляет собой блюз из двенадцати тактов, который является джазовым эквивалентом приложения базы данных с пользовательским интерфейсом. Под этим я подразумеваю: так же, как каждый программист создал приложение для базы данных с пользовательским интерфейсом, каждый американский музыкант играл блюз на двенадцать тактов. Это основа, на которой висят многие, многие песни, от графа Бэйси до Джими Хендрикса и Рамонеса.

Это конкретное видео является отличным примером гибкой практики. Послушайте, как голос и пианино влияют друг на друга. Это очень похоже на парное программирование и очень похоже на TDD: голос что-то делает; пианино отвечает; пианино что-то делает; голос отвечает. И обратите внимание на зрительный контакт. Эти люди прекрасно осведомлены о том, что происходит мгновенно. У них нет ноты (BDUF). Они вовлечены в деятельность, которая требует интенсивной концентрации и умения, как хорошая разработка программного обеспечения. Они также четко осознают, что есть аудитория, так же, как хорошая разработка программного обеспечения должна осознавать потребности людей, оплачивающих счета.

Вот ссылка на сообщение в блоге, в котором он обсуждает это: http://chrismcmahonsblog.blogspot.com/2007/05/example-of-analogy-monks-vs-music.html

Иногда я говорю о программировании как об управлении бессмысленными зомби . Подводя итог моего блога об этом:

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

Программирование - это как строить вещи с помощью Lego :

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

Программирование компьютера - это как воспитание ребенка ...

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

Основное отличие состоит в том, что мы расстраиваемся, если кто-то крадет наш исходный код, но мы часто рады, что кто-то лишает нас детей.

Программирование похоже на строительство фабрики или сборочной линии.

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

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

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

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

Написание программного обеспечения - это как ... написание! ^^

Новые ученики в классах CS / Programming, практически, как пользователи, не занимающиеся программированием. Пример робота хорош.

Назад, в 80-х, очень помогло использование Logo, Karel (или аналогичной среды программирования), где пользователь учится программировать, наблюдая за компьютером как робот, а не телевизор с пишущей машинкой. Те инструменты, которые обычно используются в средней и средней школе.

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

Или даже если студенты не стали программистами.

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

Интересно, почему многие вузы отказываются от преподавания Лого и Карела ...

Мне нравится аналогия Фреда Брукса из «Мифического человека в месяц», что программирование похоже на магию.

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

(Один) должен работать правильно. В этом отношении компьютер напоминает магию мифов и легенд. Если один персонаж, одна пауза заклинания не совсем в правильной форме, магия не работает. Человеческие существа не привыкли быть совершенными, и лишь немногие сферы человеческой деятельности требуют этого. Я думаю, что приспособление к требованию совершенства - самая сложная часть обучения программированию.

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

Обычно это попытка обмануть компьютерщика в ремонте компьютера (вы чувствуете, что хотите доказать, что они не правы?). Мой стандартный ответ:
я программист. Это как автомобильный инженер - он, вероятно, не будет знать, как починить тормоза у вас, Трабант 72 года, и, конечно, не сделает этого, если узнает. Механик сделает это!

Мне нравится концепция рецепта для приготовления пищи.

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

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

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

Я вообще приравниваю программирование к мозаике.

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

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

Это также помогает для описания прогресса. Один из моих недавних проектов, в какой-то момент мне было интересно, как его описать, чтобы неопытный человек понял, почему я не знаю, как долго, и я придумал: «Подумайте о мозаике, где все граничные части сделаны, как и чуть более половины, если внутренние части. Те, что остались, все отделены друг от друга, и теперь я должен заполнить пробелы.

Печально, но программирование - это работа, которую можно понять, только научившись ее выполнять.

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

На низком уровне это «написать очень, очень подробные инструкции для очень, очень тупой машины»

На следующем уровне это имеет дело со сложностью. Создание новой метафоры для упрощения работы. Как высшая математика.

С другой стороны - использование вспомогательных технологий, таких как контроль версий, самодокументированный код, сборка проектов и тестирование.

С другой стороны, его построение пользовательского интерфейса (не буквально, я имею в виду API и UI), прогнозирование возможных ошибок (совершаемых пользователем, данными или даже самим собой) и правильное реагирование на ошибки.

И наконец.

Метафора для программирования - литература. Сначала нужно выучить алфавит. Но написание романа на этом даже не начинается.