| Russian | English |
| можно сказать, что практика управляемой тестированием разработки раздел 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) |
| на практике, процесс общения, начатый на ранних этапах и продолжающийся непрерывно, может дать архитектору верную оценку стоимости, а разработчику уверенность в проекте, не снимая при этом чёткого разграничения сфер ответственности | in practice, early and continuous communication can give the architect good cost readings and the builder confidence in the design without blurring the clear division of responsibilities (см. Frederic P. Brooks, Jr. THE MYTHICAL MAN-MONTH Essays on Software Engineering) |
| Наконец, вы можете найти другую работу. Независимо от экономических подъёмов и спадов хороших программистов всегда не хватает, а жизнь слишком коротка, чтобы тратить её на работу в отсталом учреждении при наличии множества лучших вариантов | Finally, you can find another job. Despite economic ups and downs, good programmers are perennially in short supply, and life is too short to work in an unenlightened programming shop when plenty of better alternatives are available (см. Code Complete / Steve McConnell.-2nd ed. 2004 ssn) |
| Уровень 2 на рис. 9.4 стабилен, а Уровень 1 нестабилен. Уровень 1 зависит от Уровня 2. Уровень 2 независим и поэтому может быть заменен новым без "эффекта ряби" в остальной части системы. это – принцип и причина, стоящие за разрешением сильной зависимости сильной связи в нисходящем направлении и обеспечением слабой зависимости слабой связи в восходящем направлении | Layer 2 in Figure 9-4 is stable and Layer 1 is instable. Layer 1 depends on Layer 2. Layer 2 is independent and can therefore be replaced by a new one without a ripple-effect on the rest of the system. This is the principle and the reason behind allowing a high dependency high coupling in the top-down direction and ensuring a low dependency low coupling in the bottom-up direction (см. Maciaszek L.A. and Liong B.L. 2005: Practical Software Engineering) |
