Как вы останавливаете временные решения от вечного?

Question

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

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

Answer 1

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

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

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

Answer 2

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

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

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

Это помогает проводить аналогии с повседневными вещами. Объясните им, как, когда вы приняли временное решение, вы сделали выбор, который подходит для его быстрого строительства, а не для того, чтобы быть стабильным, ремонтопригодным и т. Д. Это все равно что выбирать строить из дерева вместо стали, потому что дерево легче резать, и, таким образом Вы могли бы построить временное решение быстрее. Однако дерево просто не может поддерживать фундамент 20-этажного здания.

Answer 3

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

// TODO: Better solution required.

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

Answer 4

Я пытаюсь построить хакерское решение, чтобы оно могло быть безболезненно перенесено на долгосрочный путь. Скажем, у вас есть парень, который строит базу данных в SQL Server, потому что это его самая сильная БД, но ваш корпоративный стандарт - Oracle. Создайте БД, используя как можно меньше непередаваемых функций (например, битовых типов данных). В этом примере нетрудно избежать типов битов, но это облегчает переход позже.

Answer 5

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

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

Это, конечно, может вообще не относиться к вашей рабочей среде: (

Answer 6

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

Answer 7

Это напоминает мне историю "CTool". Сначала CTool был предложен одним из наших разработчиков, я назову его Доном, как один из возможных способов решения нашей проблемы. Будучи серьезным трудолюбивым типом, Дон отключился и доставил рабочий прототип. Вы знаете, куда я иду с этим. В одночасье CTool стал частью рабочего процесса компании с целым отделом в зависимости от него. Ко второму или третьему дню стали поступать горькие жалобы на недостатки CTool. Пользователи подвергли сомнению компетентность Дона, приверженность и IQ. Протесты Дона о том, что это никогда не должно было быть производственным приложением, не были услышаны. Это продолжалось в течение лет . Наконец, кто-то нашел время переписать приложение, после того, как Дон ушел. К этому времени к имени CTool стало так непристойно, что назвать его CTool версии 2 не могло быть и речи. Были даже формальные похороны для CTool, несколько напоминающие сцену выполнения копира (или это был принтер?) В Office Space .

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

Answer 8

Постарайтесь объяснить стоимость взлома бизнес-людям. Тогда они могут принять обоснованное решение в любом случае.

Answer 9

Некоторые решения, которые я видел в прошлом:

• Отметьте это комментарием HACK в коде (или аналогичной схеме, такой как XXX)
• Запустите автоматический отчет и отправляйте его еженедельно по электронной почте тем, кому не все равно, сколько раз HACK комментариев появляется
• Добавить новую запись в вашу систему отслеживания ошибок с номером строки и описанием правильного решения (чтобы знания, полученные в результате исследования до написания хака, не были потеряны)
• написать тестовый пример, который демонстрирует, как хак проваливается (если это возможно), и включить его в соответствующий набор тестов (то есть, чтобы он выдавал ошибки, которые в конечном итоге кто-то захочет исправить)
• как только хак установлен и давление сброшено, немедленно начинайте с правильного решения

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

Answer 10

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

Неприятная часть проста: заставляйте ее выдавать предупреждение каждый раз, когда вы запускаете kludge.

Разорванная часть может быть легкой: мне нравится делать это, помещая kludge за именем подпрограммы. Это облегчает обновление, поскольку вы разбиваете код на части. Когда вы получаете свое постоянное решение, ваша подпрограмма может либо его реализовать, либо быть неработающим. Иногда подкласс может работать хорошо для этого тоже. Не позволяйте другим людям зависеть от вашего быстрого решения. Трудно рекомендовать какую-то конкретную технику, не видя ситуации.

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