Войти
ФлеймФорумПрограммирование

хаос в основной приложухе #чист демагогия

Страницы: 1 2 3 Следующая »
#0
13:32, 5 апр. 2020

смотрю на свои проэкты со стороны.
пишешь там игрулю, редактор, конвертер.
делаешь модули классов нужных, все вроде красиво так,  минимум костылей. даже соблюдение правил написания хорошего кода по большинству.
начинаешь делать основную программу, и тут понеслось.
-ссылки форм друг на друга
-массивы с кнопками
-if then (case of) на страницу
-сохранение (на время) сущностей с управляемым временем жизни в 20 местах (где обязательно ее удержит какая нибудь ссылка, в форме другого вспомогательного окна).
-перекрестные эвенты.
-основной модуль на миллион строк, что листать не удобно. тем более искать ошибки.

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

PS читать статуструпов и других львов толстых из мира айти , не предлагать. чисто для понимания мироустройства интересно.


#1
13:42, 5 апр. 2020

Mira
> начинаешь делать основную программу, и тут понеслось.
Ну, а я, как бы, реже раза в неделю (когда не в бане), объясняю, отчего это и как бороться?

#2
13:47, 5 апр. 2020

gudleifr
я темы только про сиськи читаю или соседей про проектам / проэктам.
сам то придерживаешся этих правил? или тоже, вроде знаешь, знаешь но не делаешь?

#3
13:50, 5 апр. 2020

Mira
> сам то придерживаешся этих правил?
Разумеется (<тут было слишком толсто>). Только правилами я бы это не назвал. Это, скорее, понимание сути проблемы, позволяющее получать частные решения неразрешимой в общем задачи.

#4
13:53, 5 апр. 2020

Mira
а в начале, когда только собираешься начать, ты составляешь план программы с картой зависимостей?

ps: есть UML, но можно без него тупо нарисовать в пэйнте картинку "что, где, куда, зачем".

#5
13:55, 5 апр. 2020

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

#6
(Правка: 14:00) 14:00, 5 апр. 2020

programina
> ты составляешь план программы?

Это возможно только для простых задач. Для сложных получается как у ТС (по Кнуту):
1. сначала проходим сверху вниз, уточняя этот план,
2. потом снизу вверх, реализуя куски, как ТС описал,
3. а, затем... понимаем, что напортачили и приступаем к пересмотру (рефакторингу), приводящему обычно в полному выкидыванию программы и пересмотру плана.

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

#7
(Правка: 14:07) 14:00, 5 апр. 2020

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

вот проект редактора анимации, это просто хорошо переделанная демка mrShoor рисующая кубики из вершинного буффера. даже название приложение осталось "instancing". а все потому что было лень писать обертку для GAPI. а тут уже была самая низкоуровневая. собсно из начального проекта только окно рисующее персонажа а остальное 99.99% это огород поверх нее.

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

#8
14:09, 5 апр. 2020

Mira
> переписывать весь модуль из за смены расположения кнопок глупо
не должно такого быть.
Пиши весь функционал без привязки к интерфейсу везде где возможно, а в ивентах на реакцию интерфейса прописать уже готовые функции дело не долгое.

#9
14:16, 5 апр. 2020

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

+ Показать
#10
14:17, 5 апр. 2020

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

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

#11
14:18, 5 апр. 2020

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

#12
14:25, 5 апр. 2020

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

#13
14:28, 5 апр. 2020

Mira
> формошлепство изначально располагает к привязке.
> даже если посмотреть почти все демки для новичков, там все делается в событиях
> типа OnClick.
> в итоге логика программы по большей части оказывается в событиях GUI.
это делфя так просто приучает, но не обязывает. Ты можешь писать модуль полностью сосредоточившись на функционале, и потом уже пользоваться им в модуле формы.

#14
(Правка: 14:33) 14:29, 5 апр. 2020

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

Страницы: 1 2 3 Следующая »
ФлеймФорумПрограммирование