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

06.10.23

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

Чек-лист для простого и быстрого проведения рефакторинга кода.

Скачать исходный код

Наименование Файл Версия Размер
Рефакторинг кода
.zip 318,90Kb
9
.zip 318,90Kb 9 Скачать

Введение

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

 

Ссылки

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

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

 

Сводка правил, чек лист

Комментарии

К1: Неуместная информация

В комментариях неуместно размещать информацию, которую удобнее хранить в других источниках.

К2: Устаревший комментарий

К3: Избыточный комментарий

К4: Плохо написанный комментарий (непонятный, не поясняющий)

К5: Закомментированный код

 

Функции

Ф1: Слишком много аргументов

Ф2: Выходные аргументы в методах (используйте возврат)

Ф3: Флаги в аргументах в методах (больше 1 действия в методе)

Ф4: Мертвые функции (не вызывающиеся нигде)

 

Разное

Р1: Некорректное граничное поведение

Р2: Очевидное поведение не реализовано

Р3: Дублирование

Р4: Код на неверном уровне абстракции

Р5: Слишком много информации

Чем меньше экспортных методов – тем проще программный интерфейс. Минимум экспортных методов для максимум эффективности.

Р6: Мертвый код (не выполняется в теле программы)

Р7: Вертикальное разделение

Р8: Непоследовательность

Если некая операция выполняется определенным образом, то и все похожие операции должны выполняться так же.

Р9: Балласт (Мусор, неисполняемый код, неиспользуемые переменные)

Р10: Непонятные намерения

Р11: Используйте пояснительные переменные

Р12: Имена функций должны описывать выполняемую операцию

Р13: Понимание алгоритма

Очень много странного кода пишется из-за того, что люди не утруждают себя пониманием алгоритмов.

Р14: Заменяйте «волшебные числа» именованными константами и переменными

Р15: Будьте точны

Наивно ожидать, что первая запись, возвращаемая по запросу, является единственной и подобное.

Р16: Инкапсулируйте условные конструкции

Выделяйте сложные условия в отдельные методы.

Р17: Функции должны выполнять одну операцию

 

Имена

И1: Используйте содержательные имена

И2: Выбирайте имена на подходящем уровне абстракции

И3: По возможности используйте принятые в отрасли термины

И4: Недвусмысленные имена

И5: Используйте длинные имена для длинных областей видимости

И6: Избегайте кодирования

И7: Имена должны описывать побочные эффекты

 

Для чего файл

В файле находится полный текст всех статей + чек-лист с комментариями. Именно этот файл мы используем для подготовки специалистов и проведения рефакторинга. Если хотите поддержать автора - можете приобрести файл.

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

См. также

Результаты ревью кода 1500+ решений каталога Инфостарт: наиболее частые ошибки разработчиков в коде

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

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

10.04.2024    6755    artbear    84    

81

Ниндзя-код

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

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

01.04.2024    2446    DrAku1a    15    

33

Практическое программирование: когда скорость важнее совершенства

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

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

01.04.2024    641    Prepod2003    6    

2

Когда понадобился новый оператор

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

Когда понадобился новый оператор, но его нет в синтакс-помощнике, что делать?

18.03.2024    1376    ZhokhovM    4    

4

Когда разработчик платформы не добавил проверку препроцессоров

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

Когда разработчик платформы решил пойти на кухню за кофе, а проверку препроцессоров не добавил, и вот тут-то и началось: "Что, опять все сломалось? Ну и кофе же я забыл сделать!".😅

18.03.2024    3055    ZhokhovM    4    

9

Реструктуризация - бесконечная история

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

При разработке программ требуемый функционал ставят на первое место, но есть еще и архитектура программы. На горизонте 5-10 лет она становится важнее функционала, который должен работать при масштабировании и росте данных. Реструктуризация 5 терабайтной базы 1С 8.2 в формат 1С 8.3, складывает весь пазл архитектурных просчетов, которые сделали ради функционала. Как это исправить? - для разработки правильной архитектуры, нужно всего лишь сместить фокус с функционала и подумать о «вечном».

29.09.2023    2130    1CUnlimited    15    

23

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

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

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

27.09.2023    7227    Lemmonbri    136    

37
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. lev6975 06.10.23 14:42 Сейчас в теме
Кстати, по поводу камментов описания функций и модулей в шапке перед функцией бытует мнение что они вообще излишни потому что очень быстро устаревают ну и как бы мешают читать код. И вообще от камментов нужно отходить по возможности совсем в пользу более грамотного написания кода и названия переменных и методов. Но я с ними не согласен В 1С без этого сильно никак - то же обновление внедренной программистом не знакомым с конфой. Он тучу времени потратит на то чтобы понять где код 1С - ный а где внедренный, поскольку зачастую обновления проводят небрежно для экономии времени просто "снимая галочки" с конфликтных объектов, не удаляя старые объекты (галочка "Разрешить удаление объектов" снята), и сравнение с конфой поставщика тут не работает, стравнивать придется с кучей цф - ников поставщика всех прошлых релизов. К нам такая база поступила, вся переписанная и обновленная кое - как, плюс еще и конфа поставщика не обновлена была несколько раз, помучились знатно... поэтому программисты часто оставляют метки типа:
//Вася Пупкин Начало 02.05.2008
//Вася Пупкин Конец 02.05.2008

Такие камменты прямо очень помогают для обновления. Это своего рода акт программистской вежливости и заботы о других
2. Lemmonbri 120 06.10.23 16:29 Сейчас в теме
(1) Для этого расширения есть.
DrAku1a; sandr13; +2 Ответить
3. sandr13 34 07.10.23 09:29 Сейчас в теме
(2) Жаль журналов в них нет
5. DrAku1a 1718 16.10.23 05:20 Сейчас в теме
(1) Мне больше понравился стиль:
//ит Вася Пупкин 2008-05-02 (#000000065) вниз
//ит Вася Пупкин 2008-05-02 (#000000065) вверх
где
ит = Префикс изменений организации/ИТ-команды
Вася Пупкин - автор
2005-05-02 - дата
#000000065 - номер тикета/задачи в "тетрадке у Чуня" системе учета задач
вниз / вверх - направление, куда смотреть относительно текущей строки (вместо начало / конец)
6. Serg O. 265 19.10.23 10:55 Сейчас в теме
(5) некоторые комментарии
1) после // нужен "пробел" - см. Соглашения при написании кода: Тексты модулей, пункт 7.3
при использовании Visual Studio Code - "дефект кода"
Phoenix BSL - так же показывает это как Информацию

2) дату лучше в "нормальном" написании использовать 02.05.2008 (главное одинаково для всех команды)

3) скобки у номера задачи - не нужны - вместо (#000000065) достаточно #65

4) вниз - вверх не очень понятно что и зачем так писать, лучше +++( в начале и ---) в конце для блока изменений ( и в конце уже дату и номер задачи можно не писать, она "врёт" потому что бывают изменения внутри изменений!)

т.е. из вашего примера получается более лаконичный

 // +++( ИТ Вася Пупкин 02.05.2008 #65

// ... Код изменения

// ---) ИТ Вася Пупкин 


а если меняется только 1 строка / условие / цикл - то вообще лучше 1 раз комментарий в конце строки
Соглашения при написании кода: Тексты модулей, пункт 7.2

 Если Количество > 0 Тогда // ИТ Вася Пупкин 02.05.2008 #65
// ... Код
КонецЕсли; 
4. sandr13 34 07.10.23 09:29 Сейчас в теме
Спасибо за чек лист. Плюсую.
Оставьте свое сообщение