рубрики: Философия разработки | Дата: 8 августа, 2020
В сегодняшнем мире размер приложений, а соответственно и количество строк кода из которых состоят эти приложения, принимает все более угрожающие размеры.
Это касается как конфигураций на платформе 1С:Предприятие, так и приложений с использованием любого другого стека технологий. И все бы ничего — раз оборудование позволяет перелопачивать такие объемы. Но как мы знаем лишь малая часть работы программиста состоит из творческого процесса по написанию кода. А по большей части приходится заниматься поиском ошибок, мелкими доработками, рефакторингом и т.д. И многим знакома ситуация, когда после перехода через десяток процедур ты уже не понимаешь где ты находишься, как вообще ты сюда попал и что было в прошлых процедурах. Это приводит к многократному повторению одного и того же пути в отладчике и желанию разбить монитор клавиатурой, что не отменяет необходимости решить задачу. Итак, что же мы можем с этим сделать?
Конечно же нам на помощь придет абстракция.
То есть необходимо выделить главные моменты и работать уже с ними, а остальное отбросить. Плохо то, что для этих задач не существует какого-то универсального метода построения абстрактной модели. Конечно существует много литературы и информации в интернете о всяческих паттернах проектирования и различных подходах к написанию программ. Но они пригодны в основном при реализации приложения с нуля. Ну если не целого приложения, то какого-то отдельного блока, который взаимодействует с остальными через какой-то API. Поэтому для вышеописанных случаев необходимо строить свою абстрактную модель для каждого конкретного случая. К тому же этих абстрактных моделей может потребоваться несколько. Иногда только после разделения существующего кода на несколько слоев абстракций начинает что-то проясняться.
Конечно же абстрактная модель должна иметь какую-то физическую форму. Будь то блок-схема, текстовое описание, перечень используемых процедур и функция и т.д. В первую очередь в голову приходит конечно же мысль о блок-схеме. Но с точки зрения временных затрат это нецелесообразно. Разве, что в случаях связанных с рефакторингом и с реализацией нового функционала. А чаще всего время поджимает и заказчик долго ждать не готов.
Поэтому наша сила в простоте. Открываем свой любимый блокнот или excel и начинаем накидывать туда имена процедур, последовательность их вызова, возможно даже условия и циклы в очень сокращенном виде. Можно даже на листочке бумаги схемы почиркать. Главное чтобы эта схема была понятна вам самим. По сути это одноразовая вещь. И после исправления ошибки никому будет не нужна. Вряд ли придется ее кому-то показывать. Поэтому еще раз повторю — на стандарты не смотрим, главное чтобы было понятно самому.
И вот когда после нескольких тысяч строк кода получается схема или текст который умещается на одном листе, то очень многие вещи сразу встают на свои места.
Конечно, если после пары проходов в отладчике все становиться понятно, то нет смысла тратить время на построение всяких схем. Но когда вы прошли один и тот же путь один раз, второй, третий и чувствуете, что ни на шаг не приблизились к пониманию как это работает, а мысли в голове начинают бегать по кругу, то пожалуй стоит отбросить второстепенное и оставить основное.
Добавить комментарий