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

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

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

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

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

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

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

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

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

Удачи!

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

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

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

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

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

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

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

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

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

На самом деле мне неприятно высказывать особое мнение по этому поводу, но ...

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

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

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

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

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

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

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

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

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

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

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

Скажите им, чтобы они прочитали (но они никогда не прочитают) теорию инкапсуляции: http://www.edmundkirwan.com/