Чтобы переписать или нет?

Question

Это стратегический вопрос. У меня есть большая часть программного обеспечения, основанная на Интернете, которая обрабатывает, вероятно, около 50-60 различных задач. Программное обеспечение использует около 100 таблиц MySQL и, вероятно, можно рассматривать как 3 больших модуля, предназначенных для 3 разных групп аудитории. Он работает очень хорошо.

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

Система была построена на проприетарной программной платформе; платформа обеспечивает надежную защиту (беспрецедентно в 99% других веб-платформ, силосов с силовыми установками, принудительно параметризованных SQL, ACL на основе строк на основе данных MySQL) и производительности (ресурсы растут по мере того, как количество приложений, а не количество одновременных ударов). Оказывается, нам не нужны преимущества производительности, но было неплохо использовать.

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

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

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

Answer 1

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

Read Joel's post on this. It pretty much sums it up.

Answer 2

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

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

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

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

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

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

Answer 3

См. When to rewrite a code base from scratch для дополнительной дискуссии по аналогичной теме.

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

Answer 4

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

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

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

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

Answer 5

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

1. Карантин от всего кода, который вы определяете, требует переписывания и отслеживания того, что там находится. С этого момента все новые коды должны быть размещены в новых сборках.
2. Если для «помещенного на карантин» кода требуется новая функция, необходимо, чтобы этот конкретный раздел был переписан, прежде чем функция сможет продолжить. (Мы изначально были намного сложнее с этим и имели политику «без изменений», но перед лицом серьезной ошибки нецелесообразно переписывать и задерживать исправление/риск, добавляя больше ошибок)
3. Всякий раз, когда происходит переход старого кода к новому коду, максимально приблизьтесь к человеческому возможному до 100% -ного охвата тестирований и проверьте функциональность нового кода на старый код.

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