Здравствуйте, Аноним, Вы писали:
А>Доброе время суток Господа.
А>Хотелось бы найти хорошие книжки по проектированию ERP и просто сложных систем (я не про использование паттернов),а про общую архитектуру. А>Т.е в каких местах имело бы смысл делать так или иначе и хотелось бы с примерами небольшими.как те или иные задачи лучше реализовывать
А>заранее благодарен за ссылки
Здравствуйте, IT, Вы писали:
IT>Если быть честным с самим собой и при оценки удачности оперировать только объективными факторами, то удачность/неудачность вполне можно обнаружить, описать, проанализировать и сделать выводы. В моей, теперь уже можно сказать, практически бывшей конторе мы неоднократно проводили эксперименты по применению разных технологий для различных задач с последующим анализом и разбором полётов именно удачности решения. Никаких эмоций, чёткие факты и их анализ.
Критерий успешности какой ? Какие гипотезы выносятся в эксперимент и что именно тебе дают результаты ?
I>>Возможности и ограничения, как минимум часть, известны для каждого используемого инструмента, или тебе лично, или другим, кто их пробовал. Требования никогда не приходят в виде "сделай шоб усё было хорошо". Как правило проектировщик их сам же и уточняет разными способами, вплоть до непосредственной работы с заказчиком, помогая сформулировать проблему и желаемый результат. Потому не ясно, как ты работаешь до того, как задача стала близка к завершению
IT>В жизни и заказчик и разработчик тяготеет как раз к "сделай шоб усё было хорошо". И в этом нет ничего плохого, если разработчик изначально строит архитектуру проекта так, чтобы в любой момент быть готовым её существенно изменить. Здесь как раз и важен отрицательный опыт, который отрезает заведомо плохие пути. А вот заведомо хороших, к сожалению не бывает, если не решается типовая задача.
Мне кажется ты изобретаешь теорию принятия решений. Отрицательный опыт и положительный ничем не помогут в новой задаче. А вот знания возможностей и свойств инструментов наоборот, помогают и в новых задачах. И анализ требований на предмет выявляения ограничений так же поможет в новых задачах.
Скажем, в небольших приложениях не надо думать за GC, более того, не надо помогать ему, достаточно научиться занулять ссылки. В высоконагруженых приложениях и задачх реального режима времени все наоборот, надо не только помогать GC, но и думать за GC . Отсюда неудивительно видеть heapless кеширование и тд.
Если опираться только на негативный опыт, придется всунуть в реалтайм-ядро все плюшки GC, получить по лбу раз пятьсот и потом записать старый негативный опыт в позитивный. А буде случится вернуться на обычные веб-приложения — проделать все в обратном порядке.
При этом, если отталкиваться от возможностей и свойств, можно обнаружить, что GC имеет ряд вещей, которые сильно недетерминированы. Например невозможно предсказать, сколько будет работать этот GC в конкретном случае. Время отклика этого GC цифры ни о чем. Если сравнивать это с требованиями реалтайма, то, внезапно, еще до начала разработки есть целый ряд конфликтов и heapless решение нарисуется само собой. А вот уже дальше помогает негативный опыт — из всех heapless решений выбросить неудачные.
То есть, выходит так, что успешно-неуспешно тянет неявно определенный и очень жосткий контекст и все утверждения привязаны к этому конктексту. Человеку не в теме будет просто непонятно, как реюзать твой опыт. А если фокусироваться на возможностях и свойствах, то как минимум твой опыт будет реюзабельным самим собой даже в новых задачах.
Здравствуйте, Poul_Ko, Вы писали:
P_K>Здравствуйте, Аноним, Вы писали:
А>>Хотелось бы найти хорошие книжки по проектированию ERP и просто сложных систем (я не про использование паттернов),а про общую архитектуру.
P_K>В одной хорошей книге (к своему стыду, не помню уже в какой) было сказано, что хорошую архитектуру нельзя создать изначально, она должна родиться в процессе решения задачи. Поэтому вооружайтесь общими принципами, паттернами и здравым смыслом... да прибудет с вами Сила!
В книге Гради Буча это сказано, хотя наверняка не только в ней, а в любой книге, ведь это одно из фундаментальных свойств хорошой архитектуры — ее просто невозможно сделать такой с нуля. Даже если имеется иллюзия что некая архитектура получилось удачной с нуля, скорее всего просто был использован богатый опыт (сын ошибок трудных) других архитекторов, работавших над этой проблемой ранее.
А насчет ERP, то Фаулер тут вне конкуренции, правда некоторые его книги ужасно переведены на русский.
Здравствуйте, vl690001x, Вы писали:
V>А насчет ERP, то Фаулер тут вне конкуренции, правда некоторые его книги ужасно переведены на русский.
У него и контент ужасен, он устарел на 5 лет примерно. Описывает по сути реалии начала-середины 90-х годов, сегодня уже и проблем нет, которые он решает.
К сожалению ему альтернативы нет. Нету книг по современной архитектуре, приходится на практике все изучать.
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, qlat, Вы писали:
Q>>Здравствуйте, Аноним, Вы писали:
А>>>Доброе время суток Господа.
А>>>Хотелось бы найти хорошие книжки по проектированию ERP и просто сложных систем (я не про использование паттернов),а про общую архитектуру. А>>>Т.е в каких местах имело бы смысл делать так или иначе и хотелось бы с примерами небольшими.как те или иные задачи лучше реализовывать
А>>>заранее благодарен за ссылки
Q>>Любая ERP состоит из двух элементов Q>>1. Среда для разработки Q>>2. Сама ERP система Q>>Вы какую задачу решаете?
А>Написать проблем не составляет,написать грамотно,а вот тут уже задумываешься. А>Как и говорили про отклик UI. А>1)Никогда ранее не заморачивался но при работе с бд при плохой связи подвисает UI, использовать просто Thread ? или ThreadPool или таски чтобы не вешать UI(приложение не отвечает) на некоторых запросах ? А>2)Больше хочется понять какие процедуры лучше бы перенести на сторону SQL сервера, описав их в TSQL,а какие раскидать по dll, — на чём обьективно основывать этот выбор ? А>3)В некоторых вариантах развития ситуации возможно что система будет обрастать отчетами, как лучше реализовать связку данных с отчетом чтобы не пихать это всё в основной проект,а разнести это по dll(тут более интересен чей нибудь опыт)
А>Архитектуру я могу выстроить и "сделать чтобы работало", но к сожалению меня это перестало удовлетворять,я хочу делать более грамотно и красиво с точки зрения разработчика. А>Я понимаю что это все должно прийти с опытом,но к сожалению мне только года 2-3 назад довелось только дорабатывать 1 ERP,а в данный момент задачи стоят другие,но интерес не угасает. А>Очень благодарен за ваше понимание и любой ваш бесценный опыт!
1. Если для Вас написать в лоб проблем не составляет, то Вы уникальны, я хорошо знаю Axapta (около 9 лет в ней работал), и точно бы не смог реализовать всю логику системы (бухгалтерию, склад, производство, сводное планирование, расчеты с клиентами, зарплату и кадры, crm и т.д. )
2. обычно ERP работают с несколькими базами, поэтому у них свой язык (это касается среды разработки), ERP системы 3-х уровневые: клиент, серверная логика (пишется не на языке базы данных) и база данных (без sql — процедур). Логика ERP систем не содержится в dll-ках.
3. внутри среды разработки свой генератор отчетов, перед тем как его сделать, лучше создать среду для разработки.
Я сейчас как раз пишу среду для разработки, может через 2 месяца выложу результат работы. Первый вариант будет простой и двухуровневый (клиент + база), в качестве примера перенесу логику 1С 7-ки.
Базы SQL, Access, IB.
: IB>>1 вариант стоит 200$ капитальных затрат, 15$\месяц эксплуатационных IB>>2 вариант стоит 300$ капитальных затрат, 20$\месяц эксплуатационных
I>Девелопер таких вещей никогда не видит. У девелопера критерии свои, у тимлида — свои, у менеджера — свои, у сейлс — свои, у тестера — свои.
Вот очень плохо если не видят.
На самом деле видят все, только под ресурсом понимают разные вещи.
У девелопера — ресурс это его собственное время потраченное на решение задачи
У тимлида — ресурс это сумма времен всех девелоперов команды
У манагера — ресурс это деньги
В конечном итоге все ресурсы имеют денежный эквивалент.
Сейлсы и тестеры не должны принимать решения по технической реализации задачи. Их я не рассматриваю.
Здравствуйте, qlat, Вы писали:
Q>Здравствуйте, Аноним, Вы писали:
А>>Здравствуйте, qlat, Вы писали:
Q>>>Здравствуйте, Аноним, Вы писали:
А>>>>Доброе время суток Господа.
А>>>>Хотелось бы найти хорошие книжки по проектированию ERP и просто сложных систем (я не про использование паттернов),а про общую архитектуру. А>>>>Т.е в каких местах имело бы смысл делать так или иначе и хотелось бы с примерами небольшими.как те или иные задачи лучше реализовывать
А>>>>заранее благодарен за ссылки
Q>>>Любая ERP состоит из двух элементов Q>>>1. Среда для разработки Q>>>2. Сама ERP система Q>>>Вы какую задачу решаете?
А>>Написать проблем не составляет,написать грамотно,а вот тут уже задумываешься. А>>Как и говорили про отклик UI. А>>1)Никогда ранее не заморачивался но при работе с бд при плохой связи подвисает UI, использовать просто Thread ? или ThreadPool или таски чтобы не вешать UI(приложение не отвечает) на некоторых запросах ? А>>2)Больше хочется понять какие процедуры лучше бы перенести на сторону SQL сервера, описав их в TSQL,а какие раскидать по dll, — на чём обьективно основывать этот выбор ? А>>3)В некоторых вариантах развития ситуации возможно что система будет обрастать отчетами, как лучше реализовать связку данных с отчетом чтобы не пихать это всё в основной проект,а разнести это по dll(тут более интересен чей нибудь опыт)
А>>Архитектуру я могу выстроить и "сделать чтобы работало", но к сожалению меня это перестало удовлетворять,я хочу делать более грамотно и красиво с точки зрения разработчика. А>>Я понимаю что это все должно прийти с опытом,но к сожалению мне только года 2-3 назад довелось только дорабатывать 1 ERP,а в данный момент задачи стоят другие,но интерес не угасает. А>>Очень благодарен за ваше понимание и любой ваш бесценный опыт!
Q>1. Если для Вас написать в лоб проблем не составляет, то Вы уникальны, я хорошо знаю Axapta (около 9 лет в ней работал), и точно бы не смог реализовать всю логику системы (бухгалтерию, склад, производство, сводное планирование, расчеты с клиентами, зарплату и кадры, crm и т.д. )
Q>2. обычно ERP работают с несколькими базами, поэтому у них свой язык (это касается среды разработки), ERP системы 3-х уровневые: клиент, серверная логика (пишется не на языке базы данных) и база данных (без sql — процедур). Логика ERP систем не содержится в dll-ках.
Q>3. внутри среды разработки свой генератор отчетов, перед тем как его сделать, лучше создать среду для разработки.
Q>Я сейчас как раз пишу среду для разработки, может через 2 месяца выложу результат работы. Первый вариант будет простой и двухуровневый (клиент + база), в качестве примера перенесу логику 1С 7-ки. Q>Базы SQL, Access, IB.
1)предприятия бывают разные.
2)про 3-х уровненную систему интересно,а почему логику реализовывают именно на сервере,а клиентов цепляют к серверу,к чему такая сложность?для некоторых этот вопрос покажется естественным,но всё-же хотелось бы узнать...
я так понимаю есть
для какой цели?
ведь добавляя новый функционал к системе придется обновлять и сервер и клиентов.
Какие преимущества хранения логики на процессинговом сервере?
Здравствуйте, igor-booch, Вы писали:
IB>Вот очень плохо если не видят.
Надо полагать тебе как девелоперу отчитываются обо всех издержках, я ж не в курсе.
IB>На самом деле видят все, только под ресурсом понимают разные вещи. IB>У девелопера — ресурс это его собственное время потраченное на решение задачи IB>У тимлида — ресурс это сумма времен всех девелоперов команды IB>У манагера — ресурс это деньги IB>В конечном итоге все ресурсы имеют денежный эквивалент.
Это слишком упрощенно, что бы можно было хоть как то применять.
IB>Сейлсы и тестеры не должны принимать решения по технической реализации задачи. Их я не рассматриваю.
Девелопер — затратил на фичу два дня, всё палит.
Тимлид — сорганизовал команду что бы найти решение, которое реализуется в два дня.
Тестеры говорят — протестировать фичу надо два года в пересчете на одного человека. Затраты девелоперов после этого никому не интересны.
Сейлсы приходят и говорят — ваша классная реализация никому не нужна, денег не будет. Считаем эффект — денег 0, затрат вагон, эффект == 0.
Ну если никто с друг с другом разговаривать не будет, то картина у всех конечно будет разная.
Управление проектом (и система коммуникаций на проекте в частности) на это и направлено
чтобы у всех была единая картина,
чтобы действия всех работников были согласованы.
Если руководители для этого не предпринимают усилий, то команда развалится, в независимости от того что будет считаться критерием успешности
Здравствуйте, igor-booch, Вы писали:
I>>Итого — у всех разная картина.
IB>Ну если никто с друг с другом разговаривать не будет, то картина у всех конечно будет разная.
Понял. Наверное перед тобой сам гендир отчитывается. Завидую.
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, qlat, Вы писали:
Q>>Здравствуйте, Аноним, Вы писали:
А>>>Здравствуйте, qlat, Вы писали:
Q>>>>Здравствуйте, Аноним, Вы писали:
А>>>>>Доброе время суток Господа.
А>>>>>Хотелось бы найти хорошие книжки по проектированию ERP и просто сложных систем (я не про использование паттернов),а про общую архитектуру. А>>>>>Т.е в каких местах имело бы смысл делать так или иначе и хотелось бы с примерами небольшими.как те или иные задачи лучше реализовывать
А>>>>>заранее благодарен за ссылки
Q>>>>Любая ERP состоит из двух элементов Q>>>>1. Среда для разработки Q>>>>2. Сама ERP система Q>>>>Вы какую задачу решаете?
А>>>Написать проблем не составляет,написать грамотно,а вот тут уже задумываешься. А>>>Как и говорили про отклик UI. А>>>1)Никогда ранее не заморачивался но при работе с бд при плохой связи подвисает UI, использовать просто Thread ? или ThreadPool или таски чтобы не вешать UI(приложение не отвечает) на некоторых запросах ? А>>>2)Больше хочется понять какие процедуры лучше бы перенести на сторону SQL сервера, описав их в TSQL,а какие раскидать по dll, — на чём обьективно основывать этот выбор ? А>>>3)В некоторых вариантах развития ситуации возможно что система будет обрастать отчетами, как лучше реализовать связку данных с отчетом чтобы не пихать это всё в основной проект,а разнести это по dll(тут более интересен чей нибудь опыт)
А>>>Архитектуру я могу выстроить и "сделать чтобы работало", но к сожалению меня это перестало удовлетворять,я хочу делать более грамотно и красиво с точки зрения разработчика. А>>>Я понимаю что это все должно прийти с опытом,но к сожалению мне только года 2-3 назад довелось только дорабатывать 1 ERP,а в данный момент задачи стоят другие,но интерес не угасает. А>>>Очень благодарен за ваше понимание и любой ваш бесценный опыт!
Q>>1. Если для Вас написать в лоб проблем не составляет, то Вы уникальны, я хорошо знаю Axapta (около 9 лет в ней работал), и точно бы не смог реализовать всю логику системы (бухгалтерию, склад, производство, сводное планирование, расчеты с клиентами, зарплату и кадры, crm и т.д. )
Q>>2. обычно ERP работают с несколькими базами, поэтому у них свой язык (это касается среды разработки), ERP системы 3-х уровневые: клиент, серверная логика (пишется не на языке базы данных) и база данных (без sql — процедур). Логика ERP систем не содержится в dll-ках.
Q>>3. внутри среды разработки свой генератор отчетов, перед тем как его сделать, лучше создать среду для разработки.
Q>>Я сейчас как раз пишу среду для разработки, может через 2 месяца выложу результат работы. Первый вариант будет простой и двухуровневый (клиент + база), в качестве примера перенесу логику 1С 7-ки. Q>>Базы SQL, Access, IB.
А>1)предприятия бывают разные.
А>2)про 3-х уровненную систему интересно,а почему логику реализовывают именно на сервере,а клиентов цепляют к серверу,к чему такая сложность?для некоторых этот вопрос покажется естественным,но всё-же хотелось бы узнать... А>я так понимаю есть
А>а)процессинговый сервер(реализация логики). А>б)куча тонких клиентов.
А>для какой цели? А>ведь добавляя новый функционал к системе придется обновлять и сервер и клиентов. А>Какие преимущества хранения логики на процессинговом сервере?
в чем преимущества 3-звенки, их много
1. независимость от базы данных (oracle, sql, ib, dbf)
2. клиент не требует установки клиентов баз данных
3. клиент — это движок, он работает с метаданными (формами, таблицами, объектами, отчетами, запросами и т.д.), которые хранятся на сервере, поэтому изменение логики происходит без обновления клиентов, идеальный клиент web-клиент
4. своя удобная и быстрая среда разработки (работа с метаданными) это уход от sql — процедур, триггеров, поэтому требуется, чтобы логика отрабатывала на сервере по производительности аналогичном серверу БД. это и есть сервер приложения.
5. серверов приложения может быть много, а база данных одна.
I>>>Итого — у всех разная картина. IB>>Ну если никто с друг с другом разговаривать не будет, то картина у всех конечно будет разная. I>Понял. Наверное перед тобой сам гендир отчитывается. Завидую.
А Вы чему конкретно завидуете? Неужели Вам доставляет удовольствие когда перед Вами кто-то отчитывается?
Здравствуйте, igor-booch, Вы писали:
I>>>>Итого — у всех разная картина. IB>>>Ну если никто с друг с другом разговаривать не будет, то картина у всех конечно будет разная. I>>Понял. Наверное перед тобой сам гендир отчитывается. Завидую.
IB>А Вы чему конкретно завидуете? Неужели Вам доставляет удовольствие когда перед Вами кто-то отчитывается?
Это была ирония. Вот представь себе типичный аутсорс(наверное 80% всех проектов) — сделали и получили бабло. Успешно ? С точки зрения аутсорсера — да, успешно. Всё. Какие бы ни были технические решения — проект сдан, значит все они успешные.
Даже если заказчик вынужен будет еще три года допиливать этот проект, что бы хоть как то отбить затраты, для аутсорсера выше проект все равно успешный.
I>Это была ирония. Вот представь себе типичный аутсорс(наверное 80% всех проектов) — сделали и получили бабло. Успешно ? С точки зрения аутсорсера — да, успешно. Всё. Какие бы ни были технические решения — проект сдан, значит все они успешные. I>Даже если заказчик вынужен будет еще три года допиливать этот проект, что бы хоть как то отбить затраты, для аутсорсера выше проект все равно успешный.
Есть репутационные потери. Они тоже имеют денежный эквивалент. Посчитать его точно конечно нельзя, но можно экспертно оценить.
Здравствуйте, Ikemefula, Вы писали:
I>Критерий успешности какой ?
Общая сложность решения.
I>Какие гипотезы выносятся в эксперимент и что именно тебе дают результаты ?
Главный результат — опыт применения той или иной технологии, заключающийся главным образом в выявлении её недостатков и ограничений.
I>Мне кажется ты изобретаешь теорию принятия решений. Отрицательный опыт и положительный ничем не помогут в новой задаче.
Т.е. по-твоему любой опыт бесполезен? В принципе, если свой опыт совсем не анализировать, то я с тобой согласен. Но это не мой случай.
I>То есть, выходит так, что успешно-неуспешно тянет неявно определенный и очень жосткий контекст и все утверждения привязаны к этому конктексту.
Я объясню, почему отрицательный опыт более ценный и почему он помогает в дальнейшем отсекать заведом неверные решения. Дело в том, что неправильное решение гораздо проще проанализировать и выявить причины неуспешности. Вдумчивый анализ даёт довольно точный и главное ограниченный список этих самых причин. А вот успешное решение ограниченного списка причин успешности не имеет, этот список бесконечен. Это как ходьбы оп минному полю. Есть ограниченное число мест, где находятся мины и куда не стоит идти, а вот путей их обхода, если знать где они находятся, бесконечное множество.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, qlat, Вы писали:
Q>3. клиент — это движок, он работает с метаданными (формами, таблицами, объектами, отчетами, запросами и т.д.), которые хранятся на сервере, поэтому изменение логики происходит без обновления клиентов, идеальный клиент web-клиент
Практика показывает, что без клиентской логики хорошего клиента скорее всего не получится. Даже если это web-клиент.
Q>4. своя удобная и быстрая среда разработки (работа с метаданными) это уход от sql
Создавать свою среду разработки ради ухода от sql точно не стоит, это можно сделать намного проще. Да и вообще, на современном этапе создавать свою среду разработки не нужно никогда, потому что обеспечение того функционала, что дают современные IDE не под силу даже крупным корпорациям, если средства разработки не являются основной сферой их деятельности. А если ты этого функционала не обеспечишь, тогда твое средство будет сильно проигрывать в продуктивности, соответственно смысла в нем будет меньше нуля.
Q>5. серверов приложения может быть много, а база данных одна.
А кеши ты как между разными серверами будешь синхронизировать? Или кешей в твоих серверах нет?
... << RSDN@Home 1.2.0 alpha 5 rev. 100 on Windows 8 6.2.9200.0>>
AVK>Создавать свою среду разработки ради ухода от sql точно не стоит, это можно сделать намного проще. Да и вообще, на современном этапе создавать свою среду разработки не нужно никогда, потому что обеспечение того функционала, что дают современные IDE не под силу даже крупным корпорациям, если средства разработки не являются основной сферой их деятельности. А если ты этого функционала не обеспечишь, тогда твое средство будет сильно проигрывать в продуктивности, соответственно смысла в нем будет меньше нуля.
Здравствуйте, qlat, Вы писали:
Q>Пример 1С, Axapta, Sap
Это все создавалось в те времена, когда IDE современного уровня просто не существовало, а сделать продукт, хотя бы по некоторым параметрам сравнимым с чем нибудь типа VS6 еще можно. Это я не говорю о том, что в 1С все было настолько убого, что даже VCS прикрутить нельзя было. Но с тех пор в этой области очень очень много поменялось. Сейчас IDE без мощных средств анализа и автоматизированного изменения кода, поддержки VCS, расширяемости, современного редактора и прочих уже привычных вещей просто не нужна никому, кроме некоторых гиков, до сих пор пользующихся текстовыми редакторами для разработки.
Но самое интересное что почти все серьезные IDE (ну, как минимум, Eclipse, IDEA и VS) имеют широчайшие возможности по расширяемости в том числе и в плане поддержки собственных языков и платформ, и даже специальные инструменты для создания таких вещей, см., к примеру, DSL Tools в VS, или то что сейчас под эгидой Nemerle делается, или тот же MPS. Бери да пользуйся (хотя и тут трудозатраты для серьезных средств явно не по плечу одному человеку).
P.S. Ты, кстати, VS LightSwitch смотрел? Если нет, то стоит это сделать.
... << RSDN@Home 1.2.0 alpha 5 rev. 100 on Windows 8 6.2.9200.0>>
Если нам не помогут, то мы тоже никого не пощадим.
