Чистый код. Мой взгляд на жизнь в макаронных джунглях. Часть 1

06.10.23

Разработка - Рефакторинг и качество кода

Коротко о том, как я перестал быть создателем макаронного кода и непроходимых джунглей методов и модулей. Расскажу о том, что реально применяю на практике с примерами при разработке (а в основном доработке) в типовых конфигурациях 1С. Комментарии очень приветствуются.

Картинка для улыбки :)

 

 

Краткое оглавление

  1. Введение
  2. Ссылки
  3. Кто я
  4. Почему я так назвал статью
  5. Источники
  6. Глава 1
    1. Отношение к коду
    2. Основной парадокс
    3. Чистота кода и тесты
    4. Мы - авторы
    5. Правило бойскаута
  7. Практический результат
  8. Заключение

 

Введение

Доброго времени суток, уважаемый читатель. Если ты зашел в эту статью, значит ты хочешь стать чуточку лучше и ищешь пути своего развития. В этой статье я познакомлю тебя с моим личным путем развития в направлении качества кода. Данная статья не призывает строго соблюдать правила, написанные в ней, и даже не является рекомендацией. Моя цель - познакомить тебя со своим видением этого мира. Если тебе есть что сказать или обсудить - добро пожаловать в комментарии.

 

Ссылки

Ссылка на вторую часть.

Ссылка на чек-лист.

 

Кто я

Я скромный разработчик. Занимаюсь доработкой типовых конфигураций. Работаю в франчайзи. Имею небольшой опыт работы в 3 года. Начинал на 3 курсе университета, как стажер на пол ставки без наставника. Сейчас сам учу стажеров в том числе прививаю им свои взгляды на качество кода.

 

Почему я так назвал статью

Прежде всего это отсылка к макаронному коду как самому известному пороку грязного кода. Сейчас все реже и реже можно такое встретить, однако практически каждый знаком с термином «макаронный код». Почти каждому новичку рассказывают, что писать макаронный код очень нехорошо. Это общемировое понятие, присущее всем языкам программирования.

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

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

 

Источники

 

Глава 1

В этом разделе я приведу те правила из книги, которые мы используем в своей команде.

 

Отношение к коду

 
 Цитата из книги

Полностью согласен с автором, а пример с пациентом и врачом мой любимый. В 1С мы часто пробираемся через сотни модулей и процедур, и связи среди них не совсем очевидные. Казалось бы, внести элементарные изменения в расчет при проведении документа, но на деле…

Основной парадокс

 
 Цитата из книги

Множество раз видел (в том числе и за собой замечал), как разработчики закапывались в своем коде и растягивали сроки, путаясь в написанном. При этом, когда происходит рефакторинг каждого написанного кусочка, жить становится гораздо легче (так же в работу вступает правило переиспользования).

 

Чистота кода и тесты

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

 

Мы — авторы

 
 Цитата из книги

Эта мысль особенно актуальна сейчас, когда количество модулей зашкаливает. Реализуются сложные проекты в связках с типовым функционалом. В типовом функционале и так не легко разобраться, а тут ещё и дописывают. Поэтому я считаю, что стоит подумать о тех, кто будет в будущем поддерживать, дописывать и переписывать тот кусок, с которым я работаю сейчас. Данное правило особенно актуально при командной разработке. Если у вас в команде есть стиль написания – его обязательно стоит придерживаться, ведь другие могут попасть в написанный вами модуль, и они ожидают увидеть код, написанный по принятому в команде стилю.

 

Правило бойскаута

 
 Цитата из книги

Взять хотя бы типовой функционал. Даже там есть закомментированный код. Мне даже удавалось находить описание методов, которое не соответствует действительности. В целом в любом коде, методе и модуле можно внести незначительные изменения без глобального изменения функциональности. Переименовать переменную или вынести сложное условие в отдельный метод. Сложнее вынесение кусков кода в отдельные методы, но, как говорится, нет ничего невозможного. Порой такие изменения занимают 5 минут и не тормозят выполнение задачи.

 

Практический результат.

Все практические примеры будут приведены в следующей статье, так как достаточно сложно отдельно проиллюстрировать вышеперечисленные правила.

 

