Как заставить людей ценить абстракцию и гибкость, а не «просто сделать это»?

Question

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

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

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

Как вы относитесь к этим людям?

Answer 1

Убедите их, что сокращение пути — это ложная экономия.

Объясните, что первоначально кодирование усилия составляют менее 30 % от первоначальных усилий по разработке и менее 10 % (по моему опыту) от общих усилий по проекту (включая обслуживание).

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

Answer 2

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

Answer 3

«Проще» когда?Теперь, когда все не в состоянии изменения?Или через три месяца, когда требования заказчика изменятся и у него появится «решение», которое уже не будет решением?

Я не сторонник структуры и правил ради структуры и правил, но полезно знать: А) кто управляет лодкой Б) каковы правила и В) почему мы решили сделать это именно так.

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

Я потратил неделю своей жизни (7 дней подряд), переписывая модуль, потому что находился в режиме «сделай это быстро».Семь дней изнурительного времени, 10-12 часов в день, делая все правильно, в конце игры, когда я мог бы смотреть Суперкубок.Это воняло.Я получил там урок.Возможно, вашим «друзьям» тоже придется испытать такое откровение.

Удачи!

Answer 4

Вообще-то мне не хотелось бы принимать особое мнение по этому поводу, но...

Цитируя Ван Халена (цитируя клише): «Есть время и место для всего». Хотя я, конечно, не выступаю за писать плохо, когда -либо, иногда вам нужно просто сделать это, и находить эту счастливую среду между надежным/устойчивым и взломанным/документированным.(Документированная часть особенно важна по двум направлениям:во-первых, вы четко указываете, что все, что вы делаете, делается просто в интересах достижения цели и требует определенных сокращений;и, во-вторых, примерное представление о том, каким может быть более правильный подход к проблеме.

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

Пожалуйста, не используйте это в качестве оправдания – здесь, конечно, действует правило 80/20.Большую часть времени вам абсолютно необходимо уничтожить любые ярлыки в этом направлении;но иногда...

Answer 5

Показать им!Пусть они сделают небольшой модуль в «Но это было бы проще». Стиль, пока вы делаете это правильно.Затем попросите их внести от 2 до 5 изменений в требования (это должны быть они вносят изменения) и устройте конкурс по внедрению этих изменений.Это может занять день или два, но они это получат.Если вы этого не сделаете, у вас будет одно и то же обсуждение каждого нового проекта или задачи.

Answer 6

Вы могли бы попробовать провести аналогию с ними....

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

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

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

В шахматах есть набор дебютов, стратегии атаки и т. д.У нас есть шаблоны проектирования.

Answer 7

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

Answer 8

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

Answer 9

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

1) О большинстве людей судят по тому, выполнили ли они свою работу. сегодня.Никто никогда не получал выговор за то, что три года назад (или два) они срезали угол, чтобы вовремя завершить проект.С другой стороны, многие люди иметь получил выговор за то, что не реализовал проекты вовремя.

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

3) Если ты делать убедить всех правильно поддерживать код, к нам придут новые люди, и их нужно будет научить, как все делать правильно.Таким образом, даже если вы добьетесь успеха, вы можете чувствовать, что терпите неудачу, потому что вы всегда ведете одну и ту же битву с новыми противниками.

4) Возможно, вы действительно ошибаетесь.Имеет ли Microsoft финансовый смысл тратить вдвое больше часов программистов на создание надежного и удобного в обслуживании MS-Paint?Иногда уродливая, взломанная система достаточно хороша.Большинству хороших программистов трудно это понять, но обычно это потому, что они хорошие программисты.

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

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

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

Answer 10

http://catb.org/jargon/html/L/LART.htmlГКНР и др.пп ;)

Answer 11

Попросите их прочитать (хотя они никогда не прочтут) теорию инкапсуляции:http://www.edmundkirwan.com/