Что такое модифицировать программу

Программы для ЭВМ являются объектами авторских прав и охраняются как литературные произведения (п. 1 ст. 1259 ГК РФ). Это значит, что создателю программного обеспечения принадлежат, в частности (п. п. 2, 3 ст. 1255 ГК РФ):

• исключительное право на программу. Его можно передать другому лицу или разрешить использовать программу по лицензии, в том числе исключительной (п. 1 ст. 1233, п. 1 ст. 1236, п. 1 ст. 1270 ГК РФ);

• право авторства и право автора на имя. То есть право признаваться автором и использовать или разрешать использование произведения под своим именем, псевдонимом или анонимно. Эти права неотчуждаемы и непередаваемы. Они остаются у автора, даже если другому лицу передается (переходит) исключительное право на произведение или предоставляется право использования произведения.

От них нельзя отказаться (п. 1 ст. 1265 ГК РФ);

• право на неприкосновенность произведения. Это, в частности, значит, что без согласия автора нельзя менять, сокращать и дополнять произведение (п. 1 ст. 1266 ГК РФ). Гражданский кодекс РФ не предусматривает возможность отчуждения этого права;

МОЖНО ЛИ ИЗМЕНИТЬ НАРЦИССА/ЖИВУ С ОДНИМ-ЛЮБЛЮ ДРУГОГО/ОТВЕТИМ 14 ИЮЛЯ В ПРЯМОМ ЭФИРЕ

• право на обнародование произведения, то есть право впервые сделать произведение доступным для всеобщего сведения любым способом или дать согласие на такие действия (п. 1 ст. 1268 ГК РФ). Гражданский кодекс РФ также не указывает, что это право можно передать другому лицу;

• право на вознаграждение за создание служебного произведения (п. п. 2, 3 ст. 1295 ГК РФ). Это право неотчуждаемо в силу прямого указания закона (п. 2 ст. 1295 ГК РФ).

Учтите, что у автора программы нет некоторых прав, которые могут быть у создателей литературных и других произведений, например:

• права на отзыв. Это значит, что он не может отказаться от принятого ранее решения обнародовать программу (ст. 1269 ГК РФ);

• права следования, то есть права на получение процентных отчислений от цены перепродажи оригинала произведения. Такое право возникает лишь при перепродаже произведений изобразительного искусства, а также авторских рукописей (автографов) литературных и музыкальных произведений (п. п. 1, 2 ст. 1293 ГК РФ).

Однако в ГК РФ отсутствуют нормы, которые содержали бы более детальные правила в отношении модификации программ, а также позволяли бы определить реальное намерение законодателя по этому вопросу.

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

Фабула этих дел всегда одинакова и выглядит следующим образом. Истец подает иск о нарушении прав на программу для ЭВМ, правообладателем которой он является. Как правило, ответчик не использует программу, абсолютно идентичную той, которая принадлежит истцу. Даже если по сути это та же программа, на рынке или в хозяйственной деятельности она позиционируется иначе (она может иметь иное коммерческое название, другой интерфейс и так далее). Поэтому получается, что суд должен установить, та ли это программа, о принадлежности прав на которую заявляет ответчик.

Как изменить программы мозга и убеждения других людей?

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

Суд по интеллектуальным правам отменил эти решения. И хотя иск был подан о незаконном воспроизведении, Суд по интеллектуальным правам высказал важную для рассматриваемого вопроса правовую позицию: «Кроме того, суд первой инстанции, приходя к выводу о том, что использование программы произведено ответчиком исключительно в целях адаптирования работы оборудования к условиям расположения садового некоммерческого товарищества, не принял во внимание, что в соответствии с подпунктом 9 пункта 2 статьи 1270 ГК РФ адаптация, то есть внесение изменений, осуществляемых исключительно в целях функционирования программы для ЭВМ или базы данных на конкретных технических средствах пользователя или под управлением конкретных программ пользователя, не является нарушением исключительного права на программу для ЭВМ».

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

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

Такой показатель, как процент переработки кода зачастую используется в делах о нарушениях не как аргумент в пользу существенности изменений и наличия модификации, а как аргумент в пользу того, что право на программу нарушено, о чем свидетельствует большой процент заимствований. В качестве примера можно привести спор между компаниями ООО «Дата МАТРИКС» и ООО «ДатаФлоу Солюшенс». Спор был о нарушении прав истца посредством использования ответчиком его программы при разработке собственной. Исход этого дела был решен в пользу истца на том основании, что процент совпадений кода в программах истца и ответчика составлял 88%, а программа истца являлась исходной.

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

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

