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

Question

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

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

Answer 1

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

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

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

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

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

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

Answer 2

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

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

Answer 3

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

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

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

Answer 4

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

Answer 5

Исповедь:

Я использовал «#define private public» в C ++ для чтения данных из некоторого другого уровня кода. Это пошло как взлом, но работает хорошо, и исправление этого никогда не стало приоритетом. Сейчас 3 года спустя ...

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

Answer 6

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

1. Разработка через тестирование

2. Малые единицы рефакторинга

3. Непрерывная интеграция
4. Хорошее управление конфигурацией
5. Методы гибкой базы данных / рефакторинг базы данных

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