5 грехов разработчика, из-за которых сопровождение кода превращается в ад

Любой дурак сможет написать код, который поймет машина. Хорошие программисты пишут код, который сможет понять человек. (с) Мартин Фаулер, автор книг и статей по архитектуре ПО

Кто-то может спросить, почему так важно писать код, понятный человеку. Личным кейсом я поделился в прошлом посте. Если кратко: программист 1С (и не только) больше времени тратит на чтение кода, нежели на его написание.

Если код сложно читать и понимать, то и накосячить в нем проще простого, и развивать его сложнее, дольше и дороже. О самых запущенных случаях и говорить не хочу – из-за них спецы чувствуют себя как в аду, и быстро выгорают (ведь в аду очень жарко 🙂 ).

Я выделил топ-5 грехов разработчика, из-за которых работа с его кодом становится сродни катастрофе.

1️⃣ Нестандартное (или отсутствующее) форматирование кода. Проблемы с оформлением бывают в основном у новичков. Некоторые придумывают свой уникальный стиль, не зная, что есть готовые стандарты. Другие вообще не заморачиваются с оформлением.

Итог: читать этот код нужно особенно внимательно. И постоянно задаваться вопросами вроде «где я – в цикле или в какой-то ветке какого-то условия?»/ «а в этой длинной строке одна операция или еще 10?»

Что делать: читать типовой код, перенимать его стиль, изучать стандарты оформления.

Хорошая новость: отформатировать код можно автоматически (расскажу об инструментах для этого в другой раз).

Плохая новость: если отформатировать изначально плохой код, он не станет внезапно хорошим. 🤗

2️⃣ Непонятные названия процедур, функций, переменных. Такой грех водится и за опытными разработчиками. Придумать краткое и емкое имя переменной порой сродни мукам поиска заголовка для статьи. Проще написать первое, что пришло в голову. В лучшем случае оставить рядом поясняющий комментарий. Но это если настроение есть. 😉

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

Что делать: практиковаться в придумывании имен и не жалеть на это времени. Задавайтесь вопросом – что конкретно делает эта процедура или хранит переменная. Если хорошее имя есть, код станет понятен без комментариев. А учитывая, что в 1С программируют по-русски, его можно будет читать как документацию.

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

Плохая новость: но это не точно. 😆

3️⃣ Велосипедостроение. Под этим я подразумеваю героическое решение задач, которые давно решены другими. Или внесение доработок авторским способом, когда в компании уже есть сложившаяся практика на этот счет или даже регламенты.

Итог: другим приходится тратить время и разбираться в наработках и приемах автора кода «с велосипедами».

Что делать: разрабатывать и внедрять регламенты, стандарты, и заставлять разработчиков им следовать.

Хорошая новость: у 1С есть готовая система стандартов разработки прикладных решений, библиотека стандартных подсистем (БСП).

Плохая новость: если разработчик любит изобретать велосипеды, то он будет их изобретать несмотря ни на что.

4️⃣ Трюкачество. Это необычные приемы программирования, которые усложняют решения даже простых задач. Часто трюки используют для оптимизации или для сокращения объема кода. Но если в первом случае это еще может быть оправдано (далеко не всегда!), то во втором – это просто намеренное вредительство.

Итог: чтение и доработка кода с трюками – то еще удовольствие, ошибки обеспечены.

Что делать: перечитывать код, задавая себе вопрос – «а разобрался бы с этим джун Вася из соседнего отдела?» Если ответ – «вряд ли», лучше код переписать.

Хорошая новость: разработчик, который знает толк в трюках — сможет написать код без них.

Плохая новость: если трюки в коде разработчика получаются вопреки его желанию — ему есть над чем работать. 🤔