Заключение.

В этой главе я показал правила из главы 1 книги. Те правила, которыми я пользуюсь, которыми пользуются мои коллеги. Мне кажется, что эти правила приносят пользу нашей команде, улучшают «простоту» кода. Мы стали реже сталкиваться с проблемами, когда новым людям не понятен наш код. Когда через несколько месяцев возвращаешься к коду, и он кажется незнакомым и запутанным.

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

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

чистый код рефакторинг Роберт Мартин качество кода статья стандарты написания кода

См. также

Рефакторинг и качество кода Программист Стажер Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

В последнее время термин «чистый код» стал очень популярным. Появились даже курсы по данной тематике. Так что же это такое?

16.09.2024    13243    markbraer    64    

38

Рефакторинг и качество кода Программист Бесплатно (free)

В статье рассматривается отказ от использования процедур и унификация формата ответа функций. Способ описывается на примере развития абстрактной информационной системы, работающей с PDF файлами.

10.09.2024    873    acces969    4    

6

Рефакторинг и качество кода Бесплатно (free)

Для быстродействия большой базы данных важно не только оптимизировать запросы, но и соблюдать стандарты при разработке подписок на события, обработок для массового изменения данных, в реализации обработчиков обновления, расширений, регламентных заданий и в архитектуре СКД-отчетов. Расскажем о нюансах разработки компонентов большой системы.

28.08.2024    1089    Chernazem    3    

6

Рефакторинг и качество кода Программист Бесплатно (free)

SOLID – принципы проектирования программных структур (модулей). Акроним S.O.L.I.D. образован из первой буквы пяти принципов. Эти принципы делают код более гибким, упрощают разработку. Принято считать, что принципы SOLID применимы только в объектно-ориентированном программировании. Но их можно успешно использовать и в 1С. Расскажем о том, как разобраться в принципах SOLID и начать применять их при работе в 1С.

22.08.2024    9732    alex_sayan    41    

49

Рефакторинг и качество кода Программист Стажер Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

Рассмотрим основные принципы шаблона проектирования "Стратегия" на простом примере.

25.06.2024    4038    MadRave    34    

27

Рефакторинг и качество кода Программист Платформа 1С v8.3 Абонемент ($m)

В статье расскажу и покажу процесс проведения Code-review на примере обработки с GitHub.

1 стартмани

04.06.2024    6152    mrXoxot    55    

42

Рефакторинг и качество кода Платформа 1С v8.3 Бесплатно (free)

Поделюсь своим опытом аудита кода авторских продуктов с Infostart.ru как одним из элементов применения DevOps-практик внутри Инфостарт. Будет настоящий код, боевые скриншоты, внутренние мемы от команды ИТ-лаборатории Инфостарт и прочее мясо – все, что любят разработчики.

10.04.2024    13083    artbear    85    

108

Рефакторинг и качество кода Программист Платформа 1С v8.3 Россия Бесплатно (free)

Предлагаю вашему вниманию советы мастеров древности. Программисты прошлого использовали их, чтобы заострить разум тех, кто после них будет поддерживать код. Гуру разработки при найме старательно ищут их применение в тестовых заданиях. Новички иногда используют их ещё лучше, чем матёрые ниндзя. Прочитайте их и решите, кто вы: ниндзя, новичок или, может быть, гуру? (Адаптация статьи "Ниндзя-код" из учебника JavaScript)

01.04.2024    4123    DrAku1a    15    

