Как сделать так, чтобы временные решения не длились вечно?

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

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

Напишите тестовый пример, в котором взломать невозможно.

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

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

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

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

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

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

Вот отличная статья о техническом долге .

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

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

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

Другой вариант, который будет работать, - это добавить функцию bug. В вашу платформу отслеживания (она у вас есть, верно?) С подробным описанием доработки. Таким образом, это будет видно и в какой-то момент может вызвать проблему.

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

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

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

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

[Редактировать]

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

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

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

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

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

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

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

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

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

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

• Я убеждаюсь, что я говорю о приоритете долгосрочного исправления, ОСОБЕННО после того, как краткосрочное исправление было внесено.
• Я подробно описываю причины, по которым это взлом, а не хорошее долгосрочное решение, и использую их, чтобы заинтересованные стороны (менеджеры, клиенты и т. Д.) Поняли, почему это необходимо исправить.
• В зависимости от случая, я могу даже привнести туда немного страха наихудшего сценария. «Если эта безопасная линия порвется, весь мост может рухнуть!»
• Я беру на себя ответственность придумать долгосрочное решение и следить за его развертыванием

Это трудный вызов. Я лично занимался хакерскими атаками, потому что иногда вам НЕОБХОДИМО выпустить этот продукт в руки покупателей. Однако способ, которым я занимаюсь, - это просто делать это.

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

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

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

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

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

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

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

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

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

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

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

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

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

// TODO: Better solution required.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Признание:

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

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

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

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

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

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

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