Software: Managing the Complexity

[gaperton]

Эта заметка про понятие "сложности" в ПО, и его связь с управлением проектами.

С веселыми картинками и забавными примерами.

https://medium.com/@gaperton/software-managing-the-complexity-caff5c4964cf#.crsq3slua

Comments

Software: Managing the Complexity

[livejournal]

Пользователь om8 сослался на вашу запись в своей записи « Software: Managing the Complexity» в контексте: [...] Оригинал взят у в Software: Managing the Complexity [...]

Накидаю я лучше комментариев сюда

[alexander_mikh]

Есть еще несколько способов:
моделирование изменений или проектов - это была цель UML и прочих инструментов системной инженерии.
В подкасте iTunes U от Carnegie Mellon University Software Engineering Institute, есть несколько интересных обсуждений на тему software complexity, включая mission critical systems. В одном из таких обсуждений приводится ссылка на одно из исследований в котором рассматривали complexity как "меру когда разработчик не может удержать систему или изменение в голове" и поэтому появляется необходимость (или осознание необходимости) моделировать систему. Однако тоже исследование указывает что к тому моменту система уже становится messy и моделировать становится слишком поздно.
ИМХО менеджерское решение - надо моделировать заранее, начиная с мелких шагов и включать стандарт моделирования, общий для разработчиков + dev ops и бизнеса.

Еще один из интересных способов борьбы с complexity - создание собственного DSL, по сути моделирование в DDD терминах - шаг после осознания пункта выше.

Re: Накидаю я лучше комментариев сюда

[gaperton]

Эти способы являются разными вариантами базовых двух. Абстракции, и декомпозиции - это весьма общие понятия. Делая модель, мы выполняем декомпозицию. Делая DSL, мы вводим абстракцию.

Я намеренно не употребляю сложной терминологии. Если люди понимают базу, это уже хорошо. Потому, что ничерта они не понимают. Только повторяют разную заумь.