Нужны советы по разработке игр

Здравствуйте,Я давно мечтаю создавать свои онлайн игры, Сейчас освоил базу си, покопавшись в нем понял что игр хороших на нем не слепишь, ни один день скитаюсь по форумам, читаю статьи и Решил. Начну изучать C++. Я знаю что разработка игр это нелегко и мне много чего нужно узнать, Я не знаю с чего начать. Сейчас любой совет на вес золота.
А больше мне нравится кодить и придумывать сценарий. Для моих будущих игр я уже придумал частичто свою историю.
Может это и покажется странным, но когда я смотрю прохождение игр, у меня включается во мне разработчик, и я начинаю думать с точки зрения разработчика. Как какая то механика могла быть реализована в коде.

Вобщем Буду очень благодарен вашим Любым полезным советам!

0

Сообщение от TRam_ Мелкие механизмы наоборот, имеют свойство плодиться

При отсутствии анализа так и происходит. При этом механизмы зачастую дублируют другие такие же по смыслу. А при анализе на предмет непротиворечивости набора сущностей эти механизмы очень быстро замыкаются в набор конечного количества. Хотя бы потому что непротиворечивый набор операций над сущностями дает на выходе любой операции сущности из исходного набора и никакие другие.

Добавлено через 5 минут

Сообщение от TRam_ Соответственно не во всякой первичной постановки их всех можно осмыслить и описать.

А пока они не осмыслены и не описаны кодить бесполезно. При этом описаны не имеется в виду обязательно толмуд текста и т.д. Толмуды нужны только когда команда большая. Если в одиночку то достаточно "пометок на полях" а то и просто в моску. Главное то в этом четкое понимание как оно должно фурычить без которого написать что то фурычащее анриал.

Добавлено через 8 минут

Сообщение от TRam_ Хотя зависит от задачи, в части случаев они конечно поддаются унификации на основе обобщённых алгоритмов, но не всегда

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

0

Сообщение от Fulcrum_013 а то и просто в моску

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

0

Сообщение от TRam_ Но вот от деления сущности/взаимодействия на всё более и более мелкие это никак не спасает.Поэтому и стараются и сущности, и их взаимодействия классифицировать и разделять на укрупнённые/обобщённые сущности.

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

Сообщение от TRam_ Вот в том то и проблема, что моск не резиновый

Солдат, если у вас голова вместо задницы, и вы не можете ничего запомнить, заведите себе записную книжку как это делаю я (c) Безымянный Генералиссимус.

Добавлено через 4 минуты

Сообщение от TRam_ Точно так же как движение галактики можно додробить до движения отдельных атомов её вещества, но это всё равно не предел

Если при этом не только дробить но и задавать механизмы комбинирования то из атомов можем скомбинировать все остальные сущности галактики. При этом набор молекул в огромное количество раз больше набора атомов. Если же додробим до основных элементарных частиц то путем комбинации соберем и сами атомы поимев для сборки всего-всего-всего всего лишь 3 сущности вместо 100+. Т.е. композиция декомпозиций - ну как бы основа основ проектирования архитектур и алгоритмов. Причем далеко не только в программировании.

0

Сообщение от Fulcrum_013 то из атомов можем скомбинировать все остальные сущности галактики

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

Но я о другом говорю. Что глубина декомпозиции в общем случае бесконечная. И что внутри атома есть нуклоны, внутри нуклонов - кварки, внутри кварков - струны и т.д.

Добавлено через 9 минут

Сообщение от Fulcrum_013 абсолютно все множество контролов и форм является комбинацией шейпа с рисунком и/или текстом либо составным контролом состоящим из таких единичных контролов

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

Добавлено через 14 минут

Сообщение от TRam_ Что глубина декомпозиции в общем случае бесконечная

И не только глубина. Как и в случае вещественных чисел, промежуточных уровней обобщения тоже можно построить бесконечно много.

0

Сообщение от TRam_ Что глубина декомпозиции в общем случае бесконечная

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

Добавлено через 10 минут