Вероятно, самым интересным делом, в котором суды (как нижестоящих инстанций, так и Суд по интеллектуальным правам) отмечали существенность функциональных изменений, является спор между ОАО «Челябинский трубопрокатный завод» (ЧТПЗ, истец) и ООО «Малахит» (ответчик). Истец подал иск в связи с тем, что ответчик использовал в своей деятельности программу, которую до этого доработал по договору с ответчиком. Предметом доработки была программа, права на которую изначально принадлежали ответчику, при этом договор не предусматривал переход прав на исходную программу к заказчику. Истец утверждал, что в результате доработки была создана новая программа, права на эту новую программу принадлежат истцу, а, значит, ответчик эту программу использовать не может. Ответчик утверждал, что в результате работ по договору не была создана новая программа, поскольку доработки были незначительными и по своему содержанию являлись адаптацией, а используемая им программа — это та программа, правообладателем которой он является, хотя она и была адаптирована для истца.

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

Основным индикатором существенности переработок были именно изменения функций и создание новых алгоритмов решения задач. При назначении экспертизы по данному делу было раскрыто понятие модификации, на которое должны были ориентироваться эксперты: «Под модификацией понимается изменение функциональности программы, появление новых свойств и возможностей программы, автоматизация неавтоматизированных ранее ручных операций, иные доработки, выходящие за пределы адаптации программы для ЭВМ (пп. 9 п. 2 ст. 1270 ГК РФ) и описанные в документации». И этот факт, и в целом исследование судами отдельных видов работ для их отнесения к модификации или адаптации — заслуживают позитивной оценки.

Если подводить какие-то итоги всему вышесказанному, то можно сформулировать следующие предложения:

1. В ГК РФ необходимо внести изменения применительно не только к термину «переработка», но и в целом применительно к способам использования программ.

В частности, необходимо развести следующие три способа использования программ:

а) использование, которое воспроизводит значительные части программы без существенных изменений, должно быть отнесено к воспроизведению (для этих целей можно установить некий числовой показатель процента совпадений);

б) использование программы, которое является достаточно творческим и существенным, чтобы в результате создавалась новая программа, следует называть переработкой;

в) использование, которое не является переработкой или воспроизведением, поскольку используются не очень существенные (в числовых показателях) части исходной программы, но охраняемые части, использование которых требует получения лицензии, поскольку используется охраняемый элемент (материал) — это аналог использования части произведения.

2. В качестве критериев модификации могут использоваться изменения функционала и процент переработки кода.

3. Сложнее всего будет разработать положения, относящиеся к третьему способу использования. Поскольку нужно будет предусмотреть, какие элементы можно считать охраняемыми и как дополнять ст. 1261 ГК РФ, что потребует детального погружения не только в юридические, но также и в технические аспекты.

Публикация подготовлена при поддержке юристов DRC.

Источник: vc.ru

7.8 Модификация программного обеспечения

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

Примечание — В настоящем стандарте программное обеспечение (в отличие от аппаратного обеспечения) не может поддерживаться, оно всегда модифицируется.

7.8.2 Требования

7.8.2.1 Перед выполнением какой-либо модификации программного обеспечения должны быть подготовлены процедуры модификации (МЭК 61508-1, пункт 7.16).

1 Требования 7.8.2.1-7.8.2.9 относятся, в первую очередь, к изменениям, выполняемым на этапе работы программного обеспечения. Они могут также применяться во время интеграции программируемой электроники, а также во время общей установки и ввода в эксплуатацию (МЭК 61508-1, пункт 7.13).

2 Пример модели процедуры модификации приведен в МЭК 61508-1 (рисунок 9).

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

a) об опасностях, на которые могут повлиять изменения;

b) о предлагаемых изменениях;

c) о причинах изменений.

Примечание — Причины появления запроса на модификацию могут быть, например, связаны с:

— тем, что функциональная безопасность оказалась ниже той, которая была определена в спецификациях;

— появлением нового или изменением действующего законодательства, относящегося к безопасности;

— модификацией EUC или способа его использования;

— модификацией общих требований к безопасности;

