Как вы заставляете людей ценить абстракцию и гибкость, а не просто делать это? - PullRequest
6 голосов
/ 17 октября 2008

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

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

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

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

Ответы [ 11 ]

7 голосов
/ 17 октября 2008

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

6 голосов
/ 17 октября 2008

Убедите их, что использование ярлыков - ложная экономия.

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

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

4 голосов
/ 17 октября 2008

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

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

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

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

4 голосов
/ 17 октября 2008

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

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

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

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

Удачи!

3 голосов
/ 17 октября 2008

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

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

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

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

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

3 голосов
/ 17 октября 2008

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

2 голосов
/ 17 октября 2008

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

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

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

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

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

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

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

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

2 голосов
/ 17 октября 2008

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

2 голосов
/ 17 октября 2008

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

0 голосов
/ 17 октября 2008

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

...