Разработка программного кода. Дублирование кода в программировании, создание велосипеда в разработке

Проблема дублирования кода в программировании

Проблема постоянного воспроизведения одного и того же на самом деле гораздо более критична, нежели это может показаться. 

Это ограничивает возможности роста.

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

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

В итоге мы теряли деньги и время на проработку похожего функционала. 

Как мы избежали этого? Через создание платформы с дополнительным системным слоем. 

Создание программного кода компонента. Наш кейс

Возьмем таблицу. Раньше разработчик использовал низкоуровневый компонент на JS и делал все необходимые манипуляции для создания таблицы: 

• Создавал слой доступа к базе данных DAL
• Создавал метод бизнес-логики BLL
• Создавал контроллер, который выдавал на front некоторый JSON объект
• Настраивал JS компонент на front 
• Добавлял стилизацию через CSS 

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

Как выглядит сейчас наш подход для создания таблиц: 

1. Создать в панели исходный программный код управления объектом таблица, его колонки
2. Положить сниппет таблицы (просто div) на странице
3. Настроить хранимые процедуры GetItems, UpdateField, DeleteItem в панели управления - они имеют заранее заданный формат и создаются по шаблону. 

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

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

Главный момент - это весь компонент представляет собой просто пакет SQL, который можно сгенерировать для компонента. Это позволяет переносить подобные компоненты между решениями, например, обновлять некие системные элементы управления в проекте. 

Преимущества нового подхода:

• гораздо легче переносить программный код сайта.
• накопление кодовой базы в платформе. Все нетиповые решения либо внедряются в платформу, либо создается база знаний с примерами кода как это сделать в платформе. 
• обновление решений. Найденные ошибки в ядре исправляются не только в отдельном экземпляре, но и положительно влияют на качество других проектов. 
• меньше ошибок и неточностей. Большинство неточностей возникает из-за неверной настройки процедур. Ядро относительно стабильное - меньше вероятность, что ошибка где-то в нем.
• проще искать ошибки. Т.е. стек очень узкий (SQL & Bootstrap), то и 95% ошибок будет где-то в хранимых процедурах разработчика, а не размазаны между хранимыми процедурами, DAL, BLL и JS. 
• накопление возможностей платформы. Постепенные доработки ядра шлифуют компоненты. Появляются новые настройки компонентов, возможности. Это ускоряет разработку отдельных страниц в новом проекте, снижает  себестоимость работ. 

Заключение

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

P.S. Рекомендуем также изучить нашу статью о качестве кода программы и компоненте в программном продукте.