Качество кода программы — ревизия кода и рефакторинг
Введение
В статье мы рассмотрим вопрос Зачем нужен рефакторинг кода программного продукта.
Любая программа состоит из кода. Этот код пишется людьми. Причем этот процесс происходит не единоразово, а инкрементно - т.е. код создается постепенно.Сначала одну часть написали, потом другую, потом третью. Потом добавили что-то в первую часть. Т.е. программа и даже ее часть не пишутся единоразово, а постоянно шлифуются и обрастают новыми деталями.
Погружение
Чем дольше история изменений по коду, тем больше таких наслоений кода. А это порождает мелкие нестыковки. Программист, дописывающий код в модуле, должен в идеале полностью знать все детали и стиль написания предшествующего кода.В реальности так бывает редко. Даже автор исходного кода может забыть какие-то нюансы.Новый код также порождает свои нюансы.Чем больше таких итераций, тем обычно сложнее код, сложнее его читать, сложнее его поддерживать.
Все это приводит к тому, что код становится все более сложным для модификации: чуть поправил бизнес-логику в одном месте, в другом месте отвалилось что-то.
Каждая новая правка обходится дороже из-за сложности кода, риска ошибок и больше количества времени для того, чтобы разобраться где и что менять.
Некачественный код также может и создавать реальную проблему для производительности. Заметно это станет только на больших объемах данных или трафика.Важно выявлять паттерны проблемного кода на ранних стадиях, т.к. решение этих проблем на поздних стадиях в разы будет сложнее.
Разная квалификация разработчиков
Другая проблема - это менее опытные коллеги. Разница между опытным и неопытным разработчиком - просто гигантская. Здесь нельзя сравнить программиста с грузчиком, водителем или какой-то другой профессией.Сильный программист может быть в 20 раз продуктивнее слабого. Плюс слабый программист порождает проблемный код. Если вы сажаете потом за доработку этого кода сильного программиста, он будет работать медленнее!
По опыту обычно проблема в том, что плохой код обычно очень витиеватый, сложный для понимания, хрупкий (чуть что поменяешь и он где то начинает падать).Разбираться в таком коде - сущий ад. И зачастую все заканчивается тем, что начинают этот код просто переписывать с нуля. А это новые затраты для проекта.
Почему так вышло?
Необходимо своевременно контролировать качество программного кода кода. Т.е. желательно сделать так, чтобы любой код проходил хотя бы минимальную проверку другим программистом.
В реальности это не так просто сделать по следующим причинам:
- Есть сроки, заказчик торопит. И первое, чем жертвуют в таких случаях - качество программного кода. Причем скрытое качество, а не видимую часть.
- Ревизию кода должен делать опытный программист. А его время самое дорогое. И он мог бы что-то сам написать в это время, а не исправлять за другими ошибки.
- В принципе не хотят на это закладывать бюджет. Это не дает видимого результата проекту (возможно недоверие разработчикам). Т.е. в целом, эта работа не проводится на проекте.
- Использование таких инструментов, которые изначально подразумевают сложную структуру и высокий уровень требований к разработчикам. Чем выше нужен уровень разработчика, тем больше проблем будет в реальности.
Как мы решаем проблему кода
Первое - часть проблем решается за счет особенности платформы Falcon Space. Это узкий стек разработки. Программист может написать код только в одном слое - в SQL.Это упрощает поиск проблемного места (раньше проблему нужно было искать по всему стеку разработки, особенно, что касается дублей запросов SQL).Также платформа позволяет диагностировать некоторые проблемы, создаваемые разработчиками (например, дубли однотипных запросов с клиента).
Второе - требования к разработчику относительно небольшие - просто хорошо знать sql и уметь писать базовый HTML. Чем проще технологии, чем их меньше надо знать - тем глубже человек их может знать, тем сфокусированнее он будет на известных проблемах своего языка.Мы стараемся сделать так, чтобы разработчик по минимуму использовал CSS и JS. Чем больше кастомного нетипичного кода - тем дольше отладка, тем больше времени он требует для будущих доработок.
Третье - код в процедурах пишется по паттерну. Т.е. если вы создаете таблицу, вы создаете типовые процедуры и наполняете их своей бизнес-логикой по шаблонным процедурам.Это сильно уменьшает вероятность какого-то "гениального" решения, которое будет валить весь сервер.
Четвертое - есть модуль Ревизия кода, в котором виды последние измененные процедуры - можно сразу их править + можно делать заметки по ревизии.Ревизия является причиной для рефакторинга - т.е. улучшения кода без изменения его функциональности. Находим проблемные места, улучшаем их, иногда полностью переписываем.
Пятое - декларативное использование возможностей. Разработчик не должен делать велосипеды в проекте. Если нужна модальная форма или модальная таблица, у него есть только 1 способ это сделать через разметку.Если он хочет вывести подтаблицу в таблице - он декларативно указывает параметр (опять же только одним способом он может это делать).
Заключение
Обычно владелец продукта вообще ничего не знает про эти моменты, никак их не учитывает и не понимает проблематику этих нюансов.Команда разработки зачастую пытается подстроиться под заказчика и урезает бюджет на рефакторинг. В целом, на начальных этапах он не критически нужен, ведь продукт и так будет работать функционально верно.Но это закладывает будущие возможные проблемы. Если вы намерены делать свой продукт в долгую с множеством будущих изменений и доработок, то качество программного кода является принципиально важным моментом.
Чем раньше будут исправлены внутренние ошибки кода, тем проще в дальнейшем это поддерживать.
Закладывайте хотя бы 5-7% от бюджета этапа доработок на выполнение этих работ. Это позволит выявить критичные проблемы, которые в противном случае будут сидеть в коде, пока они не обнаружатся уже на стадии эксплуатации, ну либо надейтесь, что их нет в коде проекта.