Рефакторинг

08 Сентября 2016 Программирование
10 0

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

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

Сейчас читаю статью: Главный вопрос программирования, рефакторинга и всего такого и (http://www.viva64.com/ru/b/0391/) по мере чтения решил поделиться своими мыслями. Автор на примерах различных реальных ситуаций показывает преимущества программы статического анализатора PVS-Studio и заодно показывает интересные вещи, которые будут полезны любому программисту. 

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

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

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

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

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

Ручные тесты не способны проверить все возможные значения. Приложение может работать в 255 случаях и неожиданно повести себя не очень хорошо в 256-м. Автоматизация теоретически может покрывать тесты на много лучше, но только если программист, который написал тест, предусмотрел нужное покрытие. 

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

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

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

Статью написал Андрей Карпов - технический директор компании, которая разрабатывает PVS-Studio. И мне понравилось то, что в ней описаны не только возможные проблемы, но и варианты правильных выходов из неловкой ситуации. 

Основным языком примеров выступил C/C++, который пока еще кажется самый популярный и на котором разрабатывается большинство приложений. Хотя в начале статьи сказано, что примеры будут полезны и программистам на других языках, большинство примеров все же уж слишком специализировано для C/C++, потому что много рассказано багов с указателями, выделением памяти и т.д. 

Я знаю C++ и начинал программировать в 90-е еще на C под MS DOS, поэтому с удовольствием прочитал всю статью. Если ты не интересуешься низкоуровневым программированием, я все равно рекомендовал бы прочитать все советы. Хотя бы просто для общего развития. 

Понравилось? Кликни Лайк, чтобы я знал, какой контент более интересен читателям. Заметку пока еще никто не лайкал и ты можешь быть первым