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

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

Причина, яка мене цікавить, полягає в тому, що багато людей стикаються з роботою програміста щодня, але якщо ви запитаєте пересічну людину, що таке програміст чи робить, вони насправді не знають. Це призводить до певних ситуацій непорозумінь (напр., "[...], але я вважав, що ти добре працюєш із комп'ютерами!")

Я дуже хотів би знайти найкращого там. Мені б хотілося легко пояснити комусь, що стосується мого вибору кар’єри. Звичайно, принаймні загальна ідея.

Я особисто не маю твердого, але я довго думав над цим, і я, як правило, тяжів до метафори "мови", де ми, як трапляємось, знаємо мову, яку розуміють комп'ютери, і тому ми можемо сказати комп'ютерам, що робити робити або "навчати" їх для вирішення наших проблем.

Наприклад:

Уявіть, що в альтернативній реальності існують гуманоїдні роботи з штучним інтелектом, і деякі люди здатні спілкуватися з ними за допомогою спільної мови, що є варіацією англійської. Ці люди, які можуть спілкуватися з роботами, здатні навчити їх вирішувати певні проблеми чи виконувати певні завдання, як, наприклад, займаючись нашими справами.

Ну хоча хоча таких роботів ще не існує, програмісти нашого часу схожі на тих людей, але замість спілкування з роботами вони спілкуються з комп’ютерами. Програмісти "навчають" комп'ютери виконувати певні завдання або вирішувати певні проблеми за допомогою програмного забезпечення, яке вони створюють, використовуючи цю "загальну мову".

Програмісти і ця "загальна мова" - це те, що дає нам такі речі, як електронна пошта, веб-сайти, відеоігри, текстові процесори, смартфони ( простіше кажучи ) та багато інших речей, якими ми користуємося щодня.

Я не хочу ставити програмування на трон чи що-небудь, це просто найкраща метафора, яку я міг придумати.

Я впевнений, що хтось знайде якусь проблему з цією проблемою, ймовірно, це трохи надумано, але потім знову тому я задаю це питання.

Це як би написати докладні покрокові інструкції щодо того, як кудись їхати. Але зазвичай додати плани дій на випадок надзвичайних ситуацій на кшталт "що робити, якщо трапляється затор", або "що робити, якщо вантажівка зламається на смузі повороту".

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

І зазвичай, як тільки ви зрозуміли, що все описано дуже вимогливо, замовник каже: "Це ідеально, за винятком того, що він повинен працювати для того, хто керує повітряним судном"

Я пишу дуже, дуже детальні інструкції для дуже-дуже німої машини.

Я використовую метафору "Ми пишемо в'язані рецепти ", яка є бабусею.

Обгрунтування:

• В'язання - це досить простий механічний процес, коли вам потрібно, як правило, дотримуватися детальних інструкцій, щоб вийти з нього що-небудь.
• Більшість інструкцій з в'язання - для кількох розмірів. Це дає вам ifзаяви і математику, і петлі.
• Ви можете знайти помилку в рецепті, коли в армію розлючених бабусь приходять їхні гнучкі светри!

Не дуже хороша аналогія, але коли люди кажуть мені виправити свою машину, я кажу: "Я той хлопець, який проектує машини. Я не механік!"

У дитинстві я читав справді хороший опис програмування: це як розповісти роботові, як робити звичайне, повсякденне завдання, наприклад, ходити до школи. Тож ви можете сказати це "Ідіть до школи!", Але це не знає як. Тож ви кажете йому «вийти на вулицю, ліворуч, продовжуй ходити до школи, ліворуч, зайти і сісти». Але дорога в дорозі! Тож вам потрібно сказати, щоб він "зупинився на дорозі, перевірив, що немає руху, переходиш дорогу і продовжуєш ходити" десь посередині. А як щодо дверей? Тож ви додаєте "перевірити, чи двері в школі відкриті. Якщо це не так, відкрийте їх". там. Зрештою, у вас є програма, яка може розповісти вашому роботові, як самостійно потрапити до школи.

Це дуже акуратно з логотипом, де ви точно вказуєте черепаху створити складні форми.

Програмування - це як коробка цукерок . Іноді ви знаходите те, що шукаєте відразу, але більшість часу це займає багато спроб та помилок. Іноді ви отримуєте кокос.

Світлофори . Автомобілі або рухаються, або зупиняються. На одному світлофорі легко уявити налаштування, але що станеться, якщо додати інший? Як щодо третини? А як щодо цілого міста? Транзитна система складається з тисяч стоп-сигналів, кожен простий сам по собі, але якщо взяти її в цілому, вона стає складною системою. Якщо один із цих світлофорів несправний або вимкнеться всього за кілька секунд, він кидає всю систему в хаос. Якщо все синхронізується, ви просто насолоджуєтеся їздою.

