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

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

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

ОТВЕТЫ

Ответ 1

Напишите тестовый файл, который не удалось выполнить.

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

Ответ 2

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

Стратегия 2 (нечестная): Ли и Чит. Сообщите руководству, что есть ошибки в хаке, и они могут вызвать серьезные проблемы позже. К сожалению, в большинстве случаев менеджеры просто говорят, чтобы подождать, пока ошибки не станут проблемой, а затем исправить ошибки.

Стратегия 2a: То же, что и стратегия 2, за исключением ошибок. Тем не менее, такая же проблема.

Стратегия 3 (и мой личный фаворит): спроектируйте решение, когда сможете, и делайте это достаточно хорошо, чтобы это могло сделать стажер или обезьяна кода. Легче оправдать расходы на небольшое количество денег с кодовой обезьяной, чем оправдать собственную зарплату, чтобы она могла просто закончиться.

Стратегия 4: Дождитесь перезаписи. Все жду. Рано или поздно (возможно, позже) кому-то придется переписать вещь. Возможно также, что это правильно.

Ответ 3

Вот отличная статья о технической задолженности.

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

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

Ответ 4

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

Еще один вариант, который будет работать, - добавить в структуру отслеживания ошибку bug.feature(у вас есть один, не так ли?), детализирующий переделку. Таким образом, это видно и может вызвать проблему в какой-то момент.

Ответ 5

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

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

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

Если это ошибка и соответствует требованиям, это делается. Отправим его. Двигайтесь дальше.

[изменить]

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

Ответ 6

ВЫ НЕ РАЗМЕЩАЕТСЯ ПРОМЕЖУТОЧНЫЕ РЕШЕНИЯ.

Иногда мне кажется, что программистам просто нужно сказать об этом.

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

Пожалуйста, прекратите оставлять мне свой дерьмовый код для поддержания. Просто ВСЕГДА КОДА ЭТО ПРАВО. Независимо от того, сколько времени это займет, и кто кричит на вас.

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

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

Ответ 7

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

Если вы проклинаете его, почему он находится внизу списка TODO?

  • Если это не влияет на вас, почему вы проклинали его?
  • Если это влияет на вас, тогда это проблема, которая должна быть исправлена ​​СЕЙЧАС.

Ответ 8

  • Я убеждаюсь, что я вокал о приоритете долгосрочного исправления ESPECIALLY после того, как исправлено короткое исправление.
  • Я подробно объясню причины, почему это взломать, а не хорошее долгосрочное решение и использовать их для привлечения заинтересованных сторон (менеджеров, клиентов и т.д.), чтобы понять, почему его нужно исправлять.
  • В зависимости от случая, я могу даже привнести немного худшего сценария страха в там. "Если эта безопасная линия защелкнется, весь мост может рухнуть!"
  • Я беру на себя ответственность за разработку долгосрочного решения и убедитесь, что оно развернуто

Ответ 9

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

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

Ответ 10

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

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

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

Ответ 11

Удачи. По моему опыту этого достичь почти невозможно.

Как только вы спуститесь по скользкому склону к осуществлению взлома, потому что вы находитесь под давлением, тогда вы можете привыкнуть к тому, чтобы жить с ним на все времена. Существует почти НИКОГДА достаточно времени, чтобы переработать то, что уже работает, независимо от того, насколько сильно оно реализовано внутри страны. Что заставляет вас думать, что у вас будет волшебное время больше "на какой-то более поздний срок", чтобы исправить взлом?

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

Ответ 12

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

Ответ 13

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

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

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

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

Ответ 14

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

// TODO: Better solution required.

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

Ответ 15

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

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

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

Ответ 16

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

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

Ответ 17

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

  • Сделайте его видимым для пользователей. Чем яснее, тем меньше вероятность того, что люди забудут вернуться назад и сделать это правильно, когда кризис закончится.

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

Ответ 18

Вы записываете вторую очень описательную ошибку в своем собственном "исправлении" и помещаете право на комментарии в затронутых областях, где говорится: "Эта область нуждается в большой работе. См. дефект № 555" (используйте правильный номер конечно). Люди, которые говорят, что "не кладут в шок", похоже, не понимают вопроса. Предположим, что у вас есть система, которая должна быть запущена и запущена сейчас, ваше решение без хака - это 8 дней работы, ваш хак - 38 минут работы, хак есть, чтобы купить вам время, чтобы выполнить работу, а не потерять деньги, пока вы это делаете.

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

Ответ 19

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

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

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

Очень идеалистический подход.

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

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

Ответ 20

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

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

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

Ответ 21

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

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

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

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

Ответ 22

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

Ответ 23

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

Ответ 24

Мы должны были сделать это один раз - сделайте краткосрочную демо-версию, которую мы знали, что мы не хотим ее хранить. Клиент хотел его на коробке winTel, поэтому мы разработали прототип в SGI/XWindows. (Мы свободно говорили обоим, так что это не проблема).

Ответ 25

Исповедь:

Я использовал '#define private public' в С++, чтобы читать данные с другого слоя кода. Он вошел как хак, но работает хорошо, и его фиксация никогда не становилась приоритетом. Сейчас уже 3 года спустя...

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

Ответ 26

Мой ответ немного отличается от других. Мой опыт заключается в том, что следующие методы помогут вам оставаться гибкими и перейти от hackey first iteration/альфа-решений к бета-версии готовой продукции:

  • Разработка, управляемая тестированием

  • Небольшие единицы рефакторинга

  • Непрерывная интеграция
  • Хорошее управление конфигурацией
  • Agile методы базы данных/рефакторинг баз данных

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