39
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. rwf96 20.09.23 08:14 Сейчас в теме
Интересно, а разработчики типовых конфигураций придерживаются этих правил? Действительно, код типовых конфигураций очень запутанный, бывает, что функция состоит из одной строки, которая вызывает только другую функцию, а другая функция вызывает третью и т.д.
Поручик; sandr13; +2 Ответить
2. Lemmonbri 140 20.09.23 10:41 Сейчас в теме
(1) Во многом придерживаются. Тут вступают другие правила, которые будут изложены в следующей статье, а именно дублирование. Они стараются по максимуму переиспользовать методы, поэтому много выносят в общие модули, а общие модули вызывают другие общие модули и получается что получается...
7. lvictor58 137 25.09.23 14:37 Сейчас в теме
(1) Это связано с разными вариантами обращения к функции из других модулей Клиент, Клиент-Сервер и проч.
Lemmonbri; +1 Ответить
14. gybson 28.09.23 15:40 Сейчас в теме
(7)+повторное использование
3. sandr13 35 20.09.23 19:08 Сейчас в теме
Спасибо за статью. Вспоминается про программистов Петю, который писал правильный код, и Васю, которого очень любили заказчики за скорость выполнения их требований. Что-то похожее есть в вконтакте. Там даже проголосовать можно за разные подходы. Об этом спорили ещё в 2013-м году...
EvgeniyOlxovskiy; +1 Ответить
4. EvgeniyOlxovskiy 65 21.09.23 06:00 Сейчас в теме
(3) Об этом и написано в книге. Вася только в начале пишет быстро, но со временем скорость падает до 0. После этого просто выбрасывают весь код и начинают сначала.
alex_sayan; sandr13; +2 Ответить
6. Lemmonbri 140 21.09.23 08:19 Сейчас в теме
(4) Есть такой момент. Я выше расписал. Тут от длительности задачи так же зависит. Если мелкая задача на пару часов - скорее всего он справится. Правда может обновляемость базы снизить до нуля... Да и вообще нюансов у говнокода много. Если ты очень опытный и можешь наперед продумать много чего то можно им пользоваться осторожно. Правда таких людей единицы во всей сфере IT. Так что в общем я бы не рекомендовал. Это лично мое мнение.
Спасибо за комментарий!
sandr13; EvgeniyOlxovskiy; +2 Ответить
9. Ветер в поле 3 27.09.23 10:21 Сейчас в теме
(4)
Сталкивался с таким. Пришёл к нам программист на С#. Код писал настолько быстро, что мне, например, даже стыдно немного становилось. Я ещё только обдумываю задачу, а он ее уже реализовал. Причем он программировал на нескольких языках. Надо ему написать приложение на iPhone, он изучает язык, через 2-3 недели приложение работает. Ларчик открывается достаточно просто - используются только простейшие конструкции языка и никакого рефакторинга. Но это аукнулось через несколько лет. Простейшая задача - если раньше счета на сумму от 50 000 рублей проходили через визирование замдиректора, то теперь надо было просто поменять эту сумму на 200 000. Выполнение задачи растянулось на целый день, потому что не было одного места маршрутизации счета. Менять пришлось в нескольких десятков мест. И так происходило со всеми задачами. Руководство даёт простенькое задание, предполагая, что оно будет быстро выполнено, но поиски решения "где нужно поменять, чтобы заработало" могут составлять дни. Бывали случаи, когда вообще не могли найти. Какой-то код вносит изменения в базу, а найти его не могут. Опрашивают программистов С#, 1с, web, мобильных приложений, но никто у себя ничего найти не может.
А раньше так радовались, что все пожелания так быстро выполнялись... Но копипаст и отсутствие рефакторинга - страшная вещь!
kalyaka; VAAngelov; EvgeniyOlxovskiy; Lemmonbri; +4 Ответить
5. Lemmonbri 140 21.09.23 08:16 Сейчас в теме
(3) Тут в объеме задачи дело, я считаю. На коротких задачах Вася действительно имеет преимущество. Но в рамках проекта код Пети будет более надежным, легко поддается изменениям и быстрее закончит проект Петя чем Вася.
Кстати пример, который вы привели с вк не совсем корректен. Там суть про продажи, что можно продавать недопиленный продукт (правило Парето в том числе на это ложится). И в конечном счете Вася нанял прогеров, которые привели код к виду Пети. Прошу заметить, что тут было привлечено 2 дополнительных разработчика, а значит и трудозатраты выросли в разы.
Получается, что подход Пети и там и там использовался... Это кстати при условии что Вася не пропустил в своем первом релизе критическую ошибку, из-за которой все его клиенты заплатили на N% больше налогов и отказались от него навсегда...
Пример этот, я считаю, очень оторван от жизни. Если переложить на проекты 1С, то у нас всегда заранее известен бюджет и сроки. И от того, что ты выпустишь говнокод раньше сроков - толку ноль. Это мое мнение касаемо Вашего примера.
Спасибо за комментарий!
8. cheshirshik 70 27.09.23 09:57 Сейчас в теме
Как обычно похвалю и поругаю автора:

