Худший враг программиста — долгосрочная актуальность

Programming

Что по-вашему будет труднее?

· решить проблему в коде;

· решить более масштабную проблему в коде

Да, я тоже так считаю.

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

Почему я говорю «не обязательно более сложные»? Потому что ваше видение будущего — ошибочно!

История из жизни!

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

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

Тогда я подумал: «Отличная идея, у меня уже есть написанный редактор графов! Им-то мы и воспользуемся!».

Иииии… получилось нечто низкопробное — как сэндвич из забегаловки.

Вообще-то я люблю Subway

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

Плохие решения

· старался делать все расширяемым;

· пользовался не самым четким визуализатором Unity API.

Плохие последствия

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

· Отсутствие масштабируемости (увеличения/уменьшения).

· Сложности с прилинковкой нодов — слоты слишком маленькие (и нет подходящего интерфейса, чтобы это исправить).

· Сложности с сериализацией — нужно синхронизировать нашу модель с Unity интерфейсом.

Первая версия редактора графов

Доработка решения

Пусть первыми бросят в меня камень те, кто ни разу не переписывал реализацию придуманных решений!

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

 

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

Хорошие решения

· Создавать простой и лаконичный интерфейс.

· Пользоваться средствами стандартного GUI-редактора и выкатывать свои интерфейсы визуализации (на деле все проще, чем кажется!).

Хорошие последствия

· Новые node-скрипты крайне компактны и расширяемы.

· Реализация масштабируемости (увеличение/уменьшение)!!!

· Проще подключать ноды, ведь мы сами программируем функцию столкновения «слот-мышь».

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

Приятные бонусы

· Выбор GameObjects в иерархии при клике на связанные ноды.

· Пинг нодов при изменении выбора в иерархии.

· В нодах может быть любой RGB-цвет (а ведь раньше было перечисление… жуть, да?)

· Проще изменять и анимировать реберную раскраску.

· Мы проделали массовое «обрезание» границ — как в ShaderForge (очень круто и полезно)

Текущая версия редактора графов

Что изменилось

Мы решили одну проблему дважды, но вторая реализация была в разы лучше.

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

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

Специально для сайта ITWORLD.UZ. Новость взята с сайта NOP::Nuances of programming