— анализом характеристик работы и обслуживания, который показывает, что эти характеристики имеют значения ниже запланированных;

— текущим аудитом функциональной безопасности.

7.8.2.3 Должен быть выполнен анализ влияния предлагаемых модификаций программного обеспечения на функциональную безопасность Е/Е/РЕ систем, связанных с безопасностью:

a) определить, необходим или нет анализ рисков;

b) определить, какие фазы жизненного цикла модулей безопасности следует повторить.

7.8.2.4 Результаты анализа влияния, полученные в 7.8.2.3, должны быть документированы.

7.8.2.5 Все модификации, оказывающие влияние на функциональную безопасность Е/Е/РЕ систем, связанных с безопасностью, должны приводить к возврату на соответствующую стадию жизненного цикла модулей безопасности. Все последующие стадии должны выполняться в соответствии с процедурами, определенными для отдельных стадий в соответствии с требованиями настоящего стандарта. При планировании безопасности (см. раздел 6) должны быть подробно описаны все последующие процессы.

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

7.8.2.6 Планирование безопасности для модификации программного обеспечения, связанного с безопасностью, должно включать в себя следующую информацию:

a) идентификацию персонала и определение требований к его квалификации;

b) подробную спецификацию модификации;

c) планирование верификации;

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

7.8.2.7 Модификация должна быть выполнена в соответствии с разработанным планом.

7.8.2.8 Все модификации должны быть подробно документированы, включая:

a) запрос на модификацию/корректировку;

b) результаты анализа влияния, которое окажут предлагаемые модификации программного обеспечения на функциональную безопасность, и принятые решения с их обоснованием;

c) сведения об изменениях конфигурации программного обеспечения;

d) отклонения от нормальной работы и нормальных условий работы;

e) все документы, которые затрагиваются процессами модификации.

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

Примечание — Требования 7.8.2.1-7.8.2.9 относятся, в первую очередь, к изменениям, выполняемым на этапе работы программного обеспечения. Они могут также применяться во время интеграции программируемой электроники, а также во время общей установки и ввода в эксплуатацию (МЭК 61508-1, пункт 7.13).

7.8.2.10 Оценка необходимых модификаций или корректировок должна зависеть от результатов анализа влияния модификаций и уровня полноты безопасности программного обеспечения.

Источник: studfile.net

Что такое рефакторинг кода?

Концепция «рефакторинга» возникла в кругах, связанных со Smalltalk, но вскоре нашла себе дорогу и в лагеря приверженцев других языков программирования. Поскольку рефакторинг является составной частью разработки структуры приложений (framework development), этот термин сразу появляется, когда «структурщики» начинают обсуждать свои дела.

Он возникает, когда они уточняют свои иерархии классов и восторгаются тем, на сколько строк им удалось сократить код. Структурщики знают, что хорошую структуру удается создать не сразу — она должна развиваться по мере накопления опыта. Им также известно, что чаще приходится читать и модифицировать код, а не писать новый. В основе поддержки читаемости и модифицируемости кода лежит рефакторинг — как в частном случае структур (frameworks), так и для программного обеспечения в целом.

Так в чем проблема? Только в том, что с рефакторингом связан известный риск. Он требует внести изменения в работающий код, что может привести к появлению трудно находимых ошибок в программе. Неправильно осуществляя рефакторинг, можно потерять дни и даже недели. Еще большим риском чреват рефакторинг, осуществляемый без формальностей или эпизодически.

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

В книге «Design Patterns» сообщается, что проектные модели создают целевые объекты для рефакторинга. Однако указать цель — лишь одна часть задачи; преобразовать код так, чтобы достичь этой цели, — другая проблема.

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

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

Что такое рефакторинг?

Рефакторинг или реорганизация кода — процесс изменения внутренней структуры программного продукта, не затрагивающий её внешнего поведения и имеющий целью облегчение понимания программного кода и, пусть и не всегда, оптимизацию производительности.

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

«Улучшение кода после его написания» — непривычная фигура речи. В нашем сегодняшнем понимании разработки программного обеспечения мы сначала создаем дизайн системы, а потом пишем код. Сначала создается хороший дизайн, а затем происходит кодирование. Со временем код модифицируется, и целостность системы, соответствие ее структуры изначально созданному дизайну постепенно ухудшаются. Код медленно сползает от проектирования к хакерству.

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

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

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

