Old NickВзять к примеру 3D, кто сейчас для написания игры разрабатывает математику?
Ведущие разработчики.

Old NickНикто, просто берут движок и создают новую игру
А так делают... те, кто двигается к ведущим позициям.

Old NickПочему в базах данных сейчас то же самое что было лет 20 назад? Каждый раз когда нужно создать, к примеру, учётную систему даже те, кто делает это не первый раз, пишут всё заново? Создают таблицы, пишут хранимки и т.д. Или это просто я в таком окружении нахожусь?
В таком окружении находитесь.

Old NickПочему, когда я кому-то говорю об общих принципах всех учётных движков, то за спиной крутят пальцем у виска (я краем глаза вижу) и каждый начинает уверять, что уж его-то задача из ряда вон и это уникальный частный случай, где общими принципами не обойтись.
Видел таких. Лечить.

Old NickМожет уровень разработчиков БД намного ниже, чем уровень 3D-шников?
Ошибаетесь, они одинаково низки.

Old NickИли может быть плохо написанная база данных всё-таки будет работать, а вот плохо проработанная математика в 3D игре не будет работать просто никак?
В этом пожалуй есть своя правда.

Old NickЕсть среди читающего народа те, кто использует один учётный движок без изменений в каждом новом проекте?
Что значит "без изменений"? Подозреваю, все нормальные люди используют движок и потихоньку его улучшают. В том числе исходя из требований новых проектов.

Bogdanov AndreyЕсли пишут заново в изменившихся условиях, то это не значит, что в прошлый раз ошиблись.
Если фирма пишет учетные системы одну за другой, и при этом каждую пишет так, что ее нельзя доработать до удовлетворения потребностей следующей - это имхо значит, что в прошлый раз ошиблись. Если же "дорабатывает раз, два и три" - в какой-то момент окажется, что очередной проект может быть выполнен без доработок движка. Можно, конечно, называть это "уже внедрением, а не новым проектом", суть от того не меняется.

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

Bogdanov AndreyСпособов реализации учета довольно много и какой из них выбрать для конкретной задачи вопрос не однозначный.
Безусловно.

Bogdanov AndreyЧестно скажу, что никогда не писал учетные системы "одну за другой". Больше был занят в относительно крупных (от 5-10 человеко-лет) проектах.
Признаться, это мне и представляется "одну за другой". Проект в 5-10 человеко-лет - это год-полтора реального времени.

Bogdanov AndreyУчаствовал в написании одного учетного ядра, еще два сам проектировал. Задаче при всей схожести терминологии были настолько разные...
Хм. Признаться, мне здесь представляется уместной старая байка насчет ощупывания слона. Первые впечатления разные, но постепенно ощупанным оказывается весь слон и новые впечатления... становятся редкими.

Bogdanov AndreyЕще несколько раз участвовал в приспособлении имеющегося учетного ядра под новые задачи. Не всегда это получается гладко.
Разумеется. Никто не обещал, что будет просто. Особенно если наработки делались без прицела на повторное использование.

Любая универсальность - это дополнительные инвестиции в первое время, на первых проектах. Ими оплачивается бОльшая надежность (в первую очередь именно надежность) и меньшие трудозатраты на следующих проектах, после того как технология наберет ход.

Bogdanov AndreyЯ и не утверждал, что впечатления "новые", я лишь утверждал, что они "разные". И сейчас (после знакомства с разными учетными задачами) я бы эти задачи решал бы по-разному. И не стал бы пытаться делать одну универсальную модель.
Вы почему-то никак не можете отказаться от мысли, что "одна универсальная модель" должна быть "одной задачей, растянутой на три". В то время как вполне может оказаться, что "одна универсальная модель" состоит из этих трех задач, еще из трех других, и после этого почти любая новая ложится в уже реализованное.

Да, конечно, есть "принципиальные вопросы" - скажем, упомянутый Вами выбор между проводками и полупроводками. Почему в кавычках - потому что этот выбор, пусть и является важным с точки зрения архитектуры системы, не так важен с точки зрения итогового результата; тот может быть приемлимым образом достигнут в любом случае.