Плюсы:

+ За статью и время потраченное на нее.
+ Мне близок подход автора статьи. Я тоже за "чистый код".
+ Про типовые конфы я согласен. Для меня - это не джунгли. Для меня - это черная лужа, в которую ты погружаешься. Но тут надо понимать. Конфигурацию пишет группа людей. Одна команда меняется другой. Часто людям лень разбирать чужой код. Работает и работает. Поэтому получается, что вместо того, чтобы переписать старый код, они его используют и пишут поверх свои исправления. Как следсвтвие я иногда вижу функцию, вызывающую фунцию, вызывающую функцию и дающую результат.

Минусы:

- Данная статья похожа на мои сочинения в школе. Вместо того чтобы описать свои мысли вы зачем-то заливаете водой статью выдержками из книги. Я всегда думал, что инфостат нужен не для того, чтобы копипастить чужие мысли, а писать свои.
- Вы пишите: "Каждому новичку рассказывают, что писать макаронный код очень нехорошо. Это общемировое понятие, присущее всем языкам программирования.

Мне никогда про "Макаронный код" никто не рассказывал. Ни в универе, ни на курсах по программированию. Я этот термин вижу в первый раз. Я так понимаю, что его использует автор книги, которую Вы цитируете. Тогда получаетсся, что не каждому новичку это рассказывают.

- Про стандарты 1С. В самом начале вы пишите: "К книге добавлены стандарты 1С. Я потратил много времени чтобы дополнить материал из книги материалами из стандартов. С того времени я не заходил больше в стандарты."

Как Вы думаете? Для чего 1С их разработала? Для того, чтобы вы их инорировали используя даже не ваш инновационный подход? Нет. 1С созада стандарты, чтобы все программисты писали свой код по единому стандарту. Т.е. если Вася напишет код, то Петя его легко прочитает. Вот для этого разрабатывались стандарты 1С и их в работе надо соблюдать. Я вам рекомендую почаще туда заглядывать, раз уж вы разрабочик 1С. Но боюсь - это будет нудно и скучно. Видимо читать и цитировать книги зарубежных авторов намного интереснее. :-)

