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