Почему так много сайтов обсуждают программирование, а не описывают системы, которые они пытаются создать?

Ответ 1

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

Вы комментируете: "[o] ne может построить столько систем [...] до того, как" общность станет очевидной. Тем не менее, те, кто построил достаточно таких систем для определения общности, попытаются извлечь из этого выгоду, создав свою версию общей системы, а затем продадут ее. В их интересах нет (воспринимается), чтобы дать другим людям, которые могли бы сделать то же самое, что помогали.

Ответ 2

Есть, но они обычно управляются поставщиками, желающими продать вам решение.: -/;

Ответ 3

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

Я также работал в нескольких организациях, которые разрабатывали свою собственную универсальную модель данных в качестве товарного продукта. Один из них был в сфере финансовых услуг, и они получили более 1500 таблиц DB2 и отказались. Организации гордятся тем, что они уникальны, в то время как мы (технические) понимаем, что под капотом большинство из них делают довольно похожие вещи - я думаю, что это может нанести ущерб корпоративному эго, чтобы развеселить, и признать, что они такие же, как и все остальные с использованием UniversalCustomer (TM) 1.7. Кроме того, эти компании созрели для нескольких SAP, Peopleware и т.д.

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

Ответ 4

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

Но даже в отрасли по ряду причин (характер продукта, вариации объема, средний размер заказа в зависимости от требований к учету, мотивация сотрудников и т.д. и т.д.), как это делается реальными людьми по уважительным причинам сильно отличается.

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

Пример с наихудшим примером: Кто-нибудь еще заметил, что шаблон в системах планирования работ и отчетов о рабочих часах отображает одну неделю на экран и многоэкранные формы ввода данных?

Ответ 5

Просмотрите книгу ресурсов модели данных Len Silverston:

http://www.amazon.com/Data-Model-Resource-Book-Vol/dp/0471380237/ref=pd_bbs_sr_1?ie=UTF8& s = книги & QID = 1232336996 & ср = 8-1

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

Ответ 6

Это было бы непростительно. Первое утверждение, которое вы неизбежно получаете от любого, кто распространяет RFQ для системы, это: "Мы не похожи на другие компании. Наши требования уникальны". (И никогда не бывает.)

Ответ 7

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

Теперь вот книга от Microsoft по этой теме, но, как и во всех моделях домена, идея состоит в том, что они должны органически расти и соответствуют потребностям пользователей и экспертов домена. Если вы хотите, чтобы истинный источник идеи рассмотрел оригинальную книгу по шаблонам, хотя это от архитектуры, а не программирования, удивляет:)

Ответ 8

В 80-х и начале 90-х годов произошло огромное "повторное использование программного обеспечения". Существовала значительная индустрия людей, которые строили и настраивали каталоги программных компонентов. Многие рассматривались как будущее программного обеспечения. Хороший обзор - "Trats" "Исповедь продавца, использующего ПО"; google terms "Brad Cox Software IC", "Martin Griss". Насколько я помню, победа была объявлена, и все перешли к другим проблемам.

Я вижу, что Брэд Кокс "Планирование промышленной революции в промышленности" находится в режиме онлайн:
http://www.virtualschool.edu/cox/pub/PSIR/

Ответ 9

Правительства прилагают различные усилия, чтобы попытаться стандартизировать модели данных, чтобы обеспечить совместное использование между различными учреждениями, но они практически не принимают за пределами того, где это необходимо. Например, в Канаде CPSIN.

Ответ 10

Возможно, вы захотите проверить Martin Fowler "Шаблоны архитектуры корпоративных приложений" - хотя это и не спецификации, похоже, что-то вроде вещей вы после.

Отказ от ответственности: я не читал его сам, знаю только о его существовании.

Ответ 11

Было бы неплохо иметь центральный репозиторий шаблонов кода, все разнообразие языков. Затем мы можем продемонстрировать наш удивительный код, упростить обучение друг у друга, а также улучшить общее качество кода, имея хорошие примеры предоставления услуги/продукта xyz.

Я имею в виду, сколько из наших проектов кодирования уникально, что никто еще не сделал это?

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

Я имею в виду, что это тот факт, что stackoverflow должен отставать. Чтобы не только делиться и говорить о проблемах, но и учиться друг у друга.

Ответ 12

Кто создал бы такую ​​вещь? Кто будет его использовать?

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

Как Марк Харрисон отмечает, есть много компаний, желающих продвигать свои проекты для обычных бизнес-систем. "Купите нашу систему и просто закрепите функциональность, необходимую для вашей организации", они скажут вам; "зачем тратить время на повторное внедрение того, что мы уже сделали?" У них действительно очень мало мотивации для обмена подробными спецификациями реализации, поскольку они действительно не хотят, чтобы вы перепрофилировали то, что они пытаются продать.

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