- Цитаты из книги тяжело читать. Сразу видно, что книга переведена на русский, причем человеком скорее всего не знающим, что такое программисты и что такое программировать, а вот ваши мысли читать легко. Сразу видно, где цитата, а где ваши мысли без строчек "цитата из книги".
VAAngelov; Ветер в поле; rpgshnik; EvgeniyOlxovskiy; Lemmonbri; +5 Ответить
10. Lemmonbri 140 27.09.23 11:25 Сейчас в теме
(8) Спасибо за комментарий!
"Данная статья похожа на мои сочинения в школе. Вместо того чтобы описать свои мысли вы зачем-то заливаете водой статью выдержками из книги. Я всегда думал, что инфостат нужен не для того, чтобы копипастить чужие мысли, а писать свои." - какой смысл перефразировать абзац или предложение из книги, смысл останется абсолютно тот же. Если я согласен с ней, привожу цитату и свои комментарии. Если не согласен - не включаю в статью :) Так же это не "сочинение", а скорее иллюстрация и попытка переложить изложенные правила на 1С. Помимо цитат я добавил примеры кода и пояснения. Если Вы считаете это водой - поясните, как сделать такой контент лучше? Или лучше его не создавать вообще?
"Мне никогда про "Макаронный код" никто не рассказывал. Ни в универе, ни на курсах по программированию. Я этот термин вижу в первый раз. Я так понимаю, что его использует автор книги, которую Вы цитируете. Тогда получаетсся, что не каждому новичку это рассказывают." - я бы не стал делать столь громких заявлений, хотя сам сделал. Добавлю слово "почти каждому новичку". Все, с кем я работал/работаю/был знаком/общался по тематике разработки - были в курсе такого термина. Обязательно добавлю это уточнение.
"1С созана стандарты, чтобы все программисты писали свой код по единому стандарту. Т.е. если Вася напишет код, то Петя его легко прочитает." - не соглашусь. Там есть некоторые пункты, которые облегчают жизнь. В большинстве своем стандарты про оптимизацию и безопасность, а не про облегчение жизни. Стандарты в типовых конфигурациях даже не соблюдаются. На партнерском форуме постоянно вылазят такие обращения от пользователей. Да и стандарты так же являются рекомендациями. Кстати на счет "инновационного подхода". Если вы посмотрите на стандарты, то там все что я изложил в статье - есть. Там написано во многом тоже самое. Про именования, про разделение и прочее. Так что это не является "инновационным подходом".
"Видимо читать и цитировать книги зарубежных авторов намного интереснее." - я пишу статью не потому что мне это интереснее, а потому что хочу поделиться подходом, который мы в команде используем (в самом начале писал). Книгу эту (как и стандарты) я прочитал ровно 1 раз, сделал документ с мыслями и выдержками и постоянно дорабатывали его в команде. По итогу получилось то, что в статье.
"Цитаты из книги тяжело читать" - для меня книга читалась очень легко, в отличии от стандартов. Я думаю это слишком субъективно, тяжело дать оценку легкости чтения.
Вы уж извините, но выскажу таки свое мнение. Я может и не лучший автор-сочинитель. Но мне показалось, что Ваш комментарий пытался задеть и, можно даже сказать, оскорбить меня: "Видимо читать и цитировать книги зарубежных авторов намного интереснее. :-)". Все же призываю критиковать статью, а не автора.
И как всегда, мое любимое. Если уж пишите минусы, предложите, как сделать лучше, как исправить минусы. Тогда и контент на инфостарте будет лучше. Статью же можно и подправить.
Ещё раз спасибо за Ваше мнение!
EvgeniyOlxovskiy; cheshirshik; +2 Ответить
13. cheshirshik 70 27.09.23 12:25 Сейчас в теме
(10)
Помимо цитат я добавил примеры кода и пояснения. Если Вы считаете это водой - поясните, как сделать такой контент лучше? Или лучше его не создавать вообще?


Пихайте цитаты в спойлер. Кто захочет, тот прочтет. Я бы если честно пропустил. Мне интересно ваше менение, а не мнение автора книги. Мнение автора книги я вообще считаю специфичным. Очень тяжело читать его текст. Сразу видно, что перевод.

(10)
Но мне показалось, что Ваш комментарий пытался задеть и, можно даже сказать, оскорбить меня: "Видимо читать и цитировать книги зарубежных авторов намного интереснее. :-)"


Задеть и оскорбить - нет такой цели. Есть цель вызвать эмоциональную реакцию.

П.с. Как сделать лучше? Всю воду в спойлеры. Больше вашего текста и мнения (опыта). Тогда будет интересно.
Lemmonbri; +1 Ответить
11. Lemmonbri 140 27.09.23 11:29 Сейчас в теме
(8) Как то мне показалось, что я слишком уж раскритиковал Ваш комментарий без оснований. На самом деле он для меня очень ценный. Постараюсь в следующих публикациях учитывать замечания!
12. Lemmonbri 140 27.09.23 11:40 Сейчас в теме
(8) Кстати, я вижу Вы опытный человек. Может посмотрите вторую статью? Ссылку добавил.
cheshirshik; +1 Ответить
15. zuxelzz 02.10.23 20:51 Сейчас в теме
Вроде, всю жизнь более привычным был термин "спагетти-код", не? Про макаронный первый раз слышу. Да и не отражает он той сути говнокода, как запутанные друг в друге спагетти.
Ветер в поле; +1 Ответить
16. svezr 5 04.10.23 12:37 Сейчас в теме
Периодически смотрю код типовых решений и наблюдаю несоответствие стандартам разработки от вендора. Более того, складывается ощущение, что качество кода актуальных типовых решений сильно упало за несколько последних лет. Видимо, сменилось поколение:)
Оставьте свое сообщение