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-операторов, у соседей тоже сколько-то. В какой-то момент я вышел на даму, чьей специальностью была именно продажа софта. Ее вердикт был - "время упущено, но десяток продаж я вам сделаю". Мое начальство ухитрилось не договориться с ее начальством. Не знаю почему, но подозреваю, стоимость внедрения "сугубо заточенного" решения опять же сыграла свою роль.

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

Alexey KudinovЗакладываться на то, что может быть "вообще все что угодно" можно, но не нужно.
Боюсь, Вы не уловили ключевого аспекта: с моей точки зрения, в большинстве случаев не нужно "закладываться" (то есть предпринимать какие-то специальные усилия по этому поводу), нужно оставлять себе свободу действий на тот момент, когда и если наконец потребуется принимать решение. Дело в том, что когда требуется "расширить" узкую систему, довольно часто оказывается, что ранее были приняты совершенно необязательные решения, которые тогда были в лучшем случае "чуть проще", а сейчас заставляют либо серьезно переделывать, либо придумывать кривые обходы.

Alexey KudinovОчень уж категорично... Случаи таки бывают разные.
Таки бывают :) Но тут есть еще один аспект. Позволю себе аналогию - это из рассказа одного из наших летчиков-испытателей. Во время войны, летит куда-то пассажиром, большую часть полета проводит в кабине болтая с пилотами, перед посадкой у транспортника не выходит одна из ног шасси. Он проводит быстый инструктаж типа - все нормально, садись как если бы обе ноги нормально вышли, ничего страшного не будет. И у него там есть такая фраза - мол, я думал, не сказать ли, что перед касанием стоит чуть наклонить самолет в сторону здоровой ноги, но решил что не стоит - обычный строевой летчик запросто может перестараться, зацепить крылом землю и всех угробить, пусть лучше садится так.

К чему этот рассказ. Я полагаю, что информация, утверждения итп кроме естественного деления истинно/ложно следует рассматривать еще в одном разрезе, условно назовем удачно/неудачно. Суть в том, что в жизни бывает так, что из вообще говоря ложного утверждения следуют правильные с практической точки зрения результаты, и наоборот, формально правильная мысль может приводить к практически неудачным последствиям.

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

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

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

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

softwarerи как мне кажется, в изначально разном понимании степени универсальности, подразумеваемой в конкретном случае.

Bogdanov AndreySAP R3 и Oracle Applications скорее не готовые системы, а "конструкторы" для разработки систем.
Не скажу ничего о SAP, но насчет OEBS не согласен. Разумеется, при остром желании можно сотворить руками "OEBS который и на OEBS-то не похож", но это нисколько не означает "конструкторности".

Bogdanov AndreyНе хотел обидеть уважаемый EBS, просто на мой взгляд его упоминание в этом топике равносильно упоминанию Oracle - мало кто пишет свои реляционные СУБД, большинство использует готовые наработки. Мне казалось, что автор все-таки говорил о другом "уровне" наработок.
Я нисколько не обижаюсь за неинтересный мне EBS, но мне кажется что у "O"EBS и "O"RDBMS существенно разный уровень "наработанности".

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

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

AlexTheRavenIMHO потому, что ресурсы на фундаментальные исследования, и даже на изучение результатов уже проведённых фундаментальных исследований, при создании обычных учётных систем не предусмотрено.
Я бы усилил это утверждение. Допустим, идет внедрение какого-нибудь OEBS, надо например написать два отчета. Если внести в план первый отчет - пять дней, второй отчет - пять дней, это легко, просто и не вызывает вопросов. Если же внести в план, допустим, "некая фундаментальная работа под оба этих отчета" - три дня, первый отчет - три дня, второй отчет - два дня, то окажется, что разработчик создал себе проблемы на пустом месте: ему это не нужно, он просто сократил себе оплачиваемое рабочее время, и мало того, клиент еще и встанет на дыбы и скажет "чего это вы делали непонятно что, оплачу только три дня по первому отчету и два дня по второму". Вот такая вот загогулина :(

FrankieКакой кошмар, неужели кругом одни идиоты?!
Нет, не одни. Но встречаются достаточно часто, чтобы возникали проблемы.

FrankieЯ бы в такой ситуации составил план согласно первому случаю, а делал согласно второму :)
И в результате через пять дней пользователь сказал бы: по плану первый отчет уже должен быть готов. Где он?? :))

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

Alexey KudinovЗаказчик в общем то тоже не всегда идиот.
Не всегда. Но чаще, чем хотелось бы.

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

Alexey KudinovЕсли программист сможет внятно обьяснить зачем ему нужно "фундаментальное исследование", клиент наверное согласится его оплатить.
Это оптимистическая точка зрения. И не забудьте еще один важный момент - ответ на вопрос "кому это нужно".

Alexey KudinovВ связи с этим меня неизменно веселят посты типа "я хочу заюзать новую технологию ХХХ. Я знаю что это круто, помогите сформулировать ее преимущества для дебила-начальника"
Тут Вы, бесспорно, правы.

Alexey KudinovЭто если еще не вспомнать о присущей программистам чувстве реальности в оценке затрат времени на "фундаментальные исследования" и точности в последующем следовании этой оценке
Именно поэтому я говорил не об исследовании, а о более конкретных вещах (применительно к тем же отчетам - написать вспомогательные view, например).