Comments 5
К перечисленным выше 3 случаям ошибок при проектировании я бы добавил слабую проработку бизнес-процессов. Это - боль. Бизнес-аналитики часто не утруждают себя прямым контактом с пользователями. Не все, конечно, но многие. Отсюда - дичайшая дичь. Они могут увидеть поверхностные явления (а потом - извратить и их), но чем эти явления обусловлены - им невдомек.
Часто приложения проектируются без учета потенциального роста бизнес-логики и количества пользователей. Как говорится "сейчас справляется - и ладно; о лучшем подумаем после". Тут нужен талант, своего рода чуйка. Этому не научишься на курсах. Этому учатся в процессе. Но результатов добиваются единицы.
Часто бизнес говорит "сделайте по минимуму, лишь бы работало". Его понять можно. Но также часто бизнес не пытается заглядывать чуть дальше. Задача архитектуры и аналитики быть прозорливее пользователей. Для этого нужна погруженность в те процессы, что выполняют пользователи. Если пользователи привыкли, что отчет формируется ночь, то при росте нагрузки в 2 раза этот же отчет будет наверняка формироваться дольше, но не в 2 раза, а, скорее, в 4 или даже в 10 раз.
Решения - как это предусмотреть и избежать, у меня, увы, нет. С унаследованными системами все очень больно - придется влезать в старую кодовую базу, менять фреймворки, базы данных, архитектуру - такое себе решение, но обычно на это приходится идти. А иногда и этого нельзя делать - только править существующее.
Но хоть новые-то проекты можно делать сразу по-людски, с перспективой роста?
А все почему? Собирается нефункциональные требования наравне с функциональными и будет вам счастье. Или не будет :) Но если не собирать - почти точно не будет :)
--------------
Вообще странно видеть столько длинную статью, при этом хотя бы перечисление этих требований отсутствует :)
Очень дельная статья, причём не только для аналитика или разработчика, но и для заказчика проекта. Помогает понять, как правильно доносить запрос до команды. Спасибо!
Перепроектирование приложений неизбежно?