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

Как считаете, может быть такая ситуация, что пишется крупный проект и при этом разработчик БД один и занят всего процентов на 30? И если нет, то как сделать так, чтобы было именно так?

Old Nick,

Ладно, отвечу сам. Чаще всего встречаешь такую картину. Несколько разработчиков целыми днями напряженно пишут код, много кода, сложные запросы, постоянно их оптимизируют, дебажат код, когда вылазят ошибки. Знакомая картина.

И есть другой подход - использовать наработки, дописывая только то что нужно для новой прикладной логики. Примерно в 10 раз меньше работы, чем в первом случае. Я использую объектно-ориентированный подход с проектированию БД. Естественно есть базовые классы, базовая логика. В полной мере используется наследование, которое сводится к простому добавлению новых классов. Классы справочников, причем типовые справочники уже есть. Классы новых документов, типовые тоже уже есть. Классы бизнес-процессов.

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

andreymxiscrafm,

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

При таком подходе очень мало тратится ресурсов на программирование и основное время уходит на проектирование.

andreymxУ нас подход далеко не такой.

Правда, есть куча наработок.

Например, есть система запросов: основной запрос, запросы для выпадающих списков, настройки колонок и подключение по необходимости хранимок, и это всё через админку.
Система используется во всех приложениях.
Есть и универсальный справочник: приложение, настроенное эту на систему запросов. Подходит под 98% справочников. Обычно для подключения нового надо написать всего пару-тройку-пяток запросов, и всё. Приложение это используется не только для справочников, но и вообще в куче случаев, когда надо организовать срочный/массовый и не сильно сложный табличный ввод.


Но до полного ООП не дошли.

Это вы просто не с той стороны зашли. То что вы сделали вещь полезная и нужная, но не достаточная.
Это вы автоматизировали только первый этап - элементы интерфейса
Далее нужно автоматизировать второй этап - то есть создать библиотеку сущностей и связать их с элементами интерфейса.
В таком случае получите аналог 1С - конструктор.
И вот только на третьем этапе - когда научитесь автоматизировать бизнес-процессы, получите эффективность разработки на 2(два) порядка выше, чем после первого этапа

MasterZivOld NickОчень часто в конторах, которые занимаются разработкой ПО для собственных нужд, да и для внедрения у заказчиков работает несколько разработчиков БД. Это связано прежде всего с неправильно проектированной архитектурой приложения.

Как считаете, может быть такая ситуация, что пишется крупный проект и при этом разработчик БД один и занят всего процентов на 30? И если нет, то как сделать так, чтобы было именно так?

А что это самоцель? Занять имел на 30%

В таком случае разработчик БД может быть занят сразу в 3-х проектах.

ShrOld NickИ вот только на третьем этапе - когда научитесь автоматизировать бизнес-процессы, получите эффективность разработки на 2(два) порядка выше, чем после первого этапаТ.е. можно и сразу BPMS внедрить?

BPMS - это средство. То, что пишут на Дельфях не обязательно ООП

andreymxOld NickВ таком случае разработчик БД может быть занят сразу в 3-х проектах.у меня все заняты сразу во всех проектах
правда, у нас 66% - это сопровождение

Это очень плохой показатель. Хотя с какой стороны смотреть. Если со стороны собственника вашей компании, то это выгодно, постоянный доход.

iscrafmOld Nickпропущено...


Это очень плохой показатель. Хотя с какой стороны смотреть. Если со стороны собственника вашей компании, то это выгодно, постоянный доход.
а с какой стороны еще нужно смотреть на это все?

Ну это хорошо, пока нет конкуренции среди "автоматизаторов". Им сходит с рук даже 3%-ный КПД. Наверное, всё-таки придёт время когда будет конкуренция за клиентов и проиграют те, что не могут настроить технологию разработки ПО. А заказчик будет голосовать рублём.

iscrafmOld NickДалее нужно автоматизировать второй этап - то есть создать библиотеку сущностей и связать их с элементами интерфейса.
В таком случае получите аналог 1С - конструктор.
И вот только на третьем этапе - когда научитесь автоматизировать бизнес-процессы, получите эффективность разработки на 2(два) порядка выше, чем после первого этапа
после 2-го этапа, после того как поведетесь на магическую библиотеку каких-то "сущностей" уже ничего не будет. Так что планы на 3-й этап можно не строить.

p.s. то что описал andreymx и то что вы приняли за автоматизацию "элементов интерфейса", по какой-то причине, совершенно этим не является.

То есть вы не в курсе, что ООП выгоднее чем лапшепрограммирование? 8-()

Странно такое слышать от программиста. Вы не в курсе зачем библиотека System.dll или System.Data.dll и набор сущностей, который там есть? И как это помогает программистам тоже не в курсе? Я в шоке...