| English | Russian |
| at the book's core is a comprehensive catalog of refactorings. Each refactoring describes the motivation and mechanics of a proven code transformation. Some of the refactorings, such as Extract Method or Move Field, may seem obvious. But don't be fooled | Основу книги составляет подробный перечень методов рефакторинга. Каждый метод описывает мотивацию и технику испытанного на практике преобразования кода. Некоторые виды рефакторинга, такие как "Выделение метода" или "Перемещение поля", могут показаться очевидными, но пусть это не вводит вас в заблуждение (см. Refactoring: Improving the Design of Existing Code by Martin Fowler et al. 1999) |
| in contemporary practice, CASE and programming development tools can effectively assist in performing refactorings. Many tools contain catalogs of supported refactorings. Fowler 1999 is a principal source of reference that lists and documents in excess of sixty refactoring methods. The following discussion illustrates the use of refactoring methods by discussing just three of them | в современной практике CASE и инструментальные средства разработки программ могут существенно помочь в реализации рефакторинга. Многие инструментальные средства содержат каталоги поддерживаемых рефакторингов. Фаулер 1999 является основным источником ссылок, который перечисляет и документирует более шестидесяти методов рефакторинга. Следующее обсуждение иллюстрирует использование методов рефакторинга, рассматривая только три из них (см. Maciaszek L.A. and Liong B.L. 2005: Practical Software Engineering) |
| in contemporary practice, CASE and programming development tools can effectively assist in performing refactorings. Many tools contain catalogs of supported refactorings. Fowler 1999 is a principal source of reference that lists and documents in excess of sixty refactoring methods. The following discussion illustrates the use of refactoring methods by discussing just three of them | в современной практике CASE– и инструментальные средства разработки программ могут существенно помочь в реализации рефакторинга. Многие инструментальные средства содержат каталоги поддерживаемых рефакторингов. Фаулер 1999 является основным источником ссылок, который перечисляет и документирует более шестидесяти методов рефакторинга. Следующее обсуждение иллюстрирует использование методов рефакторинга, рассматривая только три из них (см. Maciaszek L.A. and Liong B.L. 2005: Practical Software Engineering) |
| in the software lifecycle, the time and effort put into the code maintenance significantly outweighs the time and effort put into writing the code in the first place. Code maintenance is reading it and trying to understand it in order to modify or extend it. Any refactoring of code during its production, no matter how small, can significantly benefit software maintainers | в жизненном цикле ПО время и трудозатраты на сопровождение кода существенно превышают время и трудозатраты на первоначальное написание кода. При сопровождении кода необходимо прочитать и попробовать понять его, чтобы затем изменить или расширить. Любой рефакторинг кода в процессе его создания, независимо от того, сколь он мал, может принести существенную пользу эксплуатационному персоналу ПО (см. Maciaszek L.A. and Liong B.L. 2005: Practical Software Engineering) |
| one of refactoring targets is called large class – a class that does too much and/or has too many data members. Large classes can result from excessive minimization of coupling between classes. In case of the large class target, two methods relevant to Iteration 1 code are: Extract Class and Extract Interface Fowler, 1999 | Одна из целей использования рефакторинга называется большим классом – классом, который делает слишком много и/или имеет слишком много элементов данных. Большие классы могут возникнуть из-за чрезмерной минимизации связей между классами. В случае большого класса в коде итерации 1 уместны два метода: Класс извлечения и Интерфейс извлечения (Фаулер, 1999; см. Maciaszek L.A. and Liong B.L. (2005): Practical Software Engineering) |
| So, what's the problem? Simply this: Refactoring is risky. It requires changes to working code that can introduce subtle bugs | так в чём проблема? Только в том, что с рефакторингом связан известный риск. Он требует внести изменения в работающий код, что может привести к появлению трудно находимых ошибок в программе (см. Refactoring: Improving the Design of Existing Code by Martin Fowler et al. 1999) |
| the Extract Class refactoring is defined as "Create a new class and move the relevant fields and methods from the old class into the new class" | Рефакторинг Класс извлечения определяется так: "Создайте новый класс и переместите соответствующие поля и методы из старого класса в новый" (Фаулер, 1999, с.149). Главная трудность заключается в определении, как разбить большой класс на ряд меньших классов. Идея заключается в том, чтобы извлечь непротиворечивые и объединённые части функциональных возможностей в отдельный класс (классы; Fowler, 1999, p.149). The main difficulty is in deciding how to split a large class into a number of smaller classes. The idea is to extract consistent and integrated piece of functionality into a separate class (classes; см. Maciaszek L.A. and Liong B.L. (2005): Practical Software Engineering; все рефакторинги начинаются с глаголов, т. е. Extract Class — "Извлечь класс", а не бессмысленный "Класс извлечения". SirReal) |
| the refactoring target of Extract Interface is twofold and defined as "Several clients use the same subset of a class's interface, or two classes have part of their interfaces in common" | Цель рефакторинга Интерфейс извлечения двойная и определяется так: "Несколько клиентов используют то же самое подмножество интерфейса класса или два класса содержат общую часть своих интерфейсов" (Фаулер, 1999, с.341). Метод рефакторинга Интерфейс извлечения используется, чтобы "выделить подмножество в интерфейс" (там же). Идея относительно этого рефакторинга связана с самой природой интерфейсов (раздел 9.1.6; Fowler, 1999, p.341). The Extract Interface refactoring method is to "extract the subset into an interface" (Fowler, 1999, p.341). The idea of this refactoring is related to the very nature of interfaces (Section 9.1.6; см. Maciaszek L.A. and Liong B.L. (2005): Practical Software Engineering) |
| the refactoring target of Extract Interface is twofold and defined as Several clients use the same subset of a class's interface, or two classes have part of their interfaces in common | Цель рефакторинга Интерфейс извлечения двойная и определяется так: "Несколько клиентов используют то же самое подмножество интерфейса класса или два класса содержат общую часть своих интерфейсов" Фаулер, 1999, с.341. Метод рефакторинга Интерфейс извлечения используется, чтобы "выделить подмножество в интерфейс" там же. Идея относительно этого рефакторинга связана с самой природой интерфейсов (Fowler, 1999, p.341). The Extract Interface refactoring method is to extract the subset into an interface (Fowler, 1999, p.341). The idea of this refactoring is related to the very nature of interfaces (Section 9.1.6; см. Maciaszek L.A. and Liong B.L. (2005): Practical Software Engineering; раздел 9.1.6) |
| Understanding the mechanics of such refactorings is the key to refactoring in a disciplined way | Понимание техники таких методов рефакторинга важно для организованного осуществления рефакторинга (см. Refactoring: Improving the Design of Existing Code by Martin Fowler et al. 1999 ssn) |