Правила рефакторинга

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

Самый важный урок, который должен преподать данный пример, это ритм рефакторинга: тестирование, малые изменения, тестирование, малые изменения, тестирование, малые изменения. Именно такой ритм делает рефакторинг быстрым и надежным.

Принципы рефакторинга

Рефакторинг (Refactoring): изменение во внутренней структуре программного обеспечения, имеющее целью облегчить понимание его работы и упростить модификацию, не затрагивая наблюдаемого поведения.

Производить рефакторинг (Refactor): изменять структуру программного обеспечения, применяя ряд рефакторингов, не затрагивая его поведения.

Рефакторинг не меняет видимого поведения программного обеспечения. Оно продолжает выполнять прежние функции. Никто — ни конечный

Без рефакторинга не обходится ни один действительно сложный и долгоживущий проект

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

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

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

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

Наиболее частые причины для рефакторинга:

• дублирование кода;
• длинные методы;
• объёмные классы;
• длинные списки параметров;
• избыточные временные переменные;
• классы данных;
• несгруппированные данные;
• несоблюдение стандартов кодирования.

Когда следует проводить рефакторинг?

В жизни каждой программы, по крайней мере, в жизни тех, что разрабатываются на заказ, наступает этап, когда основные функциональные требования заказчика, по мнению разработчика, выполнены, и программный продукт поступает на тестирование. А может быть даже в опытную эксплуатацию. В ходе тестирования, если у того, кто его проводит, руки растут из нужного места и мозги работают в правильном направлении, на разработчика начинает валиться большое число bug-ов, связанных с исключительными ситуациями, “защитой от дурака”, экстремальными объемами данных, неприемлемым быстродействием и так далее (идеально работающие программы сразу не пишутся). Разработчик старается быстро реагировать на вызовы судьбы и вносит большое количество локальных исправлений, а иногда и “заплат”, вследствие чего код теряет первоначальную стройность и сбалансированность. Вот в моменты между основными волнами наплывов претензий со стороны отдела технического контроля или просто ОТК и следует проводить рефакторинг кода: анализировать код и, используя ряд эффективных приемов, преобразовывать его к более согласованному и “прозрачному виду.” Естественно, что этап рефакторинга нельзя считать однократным.

Также, уместно проводить рефакторинг кода после добавления новой функциональности, поскольку такие действия легко могут привести к необходимости провести ряд преобразований, связанных с манипуляцией классами и их элементами. Довольно часто новая функциональность является причиной извлечения новых методов или даже новых классов и/или переименования их, поскольку роль последних может быть расширена, уточнена или специализирована.

Как мне кажется, отдельного внимания, помимо прочих, должны быть удостоены и те части кода, которые давно не редактировались (не были затронуты в процессе исправления ошибок или расширения функциональности), поскольку вряд ли они настолько невосприимчивы к вносимым вами изменениям, хотя и сохраняют корректное поведение. Но это уже ответ скорее не на вопрос “Когда уместно…”, а на вопрос “Где искать…”

Почему рефакторинг приносит результаты

Из-за чего бывает трудно работать с программами? Есть, как минимум, 4 причины:

1. Программы, трудные для чтения, трудно модифицировать.
2. Программы, в логике которых есть дублирование, трудно модифицировать.
3. Программы, которым нужны дополнительные функции, что требует изменений в работающем коде, трудно модифицировать.
4. Программы, реализующие сложную логику условных операторов, трудно модифицировать.

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

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

Когда рефакторинг не нужен?

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

Явный признак необходимости переписать код — его неработоспособность. Это обнаруживается только при его тестировании, когда ошибок оказывается так много, что сделать код устойчивым не удается. Помните, что перед началом рефакторинга код должен выполняться в основном корректно.

Другой случай, когда следует воздерживаться от рефакторинга, это близость даты завершения проекта. Рост производительности, достигаемый благодаря рефакторингу, проявит себя слишком поздно — после истечения срока. Правильна в этом смысле точка зрения Уорда Каннингема (Ward Cunningham). Незавершенный рефакторинг он сравнивает с залезанием в долги.

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

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

Рефакторинг vs Реинжиниринг?