Сообщение от TRam_ Ага, и "взаимодействователя", который бы обрабатывал действия пользователя

Взаимодействователь сводится к редактору текста и хайду/шоу/смене стиля чего либо по клику/вхождению/выходу мыши. И все это уровень базового шейпа. Так кстати все браузеры и оконные апи и фурычат.

Сообщение от TRam_ то, если мы рассматриваем не только банальный клик мыши в области, а именно форму необходимого движения ею, то делать частный случая в разы менее затратно чем разбивать на обобщённые "куски движения"

Та ладно. Аппроксимация кривыми Безье потом сравнение по евклидовой дистанции вектора контрольных точек. Как результат дообучение любым жестам. Частные случаи будут по любому повторять тоже самое только в очень извращенном виде. Только это уже не к контролу относится а к системе жестов которая обычно не на уровне контролов вообще работает.

Добавлено через 32 минуты

Сообщение от TRam_ Что глубина декомпозиции в общем случае бесконечная

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

0

Сообщение от TRam_ И да, иногда ясность задачи увеличивается по мере её реализации.

я бы заменил "иногда" на "практически всегда". Если бы предметная область была на 100% известна - зачем тогда программу писать? Да и пользователи бывают весьма изобретательными в подборе исходных данных.

Сообщение от Fulcrum_013 Такого быть не может в принципе.

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

Сообщение от Fulcrum_013 из атомов можем скомбинировать все остальные сущности галактики.

И на моделирование этого процесса уйдет время, многократно превышающее время жизни галактики.

Сообщение от Fulcrum_013 К примеру абсолютно все множество контролов и форм является комбинацией шейпа с рисунком и/или текстом

А каким образом они должны обрабатывать нажатие кнопки? Будет ли это вызов функции или изменение значения, или drag-n-drop? Должен ли программист с самого начала обрабатывать нажатие любой кнопки, перетаскивание, прокрутку? Должен ли контрол содержать другие контролы? А сколько? Должен ли он позволять редактировать текст? Но зачем весь этот функционал в отдельной кнопке, которая реагирует только на нажатие?


Добавлено через 32 секунды
А да, чуть не забыл. Что там с решателем квадратных уравнений?

0

Сообщение от COKPOWEHEU Невозможно заранее предсказать какие параметры для данной задачи существенны, какие нет.

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

Сообщение от COKPOWEHEU Если бы предметная область была на 100% известна - зачем тогда программу писать?

ТАк вообще то первый и наиболее сложный этап разработки - анализ предметной области и постановка задачи в процессе которого все это и уясняется на 100%.

Добавлено через 5 минут

Сообщение от COKPOWEHEU А каким образом они должны обрабатывать нажатие кнопки? Будет ли это вызов функции или изменение значения, или drag-n-drop? Должен ли программист с самого начала обрабатывать нажатие любой кнопки, перетаскивание, прокрутку? Должен ли контрол содержать другие контролы? А сколько? Должен ли он позволять редактировать текст?

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

Добавлено через 9 минут
Т.е. суть - вместо того чтобы реализовывать по отдельности каждый из списка необходимых контролов, каждый со своим набором реализации прибамбасов, выясняется из каких вообще универсальных для всех контролов элементов они могут состоять, реализуется этот набор универсальных элементов, количество которого гораздо меньше количества типов контролов, потом сами контролы собираются из этого универсального набора механизмов. И вот именно такой подход позволяет сократить код на 90+% и избежать рефакторинага на 100%.

0

Сообщение от Fulcrum_013 Заранее - это до детального анализа предметной области и написания постановки. Вот именно поэтому и нет никакого смысла начинать писать код до завершения этих этапов.