Bogdanov AndreyСредства должны реализовывать поставленные задачи. А не представления программиста об идеальной абстрактной системе.

Знаком с парой примеров, когда группа программистов создавала "красивый и удобный универсальный конструктор",
Хм. Андрей, если честно, я.... не ценю, когда без необходимости заводятся стандартные песни класса не-о-том-зато-заведомо-истинные.

Bogdanov AndreyЕсли развитие системы не предполагается, то универсализация приведет лишь к увеличению сроков разработки, снижению надежности и производительности системы.
Не совсем так :) "Если развитие системы не предполагается", оно приведет к увеличению сроков и удорожанию "развитой системы", когда предположения нарушатся и такая таки случится.

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

Bogdanov AndreyЕсли же развитие предполагается, то универсализация должна быть именно такой, сколько надо для предполагаемого развития.
Вот это как раз принципиально неверно. Главный принцип универсализации можно сформулировать так: не связывай себе руки без необходимости. Компромисс ищется следующим образом: с одной стороны, "не трать заметные ресурсы на то, что сейчас не понадобится", но с другой стороны "из возможных решений выбирай то, которое не будет мешать тебе, когда потребуется развивать систему".

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

Bogdanov AndreyНо им внедрения были и не важны, он же универсальную систему писали...
История из жизни. У моего начальства были хорошие связи в Московской Сотовой Связи, ныне SKYLINK, мы им постоянно что-то писали. И вот однажды пришла начальству в голову идея написать им очередную хорошую программу. Долго ли коротко ли, сделал я даже не пилота, а нечто вроде демки - показать, что мы можем и как примерно это будет выглядеть. Те сказали "здорово", подписали договор, пошли делать.

Ситуация во время разработки сложилась довольно странная. С одной стороны, я делал проект практически в одиночку и практически единственный разбирался в задаче целиком. С другой стороны, я считался молодым-неопытным, поэтому по "важным вопросам" за мной постоянно пытались присматривать. В итоге проект был успешно сдан, но его трудоемкость заметно превысила заложенную; во время разбора полетов по этому поводу я довольно успешно доказал, что это явилось следствием ряда проектных решений, принятых в рамках "присмотра"; в наиболее выдающемся случае решение, принятое лично Главным с формулировкой "да перестань ты мне голову морочить, нет никакой разницы, делай как проще то есть как я сказал" вылилось в лишних месяц-полтора работы.

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

Я до сих пор не понимаю, сколько опилок должно было быть в головах у моего начальства, но они ухитрились не договориться. Почему? Потому что во время проектирования я говорил: давайте заложим "гнезда", куда сможем добавить мультиформатность. Меня посылали примерно с теми же аргументами, которые выдвигаете Вы. Теперь же, когда посмотрели, какое количество изменений придется внести, чтобы переделать под GSM программу, сделанную "сугубо под NMT" - выставили цену, превышавшую сумму в изначальном договоре на разработку. И то, что в NW их с этой ценой послали далеко и без вопросов, я вполне понимаю.

Ладно, переделка переделкой. В тот момент, когда разрабатывалась эта программа, в стране было около восьмидесяти NMT-операторов, у соседей тоже сколько-то. В какой-то момент я вышел на даму, чьей специальностью была именно продажа софта. Ее вердикт был - "время упущено, но десяток продаж я вам сделаю". Мое начальство ухитрилось не договориться с ее начальством. Не знаю почему, но подозреваю, стоимость внедрения "сугубо заточенного" решения опять же сыграла свою роль.

Что в итоге? В итоге, если бы правильно подойти к делу, программу можно было бы разрабатывать не только универсальной, но и хоть бесплатной - одна только техподдержка окупила бы ее за год и до сих пор приносила бы весьма и весьма нехилую чистую прибыль. А если подойти так, как подошли - "проект окупился и принес некоторую прибыль". Минус я, сваливший оттуда.