Мотиваційний оратор знаходить ключі , щоб відкрити загадку людей мотивацій, мрії і ідеї. Кожна ситуація, кожна людина різні. Те, що працювало в минулому, зараз може не відповідати. Іноді ключ можна повторно використовувати, але його потрібно адаптувати до особистості. В інших випадках ключ повинен бути виготовлений заново. Найцікавіше - це коли людину розблокували, і ти бачиш, як вони виходять і підкорюють світ. Найбільш руйнівно, коли ти відчуваєш себе близько, але просто не в змозі розблокувати потенціал.

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

Слот - автомат . Ви кладете всі свої монети і тягнете важіль. Іноді ти виграєш велику, іноді сидиш там годинами, і нічого не відбувається. Інколи хтось просто випадково проходить повз, один раз тягне важіль і виграє джекпот.

Музика . Одна примітка досить проста, але міра складніша. Повна пісня має багато заходів з багатьма нотами. Якщо одна нота вимкнена, це може зіпсувати всю виставу. Якщо кожна нота ідеально поставлена, виступ відходить на другий план і існує лише музика.

Найкраща метафора для чого-небудь - сама. Все, що відрізняється, втратить певну точність. Вибір найкращої метафори залежить від того, що конкретно ви хочете зробити про програмування. Оскільки тут буде дано багато відповідей щодо кодування метафор, я відповім класичною метафорою для процесу розвитку в цілому:

Будівництво будівель

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

• Зміни дешевше і дешевше, чим раніше ви їх зробите. Тобто ви можете перемістити одну лінію на папері зараз або на 10 тонн цементу пізніше.
• Будівля без належного плану буде, як правило, руйнуватися
• Будівельники намагаються реалізувати те, що хоче клієнт. Якщо клієнт не точно описав, як хоче виглядати будівля (або є якийсь інший збій у спілкуванні), змінити їх буде дорого.
• Існують певні закони фізики, які неможливо зігнути. Подібно до того, як 2-ю історію, що має ширину триста футів, не можна побудувати на 1-й історії широкої стоти футів, особливість X не може бути побудована без надійної підсистеми Y.

Звичайно, як і будь-яка метафора, вона має свої обмеження. Деякі недоліки з цим:

• Будинки використовуються одноразово; ти десь будуєш його і там залишається. Ви не можете скопіювати це мільйон разів для мільйона різних користувачів з мільйоном різних потреб при нульовій додатковій вартості.
• Будинки значно непорушніші, ніж програмні.
• Немає чіткої аналогії з витратами на будівельні матеріали. Рядок коду нічого не коштує - лише час, необхідний для його виготовлення, коштує грошей.
• Інкрементальна архітектура, яка (залежно від того, кого ви запитуєте) можлива за допомогою програмного забезпечення, неможлива з побудовою, де ви її проектуєте один раз, а потім будуєте.

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

Мені подобається , що аналогія розвитку програмного забезпечення Кріса Макмахона нагадує створення музики, особливо джазової музики.

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

Цей конкретний ролик є чудовим прикладом спритної практики. Послухайте, як голос і фортепіано впливають один на одного. Це дуже схоже на парне програмування, і це дуже схоже на TDD: голос щось робить; фортепіано відповідає; фортепіано щось робить; голос відповідає. І помітити контакт очей. Ці люди інтенсивно усвідомлюють, що відбувається миттєво в мить. У них немає нот (BDUF). Вони беруть участь у діяльності, яка потребує інтенсивної концентрації та навичок, як і хороша розробка програмного забезпечення. Вони також чітко усвідомлюють, що існує аудиторія, так само, як хороша розробка програмного забезпечення повинна усвідомлювати потреби людей, які платять рахунки.

Ось посилання на допис у блозі, в якому він обговорює це: http://chrismcmahonsblog.blogspot.com/2007/05/example-of-analogy-monks-vs-music.html

Іноді я називаю програмування контролем бездумних зомбі . Підводячи підсумки моєї публікації в блозі :

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

Програмування схоже на створення речей з Lego :

• Ви склеюєте багато маленьких шматочків разом, щоб зробити більші речі
• Маленькі шматочки бувають обмеженої кількості форм і розмірів
• Дрібні речі можуть поєднуватися лише певними способами
• Граючи з цими речами може бути дуже весело

Програмування комп’ютера - це як виховання дитини ...

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

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

Програмування - це як будівництво фабрики чи конвеєра.

Розгляньте програмне забезпечення як машину або конвеєр, який існує всередині комп'ютера. Деяка сировина та компоненти подаються в машину, і дотримується набір процедур, щоб переробити їх у якийсь кінцевий продукт. Процедури встановлюються для виконання певної операції над деякою сировиною або компонентом для певного набору параметрів (наприклад, часу, температури, відстані тощо) у певному порядку. Якщо деталі операції, яку слід здійснити, були неправильними, або датчики машини неправильно відкалібровані, або якщо деяка сировина або компонент не відповідали очікуваним стандартам якості, це може змінити результат операції і продукт не вийде. як і очікувалося.