Хорошо. Вы имеете полное право собирать всю информацию, хотя бы краем относящуюся к своей задаче. Этот процесс займет неограниченное время, поскольку копать "вширь" и "вглубь" можно до бесконечности, точнее пока не надоест. И все равно эти теоретические знания будут бесполезными без попыток их применения, чего вы, по вашим же словам, делать не будете из боязни рефакторинга.
Потом начнется процесс изобретения архитектуры. Тут есть два варианта. Первый (типичный): пишется прототип, на нем собирается максимально возможное количество граблей, не описанных в документации. Зачастую этот прототип сразу же тестируется в "боевых" условиях. Потом на основании собранных граблей и хотелок пользователей (а пока они не попробуют, конкретного мнения у них не будет) проводится рефакторинг и выпускается законченный продукт. Далее наступает сопровождение, поскольку хотелки у пользователей возникают постоянно, как и способы сломать программу, как и нахождение багов и пограничных случаев.
Второй вариант (идеалистический): разрабатывается идеальная архитектура, потом она реализуется, что в результате дает идеальный продукт. На практике же попытка учесть вообще всю собранную информацию приведет к попытке вызубрить все физические законы (без понимания) и пытаться решить практическую задачу. И даже если это каким-то чудом получится, любое изменение требований поломает всю тщательно настроенную систему, поскольку вы изначально делаете ее закрытой для изменений.
Ваш подход еще кое-как работает для примитивных встраиваемых систем, где влезть в конструкцию или провести обновление крайне сложно, а сам объем кода невелик. Но уже для встраиваемых систем высокой сложности он не работает вообще: слишком много информации, слишком часто меняются требования, слишком велика вероятность обнаружения багов или угроз.

0

Сообщение от COKPOWEHEU Первый (типичный):

Это не типичный. это идиотичный.
А типичный как раз классический подход к разработке.

Сообщение от COKPOWEHEU Второй вариант (идеалистический):

Этот как раз и есть реалистичный. Подавляющее большинство программных продуктов именно так и сделано. Исключение составляют разве что вебхеллоуверды.

Добавлено через 5 минут

Сообщение от COKPOWEHEU Ваш подход еще кое-как работает для примитивных встраиваемых систем,

Для сложных программных систем только этот подход и работает. Именно на таком подходе построены такие продукты к примеру как SolidWorks, Compass, 1C Bitrix и 1C бухгалтерия, VCL, QtWidgets, WinAPI и даже те же Unity, Unreal Engine, Cry Engine и вообще все что есть реально рабочего за исключением веб-хеллоувердов которые рабочими назвать можно разве что условно. Потому что это единственно возможный научно обоснованный подход к разработке.
Чем сложнее система тем менее применимы антинаучные срамо-агилы.

Добавлено через 10 минут

Сообщение от COKPOWEHEU поскольку вы изначально делаете ее закрытой для изменений.

Та нет уж батенька. Она изначально гораздо более приспособлена к изменениям чем ваше ловление граблей. Потому что количество вариантов сборки универсальных механизмов практически ничем не ограничено и не требует для этого рефакторинга компонентов.
И именно этот факт - неограниченность вариантов сборки и позволяет как граблей избегать так и быстро и гибко подстраиваться под изменения необходимые для более других ниш. Вы вообще в курсе, что к примеру SolidWorks, Katia и Siemens MX отличаются только UI обеспечивающим разные способы ввода команд одному и тому же движку?

0

Сообщение от cinemaster4d Нужны советы по разработке игр

в 21 веке игры уже не пишут кодом (аля принц персии 1989 года, и прочие пиксельные игрули).
кодом пишут движок, физику, звук, ИИ, и прочие компоненты среды для разработки игр.
а вот чтобы слепить всё это в одно нужна как раз таки среда, называемая software development kit (SDK).

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

если первое, то изучение C/C++ необходимо как мана небесная, т.к. все движки это сишный язык.
если второе, то чего вы забыли на этом форуме?
берете любой бесплатный SDK (например unreal engine udk, cryengine sdk, unity в конце концов) и на ютуб за видео уроки.
программировать здесь совсем не нужно будет, вы просто создаёте сцены, модели, шейдеры, свет и всё это объединяете в конструкторе в одно целое.

1

Сообщение от _lunar_ программировать здесь совсем не нужно будет

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

Сообщение от _lunar_ вы просто создаёте сцены, модели, шейдеры, свет и всё это объединяете в конструкторе в одно целое.

