Источник
Modern Software Engineering
Пост в book_cube с обзором структуры книги David Farley и ключевых инженерных принципов.
Источник
Modern Software Engineering
Пост в book_cube с обзором структуры книги David Farley и ключевых инженерных принципов.
Modern Software Engineering: Doing What Works to Build Better Software Faster (Современная разработка программного обеспечения)
Авторы: David Farley
Издательство: Addison-Wesley Professional
Объем: 2021
Книга David Farley о том, как применять инженерный подход к разработке ПО в условиях неопределенности: учиться быстрее, снижать сложность и делать доставку изменений предсказуемой.
ОригиналSoftware Engineering / Management / Delivery / Complexity
Modern Software Engineering можно читать как обновление инженерной оптики после эпохи agile/devops-базиса: меньше догм, больше проверяемых практик, быстрее обратная связь и дисциплина в управлении сложностью.
1. Карта книги: 4 части
1. What Is Software Engineering
Farley формулирует инженерный взгляд на разработку: engineering это practical application of science, а software можно и нужно строить как инженерную дисциплину.
2. Optimize for Learning
В непредсказуемой среде решает скорость обучения. Ключевой фокус: короткие итерации, ранний feedback, incremental delivery, эмпиризм и постоянные эксперименты.
3. Optimize for Managing Complexity
Борьба со сложностью через модульность, cohesion, separation of concerns, information hiding и осознанное управление coupling.
4. The Tools of an Engineering Discipline
Практические рычаги engineering excellence: testability, deployability, скорость изменений, контроль переменных и continuous delivery как рабочая норма.
2. Optimize for Learning: что важно забрать в практику
- Working iteratively: проектировать изменения короткими циклами, а не большими фазами без обратной связи.
- Feedback first: получать сигнал по коду, архитектуре и продукту как можно раньше, пока цена коррекции низкая.
- Incrementalism: ограничивать blast radius каждого изменения через декомпозицию и модульные границы.
- Empiricism: проверять гипотезы фактами, измерениями и реальным поведением системы.
- Being experimental: относиться к решениям как к экспериментам с явной гипотезой и критериями успеха.
3. Optimize for Managing Complexity
Modularity
Наследие Parnas: делим систему так, чтобы изменения были локальными, а поведение модулей предсказуемым.
Cohesion
Элементы внутри модуля должны логично принадлежать друг другу. Это снижает случайные связи и упрощает эволюцию.
Separation of concerns
DI, DDD, Port & Adapters и TDD помогают отделять ответственность и сохранять ясные границы между частями системы.
Information hiding and abstraction
Скрываем детали реализации за стабильными интерфейсами, чтобы локально менять внутренности без каскадных эффектов.
Managing coupling
Связность между модулями должна быть осознанной и измеримой, иначе скорость разработки падает с каждым релизом.
4. The tools of an engineering discipline
- Testability: проектируйте систему так, чтобы проверка поведения была встроена в процесс разработки.
- Deployability: каждый инкремент должен быть технически готов к безопасной поставке.
- Speed: оптимизируйте lead time и cycle time как системную метрику инженерной организации.
- Controlling the variables: делайте процесс повторяемым и управляемым, чтобы результат не зависел от героизма.
- Continuous Delivery: держите кодовую базу в состоянии постоянной интеграции и потенциального релиза.
5. Типичные антипаттерны внедрения идей книги
Waterfall-мышление без реальных feedback loops между этапами.
Рефакторинг архитектуры без проверки гипотез и измерения эффекта.
Копирование практик BigTech без адаптации к размеру команды и домену.
Ставка на скорость релиза без testability и deployability фундамента.
6. Рекомендации для техлида и engineering manager
Сделайте двухнедельный audit feedback-контуров: PR, тесты, observability, продуктовые сигналы и post-release learning.
Для каждой крупной инициативы явно зафиксируйте архитектурные границы, чтобы уменьшить coupling до старта разработки.
Переведите CD из лозунга в операционную практику: trunk-based flow, автоматические проверки и безопасные маленькие релизы.
Оценивайте успех изменений по learning velocity: как быстро команда превращает гипотезы в подтвержденные знания.