Юрий: Да, возможно так и есть. Но вы не поняли сути того, что я сказал. Изменение требований - вещь неизбежная. Причём возможность изменения требований часто напрямую закладывается в ТЗ как одно из ключевых требований. И разработчик несёт большую ответственность за то, чтобы это требование реализовать.
Автор вопроса спросил, как донести до руководства ошибочность направления работы студии. Причём по словам автора, он разработчик, а не аналитик и не менеджер. Мой ответ разработчику - предложить архитектуру, которая позволит быстро вносить изменения в проект без критической потери качества. Это сработает, потому что такое решение устроит и ПМ, и руководство, и заказчиков, и разработчиков. И до лампады, что слышали или не слышали те или иные заинтересованные лица.
Захар: Вы про это: "Если параметр locks имеет значение по умолчанию 0, порог укрупнения блокировок достигается, если память, используемая объектами блокировки, составляет 24 % от памяти компонента Database Engine, исключая память AWE"? Но это про блокировки, а я говорю про эскалацию транзакции. Это разные вещи.
Есть две общих рекомендации, которые мы для себя вынесли из нашей ситуации: максимально упрощать транзакцию и стараться избегать обращений к разным источникам в рамках одной транзакции.
Наша проблема была связана с тем, что в рамках TransactionScope шло сохранение данных в операционную БД и одновременное логирование этого процесса в БД мониторинга, причём обе базы были на одном инстансе. Мы переработали реализацию в соответствии с указанными , что решило проблему.
Замечу, что эскалация происходила при записи данных в две разные БД в рамках одной довольно тяжёлой транзакции: в операционную БД сохранялся большой объём данных в разные таблицы. Ключевым показателем тут является производительность. Нет возможности точно сказать, в какой момент СУБД решает, что нужно эскалировать транзакцию. Но лёгкие транзакции, даже при записи в две разные базы, проходят без эскалации. Тоже самое можно сказать о чтении данных из операционной БД при одновременной записи журнала.
Вероятно, если Вы создадите временную таблицу в рамках одной транзакции, а прочитаете данные из неё и используете их в другой, то эскалации не будет. Но 100% гарантии это не даст. Решение всё равно принимает СУБД.
Кстати, я бы дату в таблице измерения по дате задачи хранил не как единое поле, а в отдельных полях дату, месяц, год. Как минимум. Это сильно упрощает работу с многомерными данными.
nico: Если тим-лид занят где-то, кроме проекта, то у проекта нет тим-лида. Поэтому первое, что Вы должны сделать - найти технического лидера, который наведёт порядок в связке между требованиями и реализацией. Он же сформулирует корректный план разработки. И он же направит работу команды в правильное русло. Более подробно на эту тему я высказывался здесь: m-i-kuznetsov.livejournal.com/58244.html, загляните, там есть несколько цитат весьма уважаемых людей. Там же я описал похожую на Вашу ситуацию (хотя у нас тогда проект был несколько крупнее: несколько аналитиков, почти десяток штатных разработчиков, тестеры, плюс подрядчики).
Евгений Петров: Ну, желание гадить в тапочки можно очень быстро отбить. Как в любой профессии, в программировании полно своих д'Артаньянов. Которые, впрочем, могут дослужиться до маршалов. Если выживут.
Вот с умением гадить придётся повозиться подольше :) Оно лечится только с приходом желания делать всё чисто и аккуратно, а для этого уже некоторый опыт нужен. И получать этот опыт иногда молодого человека нужно заставить, чтобы он на своей шкурке понял, насколько это плохо. Могу только пожелать терпения, коллега ;)
Можно поинтересоваться, как Вы строите отношения с разработчиками? Вы непосредственно ставите задачи программистам и принимаете их работу? Или есть кто-то другой, кто занимается постановкой задач?
maximkv25: Разницы между одним и другим - почти никакой. Навыков у него в любом случае ноль. Мне нужно видеть характер и талант человека, как он думает, быстро ли сдаётся при решении задачи, умеет ли отстаивать свою точку зрения, умеет ли признавать ошибки, ждёт ли подсказок со стороны... Я принимаю в команду человека, который должен быть полезен для команды, а не тормозить её. Навыки я ему сам дам, причём на предельно конкретных примерах.
Как руководитель разработки, я глаза на профессиональные навыки никак закрыть не могу. И без моего одобрения стажёра на работу не примут.
А курсы английского у нас в офисе есть. Хотя некий начальный уровень не помешает: основная документация по Java на английском.
Виталий Пухов: Движок, но не только для базы знаний. В ней есть хорошие наработки по управлению процессами на основе Activity. Используется стандарт BPMN. И, главное, она легко кастомизируется под конкретную предметную область. Т.е. как основа и именно движок вполне подойдёт. А дальше - оболочка, которую Вам нужно создать. Это как вариант.
Автор вопроса спросил, как донести до руководства ошибочность направления работы студии. Причём по словам автора, он разработчик, а не аналитик и не менеджер. Мой ответ разработчику - предложить архитектуру, которая позволит быстро вносить изменения в проект без критической потери качества. Это сработает, потому что такое решение устроит и ПМ, и руководство, и заказчиков, и разработчиков. И до лампады, что слышали или не слышали те или иные заинтересованные лица.