Здравствуйте, в этой статье мы постараемся ответить на вопрос: «Логический оператор OR вместо условного оператора». Если у Вас нет времени на чтение или статья не полностью решает Вашу проблему, можете получить онлайн консультацию квалифицированного юриста в форме ниже.
Есть гласное правило для всех программистов – код должен быть лаконичным, хорошо структурированным и понятным для разработчиков, работающих с ним. Проблема в том, что написать такой код с первого раза – очень сложная задача. Каким бы опытным ни был программист, начальство заставит его спешить, заказчики будут менять требования по ходу разработки, а иногда код будет становиться непонятным из-за банального недосыпа. Более того, сами языки программирования регулярно совершенствуются и обретают новые возможности, позволяя заметно сократить количество кода. Поэтому и нужен рефакторинг.
Определение Мартина Фаулера
Вопрос «Что такое рефакторинг?» часто возникает у программистов-новичков, а иногда и у более опытных разработчиков. Поэтому он регулярно всплывает на форумах в духе StackOverflow.
Там в качестве ответа на вопрос приводят цитату из книги «Refactoring: Improving the Design of Existing Code» за авторством Мартина Фаулера:
Рефакторинг – это контролируемая техника совершенствования структуры существующего кода. Суть рефакторинга заключается во внесении серии мелких изменения (с сохранением функциональности приложения), каждое из которых «слишком мелкое, чтобы тратить на него время». Тем не менее эффект от внесения всех этих изменений достаточно ощутимый.
Также в этой книге рекомендуется выполнять рефакторинг пошагово, чтобы исключить появление ошибок. А пользователи StackOverflow советуют каждое изменение сопровождать применением юнит-тестов. И хотя многие отрицают столь тесную связь этих двух операций, большинство опытных кодеров все же не упускают возможности задействовать тесты на любом из этапов разработки или модификации ПО.
Методики рефакторинга
Разработчики и специалисты в области рефакторинга часто называют десятки различных тактик переработки кода, но почти все они четко привязаны к изменяемому компоненту (объекту, функции и т.п.), поэтому нет смысла их все перечислять. Обобщая, есть три основных способа выполнить рефакторинг:
-
Red-Green-Refactor. Это некий аналог «На старт, внимание, марш!». Находим кусок кода для переработки, пишем юнит-тест, переходим к переписыванию.
-
Абстракция. Эта стратегия используется, когда нужно почистить дубликаты. Разработчиками придумываются абстрактные классы или другие классы высокого уровня, чтобы вынести туда повторяющиеся методы.
-
Фрагментация. Стратегия изменения кода с целью увеличить количество компонентов, но сделать сами компоненты меньше. Что-то в духе методик планирования задач, часто применяемых для повышения личной эффективности.
Как видите, рефакторинг – это хоть и простое явление с точки зрения идеи, но необходимое для избежания задержек в разработке и сохранения нервных клеток коллег. Главное – сопровождайте каждый значимый этап рефакторинга тестами, чтобы сохранить «перерабатываемый» код в рабочем состоянии. Также стоит использовать системы контроля версий, каждое новшество отправляя отдельным коммитом в хранилище наподобие GitHub или GitLab. Это поможет в случае чего «откатить» неаккуратный рефакторинг и попытаться снова. Ведь самый понятный и читаемый в мире код все еще должен выполнять свои задачи, а не просто радовать взгляд искушенных кодеров.
Обучиться рефакторингу можно на курсах по программированию общего назначения у EPAM и Hexlet, а также на узкоспециализированных ресурсах в духе Refactoring Guru.
- Обнаружив, что в программу необходимо добавить новую функциональность, но код программы не структурирован удобным для добавления этой функциональности образом, сначала произведите рефакторинг программы, чтобы упростить внесение необходимых изменений, а только потом добавьте функцию.
- Перед началом рефакторинга убедитесь, что располагаете надежным комплектом тестов. Эти тесты должны быть самопроверяющимися.
- При применении рефакторинга программа модифицируется небольшими шагами. Ошибку нетрудно обнаружить.
- Написать код, понятный компьютеру, может каждый, но только хорошие программисты пишут код, понятный людям.
Самый важный урок, который должен преподать данный пример, это ритм рефакторинга: тестирование, малые изменения, тестирование, малые изменения, тестирование, малые изменения. Именно такой ритм делает рефакторинг быстрым и надежным.
При проведении рефакторинга важным предварительным условием является наличие надежных тестов.
Правила разработки тестов
- Делайте все тесты полностью автоматическими, так чтобы они проверяли собственные результаты.
- Комплект тестов служит мощным детектором ошибок, резко сокращающим время их поиска.
- Чаще запускайте тесты. Запускайте тесты при каждой компиляции — каждый тест хотя бы раз в день.
- Получив сообщение об ошибке, начните с создания теста модуля, показывающего эту ошибку.
- Лучше написать и выполнить неполные тесты, чем не выполнить полные тесты.
- Подумайте о граничных условиях, которые могут быть неправильно обработаны, и сосредоточьте на них свои тесты.
- Не забывайте проверять, чтобы в случае возникновения проблем генерировались исключительные ситуации.
- Опасение по поводу того, что тестирование не выявит все ошибки, не должно помешать написанию тестов, которые выявят большинство ошибок.
Проблемы рефакторинга
Изначально понятие рефакторинга (refactoring) сформировалось применительно к Smalltalk, а потом уже концепция постепенно распространилась среди сторонников других языков программирования. Собственно, рефакторинг — это уже неотъемлемый элемент процесса разработки структуры приложений (framework development). Речь идет именно о рефакторинге, когда структурщики работают над иерархией классов и сокращением кодов.
Грамотные специалисты понимают, что слёту хорошую структуру не создать, она совершенствуется в ходе работы, как говорится «на опыте». И еще они знают, что чаще речь идет об улучшении читаемости и модификации старого кода (а не о создании нового). Вот тут и вступает в силу рефакторинг, применимый и для всего ПО, и отдельно для структур (frameworks).
Связаны ли с рефакторингом какие-либо риски? Да, они есть. Дело в том, что анализу и рефакторингу подвергается чистый, уже работающий код, и по ходу дела в нем могут появиться ошибки, на поиск которых потом придется потратить целые дни, а то и недели. Еще хуже, когда рефакторинг проводится бессистемно и без соблюдения формальностей.
Целесообразность применения рефакторинга
Рефакторинг бывает двух вариантов: запланированный либо проводящийся по мере надобности.
Плановый – это тот, для которого в цикле разработки изначально заложено необходимое время. К примеру, он будет выполняться раз в полгода, или после каждых четырех спринтов.
Крупные компании часто создают специальные группы, работа которых состоит исключительно в рефакторинге старых кодов (легаси-кода в больших фирмах обычно много). После этого они становятся более понятными и простыми в использовании для других сотрудников.
Второй вариант – рефакторинг по мере надобности. Это когда необходимо внести в код новые возможности, но они плохо интегрируются со старыми. Тогда приходится их пересматривать и реорганизовывать.
Когда не стоит заниматься рефакторингом кода
Несмотря на всю пользу рефакторинга, применять его стоит не всегда. К примеру, если вы разрабатываете маленький и несложный продукт, развитие которого идет очень медленно. В таком случае править код может и не понадобиться. Хотя, конечно, лучше соблюдать порядок в любых проектах.
Также от рефакторингов можно отказаться при приближении дедлайна. Эффективность этой процедуры чувствуется лишь со временем, поэтому, если вы начнете рефакторить код перед самой сдачей проекта, заметного роста производительности не произойдет, а значит, вы впустую потратите время. Польза рефакторинга именно в том, что после него становится легче работать с существующим продуктом. Если делать этого больше не нужно — не нужен и рефакторинг.
Еще один пример — ситуация, когда проще переписать код с нуля, чем разбираться в нем. Рефакторинг — не панацея. Иногда распутывать безнадежный клубок из программных строк слишком долго и затратно. Быстрее и эффективнее написать все заново.
Важные моменты при рефакторинге
Как понять, был ли рефакторинг успешным? Да, если в результате код стал более чистым, простым и понятным.
К примеру, если переменная А отвечает за число покупателей, то желательно назвать ее customerCount – это облегчит понимание кода.
Если фрагмен используется несколько раз, его стоит оформить, как отдельную функцию/метод. Так будет проще в дальнейшем вносить изменения – обновить одно место, а не искать одинаковые фрагменты по всем строкам.
Для лучшей читаемости кода большие функции, которые не помещаются целиком на экране, разбивают на несколько менее объемных. Иногда часть функций вообще переносят в отдельный файл, а затем присоединяют его к коду.
Нужно понимать, что рефакторинг – это не синоним оптимизации. Его цель – сделать код понятнее, а оптимизация нужна для ускорения и улучшения эффективности программы.
Демонстрация результатов рефакторинга
Несмотря на то, что рефакторинг ведется на уровне кода (под капотом), как и для любой другой пользовательской истории, команды должны иметь возможность продемонстрировать результаты.
Если брать пример выше, то команды могли бы это сделать так:
- Уменьшено время обработки на нескольких веб-страницах по сравнению с предыдущим эталонным тестом.
- Понятна зависимость времени обработки от размера пакета, который теперь можно прочитать из файла.
- Есть сниппет кода кода для возможности асинхронной обработки.
- Есть файл логирования, в котором фиксируются все операции.
- Количество запросов к словарям из расчета на один пакет (по статистике из лога).
Ресурсы для дополнительного погружения в рефакторинг
Самая известная книга о рефакторинге — это “Рефакторинг. Улучшение проекта существующего кода” Мартина Фаулера. Также есть интересное издание о рефакторинге, написанное на основе предыдущей книги — “Рефакторинг с использованием шаблонов” Джошуа Кириевски. Кстати о шаблонах. При рефакторинге всегда очень полезно знать основные паттерны проектирования приложений. В этом помогут эти отличные книги:
- “Паттерны проектирования” — авторства Эрика Фримена, Элизабет Фримен, Кэтти Сьерра, Берта Бейтса из серии Head First;
- “Читаемый код, или программирование как искусство” — Дастин Босуэлл, Тревор Фаучер.
- “Совершенный код” Стива Макконнелла, в которой изложены принципы красивого и элегантного кода.
Как понять, что проекту нужен рефакторинг
Заказчику стоит задуматься о рефакторинге, если:
- проект работает, но медленнее обычного, часто случаются сбои;
- даже небольшие правки затягиваются по времени;
- разработчики не могут оценить объем задач, поскольку говорят о том, что сначала нужно разобраться;
- при выгрузке изменений в релиз часто встречают баги.
Для разработчика «красные флаги», сигнализирующие о необходимости чистки кода будут такими:
- дублирование кода;
- длинные или ресурсоемкие методы;
- большие классы;
- несгруппированные данные;
- длинные списки параметров;
- избыточные переменные;
- если понимание кода занимает много времени. Иногда код может быть написан с соблюдением принципов DRY и KISS, но работа кода всё-равно остается непонятной разработчикам. Здесь стоит задуматься о смене паттернов проектирования и проектировании другой модели абстракции. Часто помогает и переименование переменных по рекомендациям Мартина Фаулера.
В рамках рефакторинга проводятся, на первый взгляд, элементарные работы:
- перемещение поля из одного класса в другой;
- вынесение фрагмента кода из метода в самостоятельный метод;
- перемещение кода по иерархии классов.
Использование метрик позволяет вам расставить приоритеты для основных действий по исправлению, которые вам действительно нужно внести в свой код. Это не дает вам делать все сразу и заставляет фокусироваться в первую очередь на самых важных задачах.
Кроме того, вам нужны метрики, чтобы оценить эффективность рефакторинга исходного кода — речь идет не только об изменении неэффективного кода, но и об изменении неэффективного кода для добавления ценности. Чтобы понять реальную ценность, вам нужны тесты, как модульные (например, количество неудачных модульных тестов), так и функциональные. Другие показатели могут включать меньшее количество ошибок и снижение цикломатической сложности — рефакторинг должен быть направлен на снижение сложности. Методы или функции с высокой сложностью (например, более 350 строк) являются хорошими целями для рефакторинга.
Также стоит подумать о том, как рефакторинг соотносится с более широкими целями или этапами команды в отношении рабочего процесса и задач. В метрики нужно включать меньший размер кода и более понятный код.
На что смотрят при рефакторинге кода
Главный показатель успешного рефакторинга — после него код стал чище, проще и понятнее.
Например, если переменная Z в программе отвечает за количество покупателей, то лучше её заменить на customerCount — так будет проще разобраться в коде и понять, что там происходит.
Если фрагмент кода повторяется больше одного раза, то его чаще всего выносят в отдельную функцию или метод. В этом случае будет легче заменить код в одном месте, чем искать повторяющиеся фрагменты по всей программе.
Ещё программисты обращают внимание на размер функций, методов и классов. Если функция получается слишком большой, чтобы поместиться на одном экране, — её разбивают на две, чтобы упростить читаемость кода.
Иногда, чтобы сделать код проще, разработчики выносят часть функций в отдельный файл и подключают его к основной программе.
Как избежать рефакторинга?
Скажу сразу: никак. В быстро развивающихся проектах это невозможно по причине того, что разработка очень динамичная, и согласованием архитектуры, написанием документации и тщательной технической проработкой задач зачастую пренебрегают. Как следствие, создается много низкосортного кода, «некрасивых» временных решений (которые потом становятся целевыми, ибо «работает – не трогай») и нелогичных решений, в которых последующие поколения разработчиков и аналитиков уже не могут разобраться. В проектах, где сроки терпят и могут смещаться месяцами (как правило, это крупные долгоиграющие проекты в банках, страховых и т.п.) времени, ресурсов и экспертизы на тщательное проектирование выделено больше, но здесь мешает масштаб проектов и организации. Слишком много команд работают в одном системном пространстве, их интересы зачастую не пересекаются, поэтому в разработку друг друга команды заглядывают лишь одним глазом, да и коммуникации между такими командами не всегда работают. Как итог – у каждого свой велосипед, потому что либо «не знали, что у соседей такой же велосипед, и поехать можно на нём», либо «знали, но решили на него не садиться, вдруг он сломается и тогда не доедет никто».
Таким образом, рефакторинг нужно время от времени проводить в любом проекте. Ниже приведено несколько советов, как провести рефакторинг не в ущерб текущим проектным задачам, а также что делать, чтобы минимизировать технический долг и тратить на его устранение меньше ресурсов.
Рефакторинг и оптимизация программного кода.
Истинно оптимальная система в процессе оптимизации достигается далеко не всегда. Оптимизированная система обычно является оптимальной только для одной задачи или группы пользователей. Как правило, процесс оптимизации завершается до того, как достигается полная оптимальность.
«Преждевременная оптимизация — это корень всех бед». Очень важно иметь для начала озвученный алгоритм и работающий прототип.
Понятие «оптимизация» обычно подразумевает, что система сохраняет ту же самую функциональность. Однако, значительное улучшение производительности часто может быть достигнуто и с помощью удаления избыточной функциональности.
Оптимизация в основном фокусируется на одиночном или повторном времени выполнения, использовании памяти, дискового пространства, пропускной способности или некотором другом ресурсе. Это обычно требует компромиссов — один параметр оптимизируется за счёт других.
В программировании, оптимизация обычно обозначает модификацию кода и его установок компиляции для данной архитектуры для производства более эффективного ПО.
Для оптимизации требуется найти узкое место (англ. hotspot): критическую часть кода, которая является основным потребителем необходимого ресурса. Улучшение примерно 20 % кода иногда влечёт за собой изменение 80 % результатов. Для поиска узких мест используются специальные программы — профайлеры.
Чем больше памяти использует программа, тем быстрее она обычно выполняется.
Простейшие приёмы оптимизации:
— Инициализация объектов данных (Правильная инициализация объектов позволяет сэкономить процессорное время.)
— Программирование арифметических операций(самыми быстрыми являются операции сложения и вычитания. Более медленным является умножение, затем идёт деление)
Приоритеты оптимизации:
• интерфейсный, т.е. желательно заранее ВСЁ согласовать с другими участниками проекта, включая кому сколько процессорного времени на конкретном ПК.
• Если ПК не является современным и многопроцессорным, заведомо сильно ограничить суммарный CPU расход, можно утилитами типа slowcpu.
Рефакторинг — процесс изменения внутренней структуры программы, не затрагивающий её внешнего поведения и имеющий целью облегчить понимание её работы[1]. В основе рефакторинга лежит последовательность небольших эквивалентных (то есть сохраняющих поведение) преобразований.
Цель рефакторинга — сделать код программы легче для понимания.
Рефакторинг следует отличать от оптимизации производительности. Как и рефакторинг, оптимизация обычно не изменяет поведение программы, а только ускоряет ее работу. Но оптимизация часто затрудняет понимание кода, что противоположно рефакторингу[2].
Основные стимулы его проведения являются следующие задачи:
— необходимо добавить новую функцию, которая недостаточно укладывается в принятое архитектурное решение;
— необходимо исправить ошибку, причины возникновения которой сразу не ясны;
Сборка, внедрение и поставка ПО
Средство создания дистрибутивов мы будем называть инсталлятор. Под словом дистрибутив понимаем распространяемые файлы программы — обычно это Setup.exe плюс, возможно, еще несколько файлов.
Bootstrapper. Эта часть программы установки запускается первой и ее задача — подготовить все необходимое для работы installation engine. В частности, в случае использования Windows Installer, bootstrapper обеспечивает установку или обновление Windows Installer до требуемой версии.