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

06.10.23

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

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

Скачать файл

ВНИМАНИЕ: Файлы из Базы знаний - это исходный код разработки. Это примеры решения задач, шаблоны, заготовки, "строительные материалы" для учетной системы. Файлы ориентированы на специалистов 1С, которые могут разобраться в коде и оптимизировать программу для запуска в базе данных. Гарантии работоспособности нет. Возврата нет. Технической поддержки нет.

Наименование По подписке [?] Купить один файл
Рефакторинг кода
.zip 318,90Kb
13
13 Скачать (1 SM) Купить за 1 850 руб.

Введение

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

 

Ссылки

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

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

 

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

Комментарии

К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: Имена должны описывать побочные эффекты

 

Для чего файл

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

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

См. также

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

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

16.09.2024    14165    markbraer    64    

39

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

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

10.09.2024    926    acces969    4    

6

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

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

28.08.2024    1178    Chernazem    3    

6

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

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

22.08.2024    10268    alex_sayan    41    

52

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

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

25.06.2024    4234    MadRave    34    

27

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

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

1 стартмани

04.06.2024    6288    mrXoxot    55    

42

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

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

10.04.2024    13390    artbear    85    

108

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

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

01.04.2024    4264    DrAku1a    15    

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

Такие камменты прямо очень помогают для обновления. Это своего рода акт программистской вежливости и заботы о других
2. Lemmonbri 142 06.10.23 16:29 Сейчас в теме
(1) Для этого расширения есть.
DrAku1a; sandr13; +2 Ответить
3. sandr13 35 07.10.23 09:29 Сейчас в теме
(2) Жаль журналов в них нет
5. DrAku1a 1745 16.10.23 05:20 Сейчас в теме
(1) Мне больше понравился стиль:
//ит Вася Пупкин 2008-05-02 (#000000065) вниз
//ит Вася Пупкин 2008-05-02 (#000000065) вверх
где
ит = Префикс изменений организации/ИТ-команды
Вася Пупкин - автор
2005-05-02 - дата
#000000065 - номер тикета/задачи в "тетрадке у Чуня" системе учета задач
вниз / вверх - направление, куда смотреть относительно текущей строки (вместо начало / конец)
6. Serg O. 297 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 35 07.10.23 09:29 Сейчас в теме
Спасибо за чек лист. Плюсую.
Оставьте свое сообщение