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

Технический долг Автор рассказывает о своей первой работе в качестве студента-веб-мастера, где ему пришлось писать PHP и MySQL-код, унаследованный от предыдущего веб-мастера, но он не понимал этого, поэтому решил переписать его из-за технического долга, который является одной из основных причин переписывания программного обеспечения.

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

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

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

Этапы разработки подключенного интерфейса Разработка интерфейса продвинулась вперед благодаря использованию "const" вместо "var", подхода React к прямым манипуляциям с DOM и CSS в JS.

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

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

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

Запрещенные тесты зависимостей Методология тестирования запрещенных зависимостей позволяет тестировать структуру приложения с точки зрения зависимостей. Написание правил, которые являются частью CI, может привести к сбою сборки, если кто-то попытается зависеть от определенного кода, что помогает предотвратить нежелательные зависимости и дублирование в общей бизнес-логике.

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

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