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

Question

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

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

Answer 1

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

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

Answer 2

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

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

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

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

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

Answer 3

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

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

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

Answer 4

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

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

Answer 5

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

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

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

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

[Изменить]

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

Answer 6

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

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

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

Answer 7

ВЫ НЕ ДЕЛАЕТЕ ВРЕМЕННЫЕ РЕШЕНИЯ.

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

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

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

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

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

Answer 8

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

Answer 9

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

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

Answer 10

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

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

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