И знания бэкграунд математики для этого потребуются ничуть не меньшие чем для написания всего этого текстом.

Сообщение от _lunar_ берете любой бесплатный SDK (например unreal engine udk, cryengine sdk, unity в конце концов) и на ютуб за видео уроки.

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

0

Сообщение от Fulcrum_013 Не вводите человека в заблуждение.

я и не вводил, я написал так как оно есть.
не нравиться моё мнение, останьтесь при своём.
в чём проблема то?
остальной комент даже не читал, чушь..


ни грамма кода, а сцена готова.

1

Сообщение от Fulcrum_013 Первый (типичный): Это не типичный. это идиотичный. Второй вариант (идеалистический): Этот как раз и есть реалистичный.

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

Сообщение от Fulcrum_013 Именно на таком подходе построены такие продукты к примеру как SolidWorks, Compass, 1C Bitrix и 1C бухгалтерия, VCL, QtWidgets, WinAPI и даже те же Unity, Unreal Engine, Cry Engine и вообще все что есть реально рабочего

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

Сообщение от Fulcrum_013 Потому что это единственно возможный научно обоснованный подход к разработке.

Как раз разработка ПО далека от научно обоснованной. Это жуткая мешанина костылей и стилей разработки. Да и занимаются ей зачастую люди, слабо представляющие себе научный метод.
Или под своим способом вы понимали что-то другое, не то, что вы тут описываете уже которую страницу? Тщательный сбор требований, создание универсальных блоков, рассмотрение всех возможных комбинаций входных данных, выпуск единственной идеально работающей версии. Вы описали именно такое. На практике не наблюдается ничего из этого. И требования собираются сначала самые общие и по небольшому кругу пользователей, и задача изначально решается только одна, частная, и промежуточных версий сотни разной степени забагованности. Потом к этому клубку добавляется все новый и новый функционал, пока не назреет необходимость рефакторинга. Вот тогда кучу частных случаев сливают в универсальную функцию, перестраивают архитектуру и т.п. И именно для этого нужны те же юнит-тесты, чтобы после пересборки проверить не поломалось ли чего.
Естественно, все это несколько утрировано: хоть какая-то архитектура всегда нужна, от этого зависит гибкость кода и, следовательно, время между циклами рефакторинга. Часть функционала программист унифицирует сразу - насколько позволят его опыт и доступное время. Но вот фанатично копать информацию ради 1.5 случаев, которые случаются примерно раз в тысячу лет и вдвое усложняют программу, он все же не будет.
.
И вы упорно игнорируете конкретный пример с квадратными уравнениями. Какую конкретно информацию вы будете собирать для решения такой задачи? Какие случаи предусмотрите?

0

Сообщение от COKPOWEHEU Именно по "типичному" способы они и сделаны: непрерывный сбор изменяющихся требований, постоянный рефакторинг.

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

Добавлено через 1 минуту

Сообщение от COKPOWEHEU Как раз разработка ПО далека от научно обоснованной.

Вам это где вообще сказали? Вы что ликбез прогуливали что ли? Разработка софта это вид инженерной деятельности а соответственно живет на 100% на научном методе.

Добавлено через 2 минуты

Сообщение от COKPOWEHEU Да и занимаются ей зачастую люди, слабо представляющие себе научный метод.

Эти люди занимаются решением не более 1% задач индустрии. И то что их около 90% в индустрии никоим образом не делает этот маразм основным методом разработки. Наоборот это говорит о крайне низкой продуктивности срамо-агильного подхода.

Добавлено через 2 минуты

Сообщение от COKPOWEHEU И да, куча костылей и легаси в коде.

Ну вы для начала хоть один костыль найдите в коде к примеру VCL. А легаси он именно по тому что никогда не нуждался в рефакторинге, как в начале 90-х написали так до сих пор актуален. Даже при добавлении довесков, которые к примеру в абстрактный контрол VCL добавляются весьма часто, но при этом не требуют рефакторинга того что уже есть.

