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

Question

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

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

Так!Мне любопытно.Как вам удается поддерживать некачественную кодовую базу?

Answer 1

Дисциплина

Answer 2

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

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

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

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

Answer 3

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

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

2. Установите стандарты и лучшие практики.Для большинства языков есть книга, написанная кем-то о лучших практиках.Например, в PERL есть очень хорошая книга «Лучшие практики Perl» Дэмейна Конвея.Если вы этого не сделаете, у каждого человека в команде будет свой собственный способ писать код, называть переменные, комментировать и так далее.

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

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

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

Некоторый чтение для справки.

Answer 4

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

Answer 5

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

Вот ответ.

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

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

2. Сделайте полный беспорядок в коде, к которому вы прикасаетесь.

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

Answer 6

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

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

От Фаулера:

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

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

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

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

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

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

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

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

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

Answer 7

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

и запомни ЦЕЛОВАТЬ принцип(Кписк ят Спросто, Сглупо)

и конечно Простой, бережливый, средний и красивый

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

Answer 8

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

Answer 9

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

Я рекомендую приобрести книгу Майкла Физера «Эффективная работа с устаревшим кодом».

Answer 10

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

Answer 11

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

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

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

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

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

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

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

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

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

По крайней мере, это мой опыт.ЯММВ

Answer 12

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

Answer 13

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