Профессия — 1С » Абстрактный анализ кода

Профессия — 1С

Рукопашный бой Карташ

Категории

Абстрактный анализ кода

рубрики: Философия разработки | Дата: 8 августа, 2020

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




Это касается как конфигураций на платформе 1С:Предприятие, так и приложений с использованием любого другого стека технологий. И все бы ничего — раз оборудование позволяет перелопачивать такие объемы. Но как мы знаем лишь малая часть работы программиста состоит из творческого процесса по написанию кода. А по большей части приходится заниматься поиском ошибок, мелкими доработками, рефакторингом и т.д. И многим знакома ситуация, когда после перехода через десяток процедур ты уже не понимаешь где ты находишься, как вообще ты сюда попал и что было в прошлых процедурах. Это приводит к многократному повторению одного и того же пути в отладчике и желанию разбить монитор клавиатурой, что не отменяет необходимости решить задачу. Итак, что же мы можем с этим сделать?

В каких случаях возникает проблема

  • Необходимо найти ошибку в большом количестве кода с использованием большого количества процедур.
  • После того как ошибка найдена, как правило возникает вопрос: «Что делать?». Потому что очень часто устранить ее можно несколькими способами и в нескольких местах. При этом нужно сохранить работоспособным прежний функционал, чтобы не получилась ситуация из разряда одно лечим, другое калечим. А для этого в свою очередь надо понять как работает вся эта огромная машина и на что влияют твои изменения.
  • Рефакторинг. Ну допустим, с целью увеличения производительности.
  • Разработка нового функционала, который подразумевает использование ранее плохо разработанного кода. Часто бывает, что в одну процедуру свалено огромное количество кода, который не был вынесен в отдельные процедуры по своему функциональному назначению. Могут встречаться дубли процедур и т.д. И вписаться в это чудо программистской мысли бывает очень трудно.

Что делать

Конечно же нам на помощь придет абстракция.




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

Как делать

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

Поэтому наша сила в простоте. Открываем свой любимый блокнот или excel и начинаем накидывать туда имена процедур, последовательность их вызова, возможно даже условия и циклы в очень сокращенном виде. Можно даже на листочке бумаги схемы почиркать. Главное чтобы эта схема была понятна вам самим. По сути это одноразовая вещь. И после исправления ошибки никому будет не нужна. Вряд ли придется ее кому-то показывать. Поэтому еще раз повторю — на стандарты не смотрим, главное чтобы было понятно самому.




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

Заключение

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

Добавить комментарий

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

   

2014 - 2020г. Профессия — 1С. Обмен опытом по программированию в 1С