Добавлено через 15 минут
Новые же средства к примеру того же С++ при этом просто позволяют делать тоже самое что и легаси средства чуток меньшим количеством кода. И это реально круто для написания нового кода. Но пределка уже существующего кода который не требует рефакторинга по другим причинам на эти новые средства- ну это бесполезная трата времени которая не дает абсолютно никаких преимуществ. Так это С++ касается у которого новый стандарт с новыми вкусняшкуми каждые 3 года. А к примеру у дельфы практически ничего не добавилось с 90-х. Она сразу хорошо продумана была под свои цели и задачи, хотя в общем по языковым средствам сильно уступает даже плюсам середины 90-х, и за ними как раз ее и тянут за уши. Но как бы на продуманность архитектуры и т.д. это абсолютно никак не влияет. Вообще весь этот легаси-код который дожил до сегодняшнего дня обычно сделан на несколько порядков более грамотно чем современный срамо-агил и как результат и по сей день работает гораздо лучше срамо-агила того же направления, и будет пахать даже тогда когда срамо-агил давно схлопнется и про него давно забудут как про дот-комы конца 90-х.

Добавлено через 14 минут

Сообщение от COKPOWEHEU И именно для этого нужны те же юнит-тесты, чтобы после пересборки проверить не поломалось ли чего.

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

Добавлено через 13 минут

Сообщение от COKPOWEHEU И требования собираются сначала самые общие и по небольшому кругу пользователей

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

Добавлено через 10 минут

Сообщение от COKPOWEHEU И все равно эти теоретические знания будут бесполезными без попыток их применения, чего вы, по вашим же словам, делать не будете из боязни рефакторинга.

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

0

Сообщение от Fulcrum_013 Но опять же набор сущностей в любой предметной области в конечном счете тоже получается довольно ограниченным

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

0

Сообщение от COKPOWEHEU Потом к этому клубку добавляется все новый и новый функционал, пока не назреет необходимость рефакторинга.

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

0

Сообщение от Fulcrum_013 Да нет там никакого рефакторинга. Особенно рефакторинга ядра.

Ну-ну, запустите для примера какую-нибудь программу для win3.11 на win10. Уверен, у вас это получится без плясок, ведь "ядро не менялось".

Сообщение от Fulcrum_013 Как раз разработка ПО далека от научно обоснованной. Вам это где вообще сказали? Вы что ликбез прогуливали что ли?

А вам где наговорили той чуши, которой вы тут поливаете тему?

Сообщение от Fulcrum_013 Эти люди занимаются решением не более 1% задач индустрии.

Если бы! Как раз 90% задач не требуют особых знаний. Всяческие одноразовые утилиты, примитивная автоматизация, создание сайтов по готовому шаблону и т.п. гораздо более распространены, чем профессиональные инструменты.

Сообщение от Fulcrum_013 Вообще весь этот легаси-код который дожил до сегодняшнего

Ключевое слово выделил. Код, собранный по тем же принципам, но не доживший, вы скромненько не замечаете, а ведь его было в разы больше.

Сообщение от Fulcrum_013 Ну вы для начала хоть один костыль найдите в коде к примеру VCL.

Для начала расскажите про строки старого Паскаля и современного. Что служило признаком конца строки, какого типа каждый символ и т.д.

Сообщение от Fulcrum_013 Они не могут ничего проверить в принципе.

"я не знаю как пользоваться" != "не работает в принципе"

Сообщение от Fulcrum_013 Надеюсь очевиден факт, что переделка интерфейса требует полной переработки юнит-тестов.

А кто вас заставляет менять интерфейс библиотеки при рефакторинге? Наоборот, стараются максимально сохранить его даже при полном изменении архитектуры.

Сообщение от Fulcrum_013 Вообще юнит-тесты из лектроники пришли

Что вас заставляет думать, что в программировании они резко перестают работать?

Сообщение от Fulcrum_013 Пользователи вообще причем? Их то кто спрашивает?

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

Сообщение от Fulcrum_013 А сам набор сущностей в рамках данной предметной области из этих кирпичиков собирается какой угодно

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

