Самое сложное объяснение программирования

Question

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

Что самое сложное, что вы должны были передать нетехническому человеку как программисту? Нашли ли вы какие-либо аналогии или способы объяснения, которые прояснили это?

Answer 1

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

Answer 2

Важность юнит-тестов.

Answer 3

Концепция рекурсии - некоторые люди понимают это очень сложно.

Answer 4

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

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

Answer 5

C указатели

* я

& я

Answer 6

Мне иногда действительно трудно объяснить концепцию ковариации / контравариантности и связанные с ними проблемы другим программистам.

Answer 7

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

Answer 8

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

Расширяем этот уровень сложности объяснения того, что такое Inversion of Control и почему это абсолютно необходимо, а не просто дополнительные слои кода, которые ничего не делают.

Answer 9

На самом деле для этого нет правильного или неправильного ответа ... это все переживания.

Самым сложным, что мне пришлось объяснить не техническому человеку, было то, почему он не мог попасть на свой веб-сайт во время поездки за границу, но член его семьи, который жил там (с совершенно другим поставщиком), мог добраться до него. Каким-то образом «Fail in Finland» было недостаточно хорошо.

Answer 10

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

Но это действительно означает: два понятия, которые трудно объяснить:

• монады в haskell (обычно начинающиеся с: «Это похоже на функцию, которая возвращает функцию, которая делает то, что вы действительно хотели сделать, но ...»)
• deferreds в Twisted / Python («Это как ... эххх ... Просто используйте это в течение года или около того, и вы получите это»;))