Если рефакторинг кода не меняет поведения программы, то реинжиниринг на такое способен. Можно рассматривать реинжиниринг, как крайнюю форму рефакторинга, но мне кажется, что это не вполне корректно. Скорее, рефактиринг может стать причиной легкого реинжиниринга. Рассмотрим вариант, когда периодический рефакторинг в процессе интенсивного тестирования программного продукта может привести к реинженирингу:

Специалисты ОТК, а возможно, уже и пользователи (зависит от этапа жизненного цикла программного продукта) постоянно регистрируют ошибки, непосредственно связанные с особенностью принятых вами решений при проектировании программы. Возможно, вы некорректно выбрали шаблон проектирования в процессе разработки архитектуры вашей программы. Инспекция кода и периодический рефакторинг могут выявить такие места – они выглядят громоздкими, нелогичными и не поддаются общеизвестным правилам рефакторинга. Вы принимаете решение внести изменения в архитектуру программы, оцениваете последствия и грядущие изменения в ее поведении, согласуете и объявляете о планируемых изменениях и приступаете к реинжинирингу.

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

Рефакторинг vs Оптимизация

Ну тут совсем все легко, потому как рефакторинг кода и оптимизация кода преследуют разные цели, и, как это обычно бывает, оказывают противоположный эффект на читаемость кода, хотя и тот и другой не меняют логику работы программы. В процессе оптимизации программного кода главной целью является обеспечение приемлемой скорости выполнения (или рационального расходования памяти в ходе выполнения) критических участков — “узких мест” в программе. В жертву могут быть принесены не только логичность и “красота” программного кода, но и основные догмы объектно-ориентированного подхода. Результатами оптимизации могут стать и появление глобальных переменных, и “лишние” отрытые методы и свойства, раскрывающие детали реализации ваших классов и т.п. безобразия. На мой взгляд, нужно уделять особое внимание рефакторингу, а необходимость в оптимизации стараться сводить к минимуму за счет уместного использования качественных библиотек сторонних производителей.

Разработка тестов

При проведении рефакторинга важным предварительным условием является наличие надежных тестов.

Правила разработки тестов

• Делайте все тесты полностью автоматическими, так чтобы они проверяли собственные результаты.
• Комплект тестов служит мощным детектором ошибок, резко сокращающим время их поиска.
• Чаще запускайте тесты. Запускайте тесты при каждой компиляции — каждый тест хотя бы раз в день.
• Получив сообщение об ошибке, начните с создания теста модуля, показывающего эту ошибку.
• Лучше написать и выполнить неполные тесты, чем не выполнить полные тесты.
• Подумайте о граничных условиях, которые могут быть неправильно обработаны, и сосредоточьте на них свои тесты.
• Не забывайте проверять, чтобы в случае возникновения проблем генерировались исключительные ситуации.
• Опасение по поводу того, что тестирование не выявит все ошибки, не должно помешать написанию тестов, которые выявят большинство ошибок.

• Потребность вносить изменения в существующий код
• Необходимость строго придерживаться поставленной задачи
• Покрывать код проверочными тестами

Признаки, что Вам нужен рефакторинга

• Ваш программный продукт работает, но внесение новой функциональности иногда затягивается на недели;
• В определенных местах Ваш код работает совершенно не так, как Вы того ожидали;
• Вы часто ошибаетесь в сроках реализации поставленной задачи;
• Вам приходится вносить однотипные изменения в разных местах.

• Инкапсуляция поля (Encapsulate Field);
• Выделение класса (Extract Class);
• Выделение интерфейса (Extract Interface);
• Выделение локальной переменной (Extract Local Variable);
• Выделение метода (Extract Method);
• Генерализация типа (Generalize Type);
• Встраивание (Inline);
• Введение фабрики (Introduce Factory);
• Введение параметра (Introduce Parameter);
• Подъём поля/метода (Pull Up);
• Спуск поля/метода (Push Down);
• Замена условного оператора полиморфизмом (Replace Conditional with Polymorphism);

Рефакторинг очень существенно влияет на сопровождаемость проекта

Любой проект без регулярного рефакторинга за несколько лет (или даже месяцев) становится трудным для понимания, процессы изменений замедляются и становятся дороже, а иногда такие проекты доходят до состояния «проще переписать тут всё с нуля, чем разбираться». Таким образом затраты на рефакторинг окупаются за счёт того, что изменения вносить становится проще и процесс модернизации обходится значительно дешевле.

Источник: bookflow.ru