Прошу высказать свое мнение о подходе к построению архитектуры системы.

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

это

очень

плохая

идея

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

убейте его

это
очень
плохая
идея

у меня есть шанс отговорить их и от первого и от второго, пока не поздно. Но мне нужна помощь.

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

Почему я даю такие советы? А потому что у каждого своя совесть, я бы скорее всего не поступил бы так как тебе советую.

РБК ?

РБК ?

нет

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

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

Я понимаю как это все звучит со стороны№: куча говнокодеров пытается написать то, что владелец меняет каждый день. Но реально там есть вменяемые люди, просто им надо донести и убедить, что то чем они занимаются как маркетологи - противоречит здравому смыслу, исходящему от инженеров.

отговори себя работать с ними - свое драгоценное время надо экономить в первую очередь.

каждую неделю приходит с новым паком супер идей, как бы он хотел видел какую-то из частей системы.

А он сам умеет программировать или идеи берёт с хабра? А то был у меня такой знакомый теоретик, чужие идеи воспринимал плохо, свои идеи пропихивал, на выходе адский ад был. Основная его проблема была в том что он верил больше рекламным буклетам и чужому опыту с хабра, а не своим сотрудникам. Это приводило к двум проблемам: 1) некоторые вещи делались втихаря 2) то что не работало могло быть заменено тем что работает, а наверх сообщалось что внедрение сделано успешно, иначе затрахает досмерти пока не найдёшь причины «почему у фирмы xxx это взлетело, а у нас не хочет».

С другой стороны сотрудники сами не всегда в состоянии дать адекватную оценку нововведениями. Инертность мышления. Поэтому это палка о двух концах.

каждую неделю приходит с новым паком супер идей, как бы он хотел видел какую-то из частей системы

Только что с таким общался... лучше сразу его застрелить или отказаться от проекта.

С халявщиками не связывайся. Я попадал на таких.

проблемы с основателями проекта не являются архитектурными проблемами, если конечно речь идет не о архитектуре генотипа, и да эти ошибки пока наука не в силах исправлять

Твоя архитектура ничем не лучше его. Точнее у обоих есть слабые и сильные стороны. Заранее нельзя сказать, какая подойдет лучше, потому что реальных условий использования никто не знает (есть лишь предположения). С точки зрения руководства (которому нужно просто решение, далеко не идеальное, а просто работающее) ты человек, который создает лишнюю суету и мешает проекту. У них уже есть человек, который делает реальный продукт и уже отвечает за его работоспособность, а как пойдут дела с тобой никто не знает (возможно, ты напридумываешь всякой ерунды, а потом после первой неудачи уволишься...) Так что забудь про свою архитектуру, по-крайней мере в применении к этому проекту, и, либо уйди оттуда побыстрее, либо получай там, то что тебе надо (опыт, бабки, отсрочку от армии, общение с девками, все что угодно, только не рассказывай никому, что у тебя есть более клевая идея насчет архитектуры).

P.S. По мне, так лучший способ сделать нормальную архитектуру, так это строить ее постепенно, сначала просто работающий вариант, самый простой, а затем постепенно изменять уже работающие части, которые сильнее всего ограничивают работу и дописывать новые. При этом изначально нужно лишь позаботится, чтобы была возможность плавного эволюционного изменения архитектуры (т.е. продумать модульность и интерфейсы) при сохранении работоспособности старого кода. Это при условии, что проект будет развиваться длительное время (для сайта-визитки на php такой подход не катит).