1

Сообщение от TRam_ Пример вам уже приводили - если нужно искать только корни квадратного уравнения, вы будете создавать решение для уравнения произвольной степени?

Во первых давайте будем исходить из того что мы занимаемся ни разу не хеллоувердами уровня ЛР №1. В реальных задачах сложно найти предметную область которая требовала бы решения квадратного уравнения и при этом не требовала бы решения уравнений более высоких степеней. При этом решение именно квадратного уравнения так же как и уровнений 3-ей и 4-ой степени может иметь смысл выделить в отдельные функции, т.к. для этих частных случаев есть аналитические методы решения позволяющие найти все корни сразу а не по одному. Ну а в общем случае методам численного решения сугубо фиолетово какой степени и степени ли вообще уравнение.
Опять же задачи такого уровня как решение нелинейных уравнений и систем нелинейных уравнений достаточно тривиальны и комплексно решены и сведены в соответствующие библиотеки еще в 50-х и не требуют абсолютно никакого рефакторинга с тех пор. Кстати так о птичках главная причина долгожительства фортрана на суперкалькуляторах. Именно потому что правильно разделили задачи на предметные области и комплексно подошли к созданию универсальных наборов для их решения.

Добавлено через 39 секунд

Сообщение от COKPOWEHEU Как раз 90% задач не требуют особых знаний

Это как раз 1% задач по обработке информации.

Добавлено через 1 минуту

Сообщение от COKPOWEHEU А кто вас заставляет менять интерфейс библиотеки при рефакторинге? Наоборот, стараются максимально сохранить его даже при полном изменении архитектуры.

Дык чтобы его не менять нужно сразу с сущностями и механизмами взаимосвязей промеж ними определится а не путем ловления граблей. Как вы это сделаете без детального анализа?

Добавлено через 4 минуты

Сообщение от COKPOWEHEU А-а-а, так вы программы не для использования пишете, а из любви к искусству!

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

Добавлено через 4 минуты

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

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

Сообщение от COKPOWEHEU А на практике оказывается что весь из себя универсальный кирпичик неправильно работает на конкретном наборе входных данных из-за бага в архитектуре.

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

Добавлено через 1 минуту

Сообщение от COKPOWEHEU Или его понадобилось перенести на другую платформу с совершенно другим принципом работы.

Это где такие платформы то взялись с совершенно другим принципом работы? Квантовые компутеры пока что только в антинаучных фантастиках имеются.

Добавлено через 5 минут

Сообщение от COKPOWEHEU Что вас заставляет думать, что в программировании они резко перестают работать?

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

Добавлено через 23 минуты

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

Да это и без экстрасенсов ясно. То что сделано по результатам детального анализа предметной области и построено на покрытии задач предметной области проживет очень долго. Именно потому что сами предметные области меняются очень редко. К примеру за время существования тведотельных САПР (с начала 60-х примерно)произошло не более двух существеннх изменений, в предметной области. Вернее не изменений а расширений - матаппарат именно универсальных поверхностей расширился с поверхностей Безье до более общего их определения в виде НУРБС в 80-х и как результат в последующие годы метод конечных разностей расширился до метода конечных лементов.
А то что типа на спринтах и опросах пользователей строится забудут в подавляющем большинстве еще до релиза. Ну откуда бедному юзверю то знать как компу вместо него работу делать? Что то более-менее внятное на эту тему можно услышать разве что от бухгалтеров. Да и то как из той простыни видов начислений удержаний и т.д. сделать десяток универсальных управляемых данными кирпичиков для построения этих видов они не в курсах по определению.

Добавлено через 9 минут

Сообщение от COKPOWEHEU А на практике оказывается что весь из себя универсальный кирпичик неправильно работает на конкретном наборе входных данных из-за бага в архитектуре.

