| Russian | English |
| вносить изменения в размётку | make a change to the markup (Alex_Odeychuk) |
| вносить следующие изменения в код | update the code in the following way (Alex_Odeychuk) |
| значительные изменения в деловой сфере | major business changes (ssn) |
| изменения в библиотеке классов | class library changes (IBM Alex_Odeychuk) |
| изменения в данных | changes to data (ssn) |
| изменения в деловой сфере | business changes (ssn) |
| изменения в законодательстве | changes to legislation (ssn) |
| изменения в интерфейсе библиотеки | changes in the interface of the library (IBM Alex_Odeychuk) |
| изменения в общей культуре | culture shifts (ssn) |
| изменения в пакете | changes to package (ssn) |
| изменения в поставляемом коде | change in the supplier code (ssn) |
| изменения в программном коде | changing software (ssn) |
| изменения в программном обеспечении | software change (ssn) |
| изменения в процессах менеджмента услуг | changes to service management processes (ssn) |
| изменения в регулирующих актах | regulatory changes (ssn) |
| изменения в синтаксисе языка программирования | changes to the language (корпорации AdaCore Alex_Odeychuk) |
| изменения в средствах связи с базами данных | database connectivity changes (компании Embarcadero Technologies Alex_Odeychuk) |
| изменения в существовавших методах | changes to previous methods (ssn) |
| изменения в технических рабочих продуктах | changes to the technical artifacts (ssn) |
| изменения в технологии и данных | technology and data variations (ssn) |
| изменения в управлении сервисами | new governance around services (ssn) |
| изменения в языке программирования | language changes (Alex_Odeychuk) |
| незавершённые изменения в программном обеспечении | technical debt (корпорации AdaCore Alex_Odeychuk) |
| необходимые, но ещё не выполненные изменения в ПО | technical debt (корпорации AdaCore; контекстуальный перевод на русс. язык Alex_Odeychuk) |
| Структурное проектирование – нечто вроде упражнения в управлении зависимостями модулей. Модуль A зависит от модуля B, если изменения в модуле B могут потребовать изменений в модуле A. Важно, чтобы эти зависимости не противоречили брандмауэрам зависимостей Мартин, 2003. В частности, зависимости не должны быть между несоседними уровнями и не должны создавать циклы | Architectural design is an exercise in managing module dependencies. Module A depends on module B if changes to module B may necessitate changes to module A. It is important that dependencies do not cross dependency firewalls Martin, 2003. In particular, dependencies should not propagate across non-neighboring layers and must not create cycles (см. Maciaszek L.A. and Liong B.L. 2005: Practical Software Engineering ssn) |
| так в чём проблема? Только в том, что с рефакторингом связан известный риск. Он требует внести изменения в работающий код, что может привести к появлению трудно находимых ошибок в программе | 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) |
| требовать внести изменения в работающий код | require changes to working code (ssn) |
| упрощённый процесс итерации по значениям для обновления оценок полезностей после каждого изменения в модели, определяемой с помощью обучения | simplified value iteration process to update the utility estimates after each change to the learned model (ssn) |
