Короткая заметка про код, случайно увиденный аналитиком

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

Итак, примеры того, что мне не нравится.

1. Когда не знают и не интересуются типовыми механизмами реализации задач.

Например, при заполнении табличной части с номенклатурным составом из другого документа для заполнения данных по бух учету — не пользуются регистром «Счета номенклатуры», а просто в коде прописывают что-то, а потом приходиться переделывать.

Считают НДС умножением на 1,2. А в типовой — не так!

2. Когда непонятно, зачем аналитик задачу ставит.

Когда прямо говоришь, что реквизит А из документа нужно выводить в печатную форму – в коде развлекаются перебросом А в переменную В, и далее, по пути А становится уже на А, а еще куча всего. Хотя сказала ж! И не нужно префиксы обрезать, нужны мне они)

3. Не выдерживают логику ТЗ

Когда пишу, что такое то условие должно выполняться, если выполняется условие А, то оно таки должно выполняться! а не выполняться, когда НЕ выполняются другие условия (В и С), даже если они сейчас являются остатком от полного списка условий на данную минуту времени. Позже могут появиться другие условия, D и F, и как там должно работать – это совсем другой вопрос.

Получается, что аналитик может не знать логику системы, спроектированной им же.

Почему-то в обычной речи такой логики нет:

Мы НЕ пойдем гулять ИЛИ Да?.

4. Делают, то чего не просят.

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

5. Не комментируют код.

Фамилия и дата — это не достаточный комментарий.

Нужно писать, что ты делаешь в куске кода.

Из-за сложности поддержки такого кода появляются следующий радующий момент, когда есть витки кода, каждый раз проверяющие, нужно или не нужно выполнять условие. Например, Если А=В, то делаем С, через несколько условий опять Если А=В то делаем D, ну и потом еще несколько раз.

Хорошо бы один раз проверить условие и внутри написать все, что выполнить. Просто нужно выделить каждую процедуру и по-человечески написать.

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

Написать код, чтоб его поняла машина, каждый сможет, а вот чтоб его человек понял…

Вот и все, дорогие читатели.