так вот про практику. Есть к примеру задачка сложения двух векторов. Ее можно решить двумя способами - создать класс вектор и перегрузить для него оператор сложения и написать само сложение один раз. А можно неуниверсально - в каждом месте где нужен вектор объявлять по три переменных и в каждом месте где нужно его суммировать писать по 3 операции сложения.
Вопрос - где будет меньше ошибок? И где их все быстрее заметят и исправят если они будут? И даже если использовать юнит-тестирование (которое для такой штуки реализованной в виде оператора кстати так о птичках весьма даже применимо потому что ветвлений оно не имеет а внутренние состояния обоих операндов легко задаваемы в самом тесте) какой код проще покрыть тестами?
Очевидно что в универсальной реализации.

Добавлено через 38 минут

Сообщение от COKPOWEHEU Ну-ну, запустите для примера какую-нибудь программу для win3.11 на win10. Уверен, у вас это получится без плясок, ведь "ядро не менялось".

Перекомпилировать - это по вашему пляска с бубном? К примеру основной набор компонентов VCL (и самое главное - ядро обеспечивающее технологию персистента) еще с 3.1 едет без рефакторинга. А многие элементы стандартной библиотеки типа стримов ввода вывода и т.д. еще со времен доса.

Добавлено через 26 минут

Сообщение от COKPOWEHEU "я не знаю как пользоваться" != "не работает в принципе"

Да то вы не знаете откуда у них ноги растут и с чем их едят, а поэтому и не понимаете как и где их можно эффективно использовать а где они просто мешают.
И даже того что эффективным может быть только взаимное тестирование 3+ алгоритмов, а никак не ручная подготовка контрольных данных для тестов, которая только увеличивает вероятность ошибки.

0

Сообщение от Fulcrum_013 При этом решение именно квадратного уравнения так же как и уровнений 3-ей и 4-ой степени может иметь смысл выделить в отдельные функции

Ага, вот и появились частные случаи.
Но вопрос был в другом: какие именно условия вы предусмотрите при написании программы решения квадратного уравнения? Будет ли там хотя бы проверка наличия корней?

Сообщение от Fulcrum_013 Это как раз 1% задач по обработке информации.

Я примерно это и написал: 10% задач по обработке информации, 90% примитивная автоматизация и формошлепство.

Сообщение от Fulcrum_013 Дык чтобы его не менять нужно сразу с сущностями и механизмами взаимосвязей промеж ними определится а не путем ловления граблей. Как вы это сделаете без детального анализа?

Допустим есть библиотека ввода-вывода, скажем что-то вроде stdio. Она написана для UNIX и использует его системные вызовы open, read, write и т.п. Потом ее решили портировать на DOS, где этих вызовов нет, зато есть другие с другими флагами. В лучшем случае все решится добавлением слоя абстракции, в худшем - переписывание всего кода. А потом решили портировать на AVR, где нет не только стандартных вызовов, но и вообще какой-либо работы с файлами. Там даже операционной системы нет и стандартного хранилища.
Очевидно, что внутренняя структура библиотеки будет меняться, но вот интерфейсы - нет (они вообще в стандарте прописаны).

Сообщение от Fulcrum_013 При этом пришли они из аналоговой лектроники где ни веток выполнения ни внутренних состояний то нет.

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

Сообщение от Fulcrum_013 Вот приходите вы к инжойнеру. Он че то там чертит пересечения какие то искает.

