Что по-вашему будет труднее?
· решить проблему в коде;
· решить более масштабную проблему в коде
Да, я тоже так считаю.
Программирование сводится к решению проблем. Если вы рассматриваете код через призму долгосрочной актуальности, то эффективно решаете не обязательно более сложные и глобальные проблемы.
Почему я говорю «не обязательно более сложные»? Потому что ваше видение будущего — ошибочно!
История из жизни!
Мне нравится создавать инструменты для разработки игр. То есть, писать что-то для создания чего-то. Поэтому, иногда я пишу программы без практической значимости!
Все шло как по маслу. Но однажды в середине разработки DeMagnete мы решили воспользоваться неким редактором графов, который помог бы разработчикам игр проработать логику головоломки.
Тогда я подумал: «Отличная идея, у меня уже есть написанный редактор графов! Им-то мы и воспользуемся!».
Иииии… получилось нечто низкопробное — как сэндвич из забегаловки.
Дело в том, что при написании программ без практического применения, я принимал решения, которые могли бы стать настоящей головной болью, при их внедрении в реальные проекты.
Плохие решения
· старался делать все расширяемым;
· пользовался не самым четким визуализатором Unity API.
Плохие последствия
· Слишком расширяемая часть мешала в работе над простыми элементами (но даже так проект получался не самым расширяемым, ведь в то время я плохо разбирался во всех плюсах конфигурируемости).
· Отсутствие масштабируемости (увеличения/уменьшения).
· Сложности с прилинковкой нодов — слоты слишком маленькие (и нет подходящего интерфейса, чтобы это исправить).
· Сложности с сериализацией — нужно синхронизировать нашу модель с Unity интерфейсом.
Доработка решения
Пусть первыми бросят в меня камень те, кто ни разу не переписывал реализацию придуманных решений!
Обогатившись знаниями о недочетах первоначального API и детальных требованиях к нашему решению, мы смогли подобрать более надежное решение.
За выходные я смог создать эскиз нового графического редактора с нуля. В этот раз я четко понимал его назначение. Так появился более простой для реализации и работы интерфейс.
Хорошие решения
· Создавать простой и лаконичный интерфейс.
· Пользоваться средствами стандартного GUI-редактора и выкатывать свои интерфейсы визуализации (на деле все проще, чем кажется!).
Хорошие последствия
· Новые node-скрипты крайне компактны и расширяемы.
· Реализация масштабируемости (увеличение/уменьшение)!!!
· Проще подключать ноды, ведь мы сами программируем функцию столкновения «слот-мышь».
· Сериализация стала более надежной (как только мы разобрались с первоначальными проблемами хаха). Больше не нужно поддерживать два состояния синхронизации (представление и модель графа).
Приятные бонусы
· Выбор GameObjects в иерархии при клике на связанные ноды.
· Пинг нодов при изменении выбора в иерархии.
· В нодах может быть любой RGB-цвет (а ведь раньше было перечисление… жуть, да?)
· Проще изменять и анимировать реберную раскраску.
· Мы проделали массовое «обрезание» границ — как в ShaderForge (очень круто и полезно)
Что изменилось
Мы решили одну проблему дважды, но вторая реализация была в разы лучше.
Единственное, что изменилось: при первоначальном написании программы в ней не было практической необходимости, и она даже не возникла в прошлом.
В других моих инструментах/коде прослеживалась общая закономерность — у них отсутствовали реальные примеры использования. И не было ни одной программы, которую я смог бы повторно использовать без какого-либо дописывания/переписывания!
Перевод статьи Matheus Lessa: The Worst Enemy of a Programmer: Future Proofing
