Почему так много сайтов обсуждают программирование, а не описывают системы, которые они пытаются создать?[закрыто]
https://stackoverflow.com/questions/456349
-
19-08-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianВопрос
Существует множество сайтов, которые учат людей создавать лучшее программное обеспечение, но почему так мало сайтов, которые на самом деле дают подробные описания областей, которые мы (как программисты) должны создавать?Можно построить лишь определенное количество систем инвентаризации, учета и ERP, прежде чем между различными типами систем начнет проявляться закономерность общих требований.С точки зрения логики, если программисты тратят так много времени, пытаясь создать повторно используемые компоненты в своих архитектурах, означает ли это, что у них должен быть некий повторно используемый «чертеж», описывающий системы, которые они должны создать?Другими словами, создается впечатление, что при разработке программного обеспечения основное внимание уделялось тому, «как» программное обеспечение должно создаваться, а не каталогизировать и точно указывать (с подробными требованиями) «что» следует использовать в первую очередь.
Итак, мой вопрос заключается в следующем:Проводилась ли какая-либо работа по каталогизации всех различных типов системных спецификаций в одном месте и на одном сайте?Если отсутствие надлежащих требований в начале проекта является одним из проклятий разработки программного обеспечения, не было бы разумнее иметь возможность «повторно использовать» спецификации требований из предыдущих систем того же типа, которые уже были написаны?
Решение
Есть сайт Ответы базы данных , который пытается предоставить решения для типовых конструкций баз данных. Это не то же самое, что полное решение, которое вы описываете, но это шаг в правильном направлении.
Вы комментируете " [o] ne может создать только столько [...] систем до " общность становится очевидной. Однако те, кто построил достаточно таких систем, чтобы обнаружить общность, затем пытаются извлечь из нее выгоду, создав свою версию общей системы, а затем продают ее. Не в их интересах (как предполагается, что это) помогать другим людям, которые могут сделать то же самое, протянуть руку помощи.
Другие советы
Есть, но обычно ими управляют поставщики, желающие продать вам решение. : - /;
Я полностью согласен, где находится «Руководство Dummy по инвентаризации ИТ», аккредитованная модель данных для клиентов, адреса, контактные данные и т. д. и т. д. Я обнаружил, что заново внедряю один и тот же код в очень многих разных местах, с немного разные поля и логика, но в основном это одно и то же Несколько лет назад я нашел сайт с предварительно приготовленными моделями данных - маленький шаг в правильном направлении, но не весь рассказ Универсальные модели данных (без подключения). Вы заметите, что у них не было большого интереса к их продукту.
Я также работал в нескольких организациях, которые разрабатывали свою собственную «универсальную» модель данных как продаваемый продукт. Один был в области финансовых услуг, и они получили более 1500 таблиц DB2 и сдались. Организации гордятся своей уникальностью, в то время как мы (технические специалисты) понимаем, что большинство из них делают довольно похожие вещи - я думаю, что это может быть слишком вредным для корпоративного эго, чтобы признаться, и признаем, что они такие же, как и все остальные. использование UniversalCustomer (TM) 1.7. Кроме того, это делает эти компании зрелыми для SAP, Peopleware и т. Д.
В качестве последней мысли - здесь много низко висящих фруктов для предпринимателей. Достойный набор коротких книг с описанием общих доменов. Я имею в виду очень простые вещи, имя человека, адрес, телефон и т. Д. - со всеми маленькими недостатками, такими как заголовок в разных культурах и разметка номера телефона, - теперь есть книга / вики, которую могут использовать многие люди.
По моему опыту, когда он разваливается, есть варианты использования, охватываемые пользовательским интерфейсом. На самом деле я спроектировал и создал систему инвентаризации, которая применялась в широком спектре организаций и отраслей (телекоммуникации, продукты питания, здравоохранение, производство и распространение электроники, потребительские товары, одежда, авиакосмическая промышленность и многие другие). После первой половины дюжина, появилась хорошая модель данных, которая служила с небольшими вариациями (расширением, но не вариацией) для всех из них.
Но даже в рамках отрасли по ряду причин (характер продукта, изменение объема, средний размер заказа на входе и выходе, требования к бухгалтерскому учету, мотивация сотрудников и т. д. и т. д.) способ выполнения работы реальными людьми по разным причинам сильно различается.
Обратите внимание, что приведенные выше примеры, как представляется, касаются более глубоких уровней абстракции, в частности моделей данных, где мы, программисты, можем делать это по-своему, к нашей выгоде. Чем ближе к пользователю мы движемся, тем больше наши интересы должны стать второстепенными по отношению к их интересам.
Пример наихудшего случая. Кто-нибудь еще заметил, что в системах планирования работника и отчетности по рабочим часам кто-то еще показывал одну неделю на экран и многоэкранные формы ввода данных?
Ознакомьтесь с Книгой ресурсов модели данных Лена Сильверстона:
Он подходит к повторно используемому дизайну с точки зрения модели данных, в отличие от требований конечного пользователя или конструкций ОО. Тем не менее, я считаю, что это очень полезно - как только вы хорошо разберетесь в модели данных, у вас будет большой скачок в требованиях и объектах, которые в конечном итоге будут моделироваться как классы.
Это было бы невозможно продать. Первое утверждение, которое вы неизбежно получите от любого, кто распространяет RFQ для системы: & Quot; Мы не похожи на другие компании. Наши требования уникальны. & Quot; (И никогда не бывает.)
Если вы собираетесь повторно использовать требования, вы также можете повторно использовать код. Но на более низком уровне, я думаю, вы ищете & Quot; шаблоны требований & Quot; вдоль строк & Quot; шаблоны программирования & Quot;.
Теперь вот книга от Microsoft на Тема, но, как и во всех шаблонах доменов, идея заключается в том, что они должны органично расти и соответствовать потребностям пользователей и экспертов домена. Если вам нужен истинный источник идеи, ознакомьтесь с оригинальной книгой по шаблонам , хотя это из архитектуры, а не программирования, сюрприз-сюрприз:)
Был огромный & запрос на повторное использование программного обеспечения &; движение назад в 80-х и начале 90-х годов. Была значительная индустрия людей, создающих и настраивающих каталоги программных компонентов. Это было расценено многими как будущее программного обеспечения. Хорошим обзором является "& Уилл Трака" Признания продавца подержанного программного обеспечения &; Условия использования Google " IC Brad Cox Software " ;, " Martin Griss " ;. Насколько я помню, победа была объявлена, и все перешли к другим проблемам.
Я вижу, что предложение Брэда Кокса & Планирование промышленной революции в области программного обеспечения &; онлайн:
http://www.virtualschool.edu/cox/pub/PSIR/
Правительства предпринимают различные усилия для того, чтобы попытаться стандартизировать модели данных, чтобы обеспечить обмен данными между различными учреждениями, но они практически не принимаются за пределами того, что требуется. Например, в Канаде у нас есть CPSIN .
Возможно, вы захотите ознакомиться с шаблонами архитектуры корпоративных приложений . - хотя это и не спецификация, похоже, это то, что вам нужно.
Отказ от ответственности: я сам не читал, я знаю только о его существовании.
Было бы неплохо иметь центральное хранилище шаблонов кода со всеми языками. Тогда мы сможем продемонстрировать наш удивительный код, упростить обучение друг у друга, а также улучшить общее качество кода, имея хорошие примеры предоставления услуги / продукта xyz.
Я имею в виду, сколько наших уникальных проектов по написанию кода, которых никто еще не делал?
Я предполагаю, что 98% нашей работы - это то, что делали другие люди во многих компаниях, схожих отраслях, схожими функциональными потребностями.
Я имею в виду, что именно такой стековый поток должен отставать. Чтобы не только делиться и говорить о проблемах, но и учиться друг у друга.
Кто мог бы создать такое?Кто будет использовать это?
Насколько я понимаю, вы говорите о библиотеке проектов приложений.Люди, склонные делиться такими подробными проектами, уже делают это – в форме открытых спецификаций или открытого исходного кода.Первое, как правило, привлекает в основном людей и организации, уже участвующие в создании продуктов, реализующих такие спецификации, или продуктов, которые взаимодействуют с системами, которые их реализуют.Последний...ну, зачем переделывать дизайн, если можно просто взломать исходный код?
Как Марк Харрисон отмечает, там являются множество компаний, желающих продвигать свои разработки для общих бизнес-систем.«Купите нашу систему и просто закрепите функционал, необходимый для вашей организации», — скажут вам;«Зачем тратить время на повторное внедрение того, что мы уже сделали?» У них действительно очень мало мотивации, чтобы поделиться подробными характеристиками реализации, поскольку они действительно не хотят, чтобы вы переопределяли то, что они пытаются продать вам.
Окончательно...Эти вещи на самом деле не так уж и сложны.Вернее, они...но сложность рождается из размера, из бесчисленных комбинаций загадочных требований, которые любая организация может наложить на систему.Настоящая работа заключается в интерпретации этих требований, встраивании их в базовую систему – и, хотя это может быть утомительно, это неизбежно.