Вот приходите вы к инженеру, который чертит на куске миллиметровки и говорите "давай я тебе все это автоматизирую". Пишете замечательную программу, в которую вбиваешь координаты опорных точек для всех фигур, а она красивенько распечатывает на принтере. Со всеми размерами, полями и завитушками. А инженер смотрит на черный экран и не понимает как этим пользоваться. Вы пытаетесь его научить, рассказать, доказать что текстовый интерфейс удобный и быстрый. Инженер плюется, ругается, но переходит на вашу программу. А потом видит какой-нибудь, простите, Пейнт и "ух ты, тут же сразу видно что я делаю" - и переходит на него - пофиг что криво, пофиг что нормально размеры не проставить и по ГОСТу не выправить, зато интерфейс оказался удобнее. Собственно, на этом можно было бы закончить, поскольку никакие сборы исходных данных это предсказать не могут, но продолжим.
Как хороший программист, вы решаете добавить к своей программе интерфейс. Размер возрастает в несколько раз, зато теперь инженер может сразу видеть результат своих трудов, красиво оформить и т.д. Хэппи энд.
А потом он приходит и говорит: "всем хороша твоя программа, но мне тут часто приходится делать чертежи отдельных узлов, нельзя ли их как-то свернуть в блок, а то все тормозить начинает". Вы понимаете, что нужно добавлять блоки, слои и тому подобное. Но как это сделать, если исходная программа рассчитывалась на один большой лист? Сбор требований тут опять же не поможет, именно потому что инженер пока не знает как это можно сделать по-другому и к каким проблемам это приведет. И вот начинается процесс добавления ко всем объектам еще и номера слоя, управление отображением, переключение и прочее. В лучшем случае дело решится добавлением небольшого костыля (инженеру работать надо, а не любоваться архитектурой! Чем быстрее выпустите новую версию, тем лучше).
Надеюсь, суть понятна.

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

Я уже предлагал запустить программу для win3.11 на win10. Вам это уже удалось? А почему? Уж не потому ли, что кроссплатформенность языка это одно, а наличие платформо-специфичных библиотек - совсем другое?

Сообщение от Fulcrum_013 И не надо иметь экстрасенсорных способностей чтобы определить что работает он исключительно на том наборе который активирует единственную ветку вычислений которую проверял юнит-тест. А на остальных ветка полный абзец. потому что при рефакторинге реализации юнит тесты никто не перерабатывал и посчитал что если один частный случай отработал то типа функция полностью работоспособна

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

Сообщение от Fulcrum_013 Перекомпилировать - это по вашему пляска с бубном?

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

Сообщение от Fulcrum_013 И даже того что эффективным может быть только взаимное тестирование 3+ алгоритмов

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

0

Сообщение от COKPOWEHEU В лучшем случае все решится добавлением слоя абстракции

Вот как раз этим слоем и является стандартная библиотека языка. Единственная ее задача - сокрытие различий между апи ОС а не то что туда сейчас принято пихать.

Добавлено через 2 минуты

Сообщение от COKPOWEHEU а наличие платформо-специфичных библиотек - совсем другое?

таковой является стандартная библиотека языка.

Добавлено через 8 минут

Сообщение от COKPOWEHEU А потом видит какой-нибудь, простите, Пейнт и "ух ты, тут же сразу видно что я делаю"

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

Сообщение от COKPOWEHEU Собственно, на этом можно было бы закончить, поскольку никакие сборы исходных данных это предсказать не могут,

Могут. К примеру Банальный анализ общего назначения такой штук и как начерталки сразу выявляет что 2D интерфейс вообще не применим 3D онли.

Сообщение от COKPOWEHEU Как хороший программист, вы решаете добавить к своей программе интерфейс

Как хороший программист я на основе формата выходных данных определяю в каком виде их визуализация наиболее удобна для восприятия еще до начала написания кода. А на основе формата входных и возможных команд пользователя которые определяются из возможного набора операций по изменению данных определяю и то каким должен быть интерфейс для ввода команд. Если же мы касаемся конкретно САПР то даже не сам интерфейс а алгоритм генерации интерфейсов ввода команд.

Добавлено через 1 минуту

Сообщение от COKPOWEHEU исправляют ее и добавляют этот случай в тесты чтобы не повторилось в будущем.

Потом опять что то рефакторят в реализации и в этом же месте опять вылазит ошибка. Потому что ветки исполнения поменялись и тест без полной переработки нифига не тестирует.

Добавлено через 2 минуты

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

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

Добавлено через 8 минут

Сообщение от COKPOWEHEU Обычно же это тройная работа, которую никто без веской причины выполнять не будет.

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

Сообщение от COKPOWEHEU Обычно же это тройная работа

Не по этому. А потому что оно очень редко возможно. А без этого юнит тесты в общем то бесполезны.

0