| Russian | English |
| восходящее тестирование: последовательный подход к интеграционному тестированию, при котором компоненты нижнего уровня тестируются первыми и затем используются для облегчения тестирования компонентов более высокого уровня. этот процесс повторяется до тех пор, пока компонент на самом верху иерархии не будет протестирован | bottom-up testing: An incremental approach to integration testing where the lowest level components are tested first, and then used to facilitate the testing of higher level components. This process is repeated until the component at the top of the hierarchy is tested (см. Standard glossary of terms used in Software Testing) |
| всё сказанное означает, что разработчик ПО должен быть готов создавать ПО, которое можно приспосабливать к изменениям. этого требует сама природа ПО. Программное обеспечение должно быть приемлемым понятным, обслуживаемым и расширяемым | this said, a software engineer must be prepared to build software that can accommodate change. That is the demanded nature of software. Software must be supportable understandable, maintainable and scalable (см. Maciaszek L.A. and Liong B.L. 2005: Practical Software Engineering) |
| Завершение самого внешнего состояния объекта соответствует гибели этого объекта | Completion of the outermost state of an object corresponds to its death (см. "The UML Reference Manual" by J.Rumbaugh, Ivar Jacobson, Grady Booch 1999 ssn) |
| Идея эта стара, как сама компьютерная индустрия | this message is as old as the software field itself (ssn) |
| можно сказать, что практика управляемой тестированием разработки раздел 12.2 является частичной заменой рефакторинга. Действительно, управляемая тестированием разработка использует разновидность рефакторинга – разновидность, которая применяется для улучшения скорее самого проекта, а не кода. Управляемая тестированием разработка – итеративный и пошаговый процесс, объединённый с написанием прикладного кода. Рефакторинг может предугадать "дурно пахнущий код" и устранить его до того, как это случится | it can be argued that the practice of test-driven development Section 12.2 is a partial substitution for refactoring. In reality, test-driven development uses a variation of refactoring – a variation that applies to cleaning up the design rather than the code. Test-driven development is an iterative and incremental process intermixed with writing the application code. Refactoring can anticipate "bad smells in code" and eliminate them before they happen (см. Maciaszek L.A. and Liong B.L. 2005: Practical Software Engineering) |
| пожалуй, это самый чистый способ написания автономных тестов для асинхронного кода, поскольку ответственность за управление потоками перекладывается на каркас тестирования | this is arguably the neatest way to write unit tests for async code, pushing the responsibility for threads into the testing framework (см. Async in C# 5.0 / Alex Davies 2012) |
| Порождение событий – это подход, концентрирующий внимание на долговременном хранении всех изменений персистентного состояния, а не самого текущего состояния | Event sourcing is an approach that concentrates on persisting all the changes to a persistent state, rather than persisting the current state itself (ssn) |
| Самый прямой подход в работе с диаграммами состояний – это вложенный оператор switch | the most direct approach to handling a state diagram is a nested switch statement (см. "UML Distilled: A Brief Guide to the Standard Object Modeling Language, Third Edition" by Martin Fowler 2003) |
| Самый прямой подход в работе с диаграммами состояний это вложенный оператор switch | the most direct approach to handling a state diagram is a nested switch statement (см. "UML Distilled: A Brief Guide to the Standard Object Modeling Language, Third Edition" by Martin Fowler 2003) |
| так как детали доступа к объектам приложения в значительной мере зависят от самого приложения и его реализации, мы не станем останавливаться на этом вопросе | Because the details of accessing application objects depend heavily on the application and its implementation, we shall not pursue them here (см. Introduction to Algorithms Second Edition by Thomas H. Cormen et al. 2001) |
| Цель рефакторинга Интерфейс извлечения двойная и определяется так: "Несколько клиентов используют то же самое подмножество интерфейса класса или два класса содержат общую часть своих интерфейсов" Фаулер, 1999, с.341. Метод рефакторинга Интерфейс извлечения используется, чтобы "выделить подмножество в интерфейс" там же. Идея относительно этого рефакторинга связана с самой природой интерфейсов | 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 (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) |
| этого требует сама природа ПО | that is the demanded nature of software (ssn) |
| этого требует сама природа программного обеспечения | that is the demanded nature of software (ssn) |
| этот простой паттерн – самая суть эпизодических вычислений | this simple pattern is at the heart of episodic computation |
| этот простой паттерн самая суть эпизодических вычислений | this simple pattern is at the heart of episodic computation |