Така машина дуже жорстка у своїй роботі та прийнятні входи. Машини не ставлять під сумнів інтелект дизайнерів, ані його поточне робоче середовище. Він буде продовжувати дотримуватися процедур до тих пір, поки це спрямовано. Навіть якби зміна сировини або компонентів могло б кардинально вплинути на те, що сталося в наступних операціях, машина все одно буде виконувати свої процедури. Процес потрібно переглянути, щоб побачити, які зміни в процедурах були необхідні для компенсації та отримання бажаного результату. Зміна дизайну або конфігурації виробу також може зажадати значних змін у виконаних операціях або в їх порядку. Хоча відповідальні за виробництво швидко дізналися важливість ізоляції операцій якнайбільше для зменшення небажаних наслідків між ними, багато припущень зроблено щодо компонентів стану, які перебувають під час їх переробки; припущення, які можуть бути не виявлені, поки кінцевий продукт не опиниться в руках користувача в деяких різних робочих умовах.

Допомагаючи швидкому ідіоту пройти клас математики, який вимагає письмового есе.

Комп'ютерне програмування - це як грати в шахи, в якій розмір дошки, кількість відтворених штук та правила, які керують цими фігурами, збільшуються в розмірі та складності в процесі гри.

Написання програмного забезпечення схоже на ... Написання! ^^

Нові студенти до класів CS / програмування практично не схожі на користувачів, які не програмують. Приклад робота хороший.

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

Це практичне програмування допомогло студентам здобути навички вирішення проблем, навіть якщо вони не були пов'язані з комп’ютером !!!

Або, навіть якщо студенти не стали програмістами.

Деякі колективи та університети також застосовували ці інструменти на курсах першого курсу.

Цікаво, чому багато вузів кидають викладання логотипу та Карела ...

Мені подобається аналогія Фреда Брукса з Mythical Man-Month, що програмування - це як виконання магії.

() Програмна конструкція, на відміну від слів поета, реальна в тому сенсі, що вона рухається і працює, створюючи видимий вихід окремо від самої конструкції. Він друкує результати, малює картинки, видає звуки, рухає руками. Магія міфу та легенди збулася в наш час. Одне вводить правильну заклик на клавіатурі, а екран дисплея оживає, показуючи речі, які ніколи не були і не могли бути. ...

(Один) повинен виконувати правильно. Комп'ютер нагадує магію міфу та легенди і в цьому відношенні. Якщо один персонаж, одна пауза заклинання не суворо належної форми, магія не працює. Людина не звикла бути ідеальною, і мало областей людської діяльності цього вимагають. Пристосування вимоги до вдосконалення, я думаю, найважча частина навчання програмуванню.

"[...] але я вважав, що ти добре з комп’ютерами!"

Зазвичай це спроба обману видовища у виправлення комп’ютера (ви відчуваєте, що вимагаєте довести їх неправильно?). Моя стандартна відповідь:
я програміст. Це як автомобільний інженер - він, мабуть, не знатиме, як зафіксувати гальмо у вас '72 Трабант, і, звичайно, не зробив би цього, якби знав. Механік зробив би це!

Мені подобається концепція рецепту приготування.

Програмування - це як управління великими потужностями. Ви можете змусити комп’ютер робити все, що завгодно. Вас обмежує лише ваша фантазія та кількість часу, який ви готові вкласти.

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

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

Я, як правило, прирівнюю програмування до головоломки.

Для створення нового проекту - у вас є тонни штук, кілька з яких не належать до цього зображення, і у вас немає попереднього перегляду того, як виглядає головоломка, коли вона буде виконана. Але ви знаєте розмір та загальні кольори, тому оцінки можливі, але не обов’язково точні.

Для видозміни вже існуючого проекту - кішка підійшла і збила шматок готової головоломки. Мине певний час, але рамка вже є, тому вона не повинна бути занадто поганою (залежно від того, скільки потрібно змінити).

Це також допомагає описати прогрес. Один з моїх останніх проектів, я в один момент цікавився, як описати це, щоб людина, яка не технічна, зрозуміла, чому я не знаю, як довго, і я придумала: Подумайте головоломку, де всі шматочки облямівок зроблені, як і трохи більше половини, якщо внутрішні шматки. Ті, що залишилися, всі відокремлені один від одного, і те, що я маю зараз зробити, - це заповнити прогалини.

Сумно, але програмування - це робота, яку можна зрозуміти, лише навчившись це робити.

Програмування має кілька різних рівнів сприйняття і відрізняється з різних сторін.

На низькому рівні це "написати дуже, дуже детальну інструкцію для дуже-дуже німої машини"

На наступному рівні вона має справу зі складністю. Побудова нової метафори для спрощення роботи. Як і вища математика.

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

З іншого боку, його "користувальницький" інтерфейс (не буквально, я маю на увазі API і інтерфейс користувача), передбачити можливі помилки (зроблені користувачем, даними або навіть самим собою) і виправити реакцію на помилки.

І, нарешті.

Метафора програмування - література. Спочатку потрібно вивчити алфавіт. Але писати роман у цього навіть не починається.