Любой дурак сможет написать код, который поймет машина. Хорошие программисты пишут код, который сможет понять человек. (с) Мартин Фаулер, автор книг и статей по архитектуре ПО
Кто-то может спросить, о чем вообще речь в этой цитате, и почему так важно писать код, понятный человеку. Если кратко: программист 1С (и не только) больше времени тратит на чтение кода, нежели на его написание.
Если код сложно читать и понимать, то и накосячить в нем проще простого, и развивать его сложнее, дольше и дороже. О самых запущенных случаях и говорить не хочу – из-за них спецы чувствуют себя как в аду, и быстро выгорают.
Ниже мои топ-5 огрехов разработчика, из-за которых работа с его кодом становится сродни катастрофе.
1. Нестандартное (или отсутствующее) форматирование кода. Проблемы с оформлением бывают в основном у новичков. Некоторые придумывают свой уникальный стиль, не зная, что есть готовые стандарты. Другие вообще не заморачиваются с оформлением.
Итог: читать этот код нужно особенно внимательно. И постоянно задаваться вопросами вроде «где я – в цикле или в какой-то ветке какого-то условия?»/ «а в этой длинной строке одна операция или еще 10?»
Что делать: читать код типовых конфигураций, перенимать его стиль, изучать стандарты оформления.
Хорошая новость: отформатировать код можно автоматически (инструментов для этого много, расскажу о них в другой раз).
Плохая новость: если отформатировать изначально плохой код, он не станет внезапно хорошим.
2. Непонятные названия процедур, функций, переменных. Такой грех водится и за опытными разработчиками. Придумать краткое и емкое имя переменной порой сродни мукам поиска заголовка для статьи. Проще написать первое, что пришло в голову. В лучшем случае оставить рядом поясняющий комментарий. Но это если настроение есть.
Итог: при чтении кода с непонятными именами приходится постоянно прыгать от вызова функции к ее описанию, чтобы понять, что она выдает. Или от места использования переменной к месту присвоения ей значения, чтобы понять, что она хранит. Это, опять же, отнимает время и силы.
Что делать: практиковаться в придумывании имен и не жалеть на это времени. Задавайтесь вопросом – что конкретно делает эта процедура или хранит переменная. Если хорошее имя есть, код станет понятен без комментариев. А учитывая, что в 1С программируют по-русски, его можно будет читать как документацию.
Хорошая новость: возможно, в непростом деле придумывания имен нам вскоре смогут помочь нейросети.
Плохая новость: но это не точно.
3. Велосипедостроение. Под этим я подразумеваю героическое решение задач, которые давно решены другими. Или внесение доработок авторским способом, когда в компании уже есть сложившаяся практика на этот счет или даже регламенты.
Итог: другим приходится тратить время и разбираться в наработках и приемах автора кода «с велосипедами».
Что делать: разрабатывать и внедрять регламенты, стандарты, и заставлять разработчиков им следовать.
Хорошая новость: у 1С есть готовая система стандартов разработки прикладных решений, библиотека стандартных подсистем (БСП).
Плохая новость: если разработчик любит изобретать велосипеды, то он будет их изобретать несмотря ни на что.
4. Трюкачество. Это необычные приемы программирования, которые усложняют решения даже простых задач. Часто трюки используют для оптимизации или для сокращения объема кода. Но если в первом случае это еще может быть оправдано (далеко не всегда!), то во втором – это просто намеренное вредительство.
Итог: чтение и доработка кода с трюками – то еще удовольствие, ошибки обеспечены.
Что делать: перечитывать код, задавая себе вопрос – «а разобрался бы с этим джун Вася из соседнего отдела?» Если ответ – «вряд ли», лучше код переписать.
Хорошая новость: разработчик, который знает толк в трюках — сможет написать код без них.
Плохая новость: если трюки в коде разработчика получаются вопреки его желанию — ему точно есть куда расти.
5. Возведение монолитов. Хорошая программа состоит из отдельных, слабо связанных между собой элементов. В этом случае с ней проще разобраться – не нужно «есть слона целиком», он уже разделен на части. А отдельные элементы можно переиспользовать для решения других задач. Но разрабатывать такие программы сложнее – требуется навык правильной декомпозиции задачи на составляющие. И навыку этому нельзя просто где-то научиться, он приходит только с опытом. Поэтому у неопытных разработчиков решение большой задачи часто выливается в монолитный код с кучей внутренних связей.
Итог: дорабатывать и исправлять такой код опасно. Починишь в одном месте – сломаешь в трех других. А чтобы добавить новый функционал – приходится менять уже существующий и хорошо работающий код.
Что делать: привлекать опытного специалиста, хотя бы для проектирования решения и проверки кода разработчика. А разработчику – набираться опыта, изучать код других, читать книги по методологиям разработки ПО.
Хорошая новость: опытные спецы есть, их на рынке много.
Плохая новость: они стоят дорого
Лучшее средство для искоренения всех перечисленных проблем – ревью кода. Программист постарше изучает код коллег и вершит над ними страшный суд дает им советы о том, что и где нужно исправить. Да, в 1С это мало кто делает. Да, это трудоемко. И да, это дорого. Но поверьте – некачественный код в конечном счете обходится дороже.
В комментариях предлагаю поделиться вашими методами борьбы за качество кода. Или рассказать о том, какие огрехи в коде – ваша личная боль. У меня, например, с наименованиями пока бывают сложные отношения. Сегодня имя кажется хорошим, а через неделю, возвращаясь к коду – уже не понимаю, что я имел в виду под этим именем. :)
