Есть ли какие-либо хорошие метафоры для объяснения сложности проекта непрограммисту? [закрытый]
Г-н Millikin, если Вы займете некоторое время для рассмотрения части документации относительно окаменелости, я думаю, что возражения обращены там. Хранение репозитория в sQLite базе данных возможно более безопасно, чем какой-либо другой подход. См. текст ссылки для некоторых преимуществ использования транзакционной базы данных для хранения репозитория. Что касается чрезмерного увеличения размера: вся вещь находится в единственном автономном исполняемом файле, который, кажется, опровергает то беспокойство.
Полное раскрытие: Я - автор окаменелости.
Примечание, что я записал окаменелость, потому что никакой другой DVCS не удовлетворил мои потребности. С другой стороны, мои потребности не являются Вашими потребностями, и поэтому только можно судить, является ли окаменелость правильной для Вас. Но я действительно поощряю Вас, по крайней мере, взглянуть на документацию и попытаться понять проблему, которую окаменелость пытается решить перед отклонением ее.
35 ответов
Мне нравится говорить, что это похоже на постройку корабля и его обслуживание: поддержание двигателя в исправном состоянии, чистка, соскребание ракушек и тому подобное. Конечно, программное обеспечение не ломается из-за того, что оно старое, требования меняются, среда меняется.
Взгляните на Код Стива МакКоннельса, вы найдете там несколько хороших метафор.
Я говорю людям, что это как поддерживать двигатель, который нужно поддерживать в рабочем состоянии, и каждую неделю он будет делать разные вещи. Кроме того, это невидимо, и вы должны выяснить, что происходит косвенно.
Это описание не совсем удовлетворяет нетехнических людей, но помогает мне чувствовать себя лучше.
Большая часть инженерной сложности связана с взаимодействием между люди (и подразделения, которые они представляют, и их цели, и развивающиеся дизайнерские решения, которые возникают в результате этих взаимодействий). Мне никогда не удавалось объяснить это не инженерам, которые обычно говорят мне: «Вы могли бы работать из дома все время, если бы захотели».
Я бы пошел дальше метафоры жилищного строительства. Каждый проект подобен постройке дома с нуля с использованием немного разных компонентов, материалы которых имеют разные свойства и которые взаимодействуют друг с другом по-разному. Часто каждый дом строится на разных планетах по немного разным физическим законам.
И, конечно же, есть постоянный покупатель, который постоянно меняет дизайн дома, пока вы его строите.
Так что да, вы можно сказать, что все дома одинаковые; крыша, стены, двери, окна, водопровод, проводка - но дьявол всегда в деталях.
Как насчет антиметафоры? Проект разработки программного обеспечения НЕ ЯВЛЯЕТСЯ МОНТАЖНЫМ ЛИНИЕМ.
Мой подход полностью отличается:
Я просто объясняю им, как если бы они были другим разработчиком, когда они спрашивают, что означает технический термин, я тоже объясняю , что обычно приводит к еще большему количеству деталей и т. д. Я обнаружил, что тогда пользователи действительно понимают, насколько сложным является дело.
На мой взгляд, аналогии не работают, потому что у них нет способа вернуться к разработке.
1280] Darknight
Это сад. Моя мама - увлеченный садовник, и она говорит о своем саду так же, как я говорю о своей кодовой базе.
- Это так и не закончено - всегда есть сорняки, которые нужно удалить (ошибки / рефакторинг), и планы для новых травянистых бордюров или огородного участка (новые характеристики / требования)
- Вы должны справиться с неожиданным - однажды, когда она пошла пропалывать и переустанавливать клумбу, она обнаружила, что поселилась колония лягушек, не позволяя ей делать что-либо назойливое до зимы (это немного похоже на поиск странностей в сторонней библиотеке или ожидание внешнего подрядчика)
- Вы можете потратить на это всю свою жизнь и никогда не почувствовать как будто вы выполнили половину того, что хотели