Как Вы поддерживаете низкокачественную кодовую базу?

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

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

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

Большинство моих проектов является также помещенным onder ContinuousIntegration; рядом с созданием и выполнением unittests, статический анализ кода (fxcop) выполняется также. Время от времени я взглянул на результаты и пытаюсь зафиксировать некоторые нарушения, о которых сообщают.

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

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

1. Кто-то в команде с достаточными полномочиями должен заботиться. Это - самая важная часть. Если никто не будет заботиться, то это не будет сделано. Эта точка кажется очевидной, но это не.

2. Установите нормы и лучшие практики. Большинству языков записал книгу кто-то о лучших практиках. Например, в Perl существует очень хорошая книга Лучших практик Perl Damain Conway. Если Вы не делаете это, каждый человек в команде поступает по-своему, чтобы написать код, переменные имени, прокомментировать и т.д.

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

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

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

Некоторое чтение для ссылки.

Связанный вопрос: Как людям сходит с рук написание низкокачественного кода?

Вот ответ.

Хорошая стратегия некомпетентных людей в нашей промышленности - это:

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

2. Сделайте полную путаницу кода, которого Вы касаетесь.

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

Я хотел бы представить Вас термину, который я слышал несколько лет назад - Технический Долг. Вот (1) статья в Википедии и другой от Martin Fowler (2) веб-сайт.

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

От Fowler:

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

Из Википедии:

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

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

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

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

Существует много качественных инструментов вокруг сегодня, таких как fxCop (и другие как он) однако, необходимо тщательно выбрать, какие подходы Вы собираетесь развлечь.

Усилие в поддержании качества в дизайне и в кодовой базе должно составляться, поэтому думайте тщательно о самом эффективном и полезном пути к своей группе разработчиков/product/company/customers и т.д.

[(1) http://en.wikipedia.org/wiki/Technical_debt]
[(2) http://martinfowler.com/bliki/TechnicalDebt.html]

Это просто имеет место, когда Вы пишете код, и другие люди читают его
1. Оставленный дурные привычки
2. Используйте значимую процедуру, функцию, имя переменной
3. Используйте документацию о том, как она (процедура/функция/вычисление/и т.д.) работает и что следовало, что, не делайте ненужный комментарий
4. Попытайтесь дать стиль своему кодированию, таким образом, люди могут знать это (такие как использование кода стиля GNU)
или
Используйте программу изящного форматирования кода для этого
5. Думайте для работы командой (даже если Вы были одними), и не только Вы, которые прочитают Ваш код (даже если это было),
6. Осуществите рефакторинг код, должно быть хорошим также
7. Консультируйтесь со своими товарищами по команде о коде, Вы были записью, они могут считать его?
8. Извлеките уроки из Сообщества разработчиков ПО с открытым исходным кодом, как они работают и совместно используют коды и патчи
9. Если Вы можете, использовать SVN или CVS для поддержания Вашего кода

и помните принцип KISS (Сохраните Его Простым, Глупым),

и конечно Простой, Минимизированный, Средний и Красивый

если это инвертировало (другие люди пишут, Вы читаете), я не знал, что к сказанному :D (возможно, дают этому людей выше советов LOL),

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

Я рекомендую забрать копию Michael Feather, "Работающего Эффективно с Унаследованным кодом".

Fridgemagnet заявляет: "У тусклых программистов есть безупречные кодовые базы"

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

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

Изменение, о котором Вы спрашиваете, является по существу переходом от взламывания до программирования и наконец Разработки программного обеспечения.

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

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

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

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

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

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

Обычно эти хорошие методы реализованы после ГИГАНТСКОГО проекта, который полностью перестал работать, потому что кодовая база сосет настолько плохо. Затем они увольняют любого, кто не может избежать вины, нанять некоторых менеджеров, у которых, надо надеяться, есть некоторый опыт с большими проектами и (если они не остаются без денег), перезапуск от эпицентра.

По крайней мере это - мой опыт. YMMV

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

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