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

Question

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

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

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

Answer 1

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

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

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

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

Answer 2

Дисциплина

Answer 3

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

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

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

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

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

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

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

Answer 4

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

Вот ответ.

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

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

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

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

Answer 5

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

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)
или
Используйте для этого код beautifier
5. Подумайте, как работать командой (даже если вы были один), и не только вы будете читать ваш код (даже если он был)
6. Код рефакторинга тоже должен быть хорошим
7. Проконсультируйтесь со своими товарищами по команде о коде, который вы написали, они могут его прочитать?
8. Узнайте из сообщества OpenSource , как они работают, а также поделитесь кодами и патчами
9. Если можете, используйте SVN или CVS для сохранения своего кода

и помните Принцип поцелуя ( K eep I t S орудия, S тупой)

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

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

Answer 8

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

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

С Software Engineering вы понимаете, что не все в команде идеальны. Вы просматриваете код, вы проверяете, что другие тестируют, вы перепроверяете друг друга.

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

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

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

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

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

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

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

Answer 9

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

Answer 10

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

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