![]() |
Тестовое задание.
Вложений: 3
|
Ну, в плане оптимизации здесь это не особо критично. Просто видимо хотели проверить знания по разным нюансам.
К примеру, длину массива не нужно просчитывать в цикле каждый раз. То есть лучше написать так: Код AS3:
Код AS3:
Второе. Известно, что доступ к константам всегда медленнее, чем доступ к локальным переменным. Поэтому можно было часто используемые константы внутри функций "прилепить" к локальным переменным. К примеру не использовать везде в функции вызов Math.PI а сначала присвоить ее значение локальной переменной var pi:Number = Math.PI; а потом уже использовать ее. По-поводу оператора switch. Здесь уже были темы с таким обсуждением, и приходили к выводу, что в ас3, if / else работает быстрее, чем switch. В отличие от некоторых других языков. Так что свич я бы тоже выкинул. Так же есть такая мелочь как вид записи Код AS3:
По логике, должна быть проверка типа, и после этого приведение к типу Boolean Код AS3:
Во многих языках первый тип записи вообще не позволит программе скомпилироваться. Это так, то, что можно сказать на вскидку |
А на мой взгляд - работодатель не прав. В задании нет ни единого намёка на оптимизацию кода. А идеально оптимизированным кодом, для такого простого примера, вряд ли кто-то заморачивается, только конечно если это не очень опытный программер, у которого уже просто привычка оптимизировать всё что только можно.
Уверен, если бы в задании был намёк на оптимизацию, то код товарища AtomicFlasher был бы другим. |
Цитата:
|
Пусть Ваш работодатель курит нервно в сторонке....
Начните свой проект! Не заморачивайтесь на этих жизненных мелочах. Нужно идти вперед. Станьте инди разработчиком. Поверьте пройдет время и вы поймете, что жизнь дает Вам шанс. Код достаточно хорош. А оптимизация - это отговорка... P.S. Нужна срочная работа, выйдите на фриланс-сайты |
Если придираться, то я вижу здесь 3 недостатка:
1. Отрисовка графиксом, а не битмапами (хотелось бы видеть ваш фпс на 5000 объектов). 2. Отсутствие инвалидации. Т.е. отрисовка идёт каждый фрэйм независимо от сохранности данных. 3. Нет явного MVC, хотя по сути Main - это контроллер, Planet - это модель, а Gui и Universe это вьюшки (рендереры) Но код достаточно понятный и чистый. |
В ТЗ ничего этого нет
|
Цитата:
Цитата:
2. Наверно не очень поможет - почти все двигается почти всегда. Но я подумаю об этом. 3. По-моему достаточно явное :) Как можно сделать его явнее в контексте такого маленького примера, чтобы это не выглядело как оверинжениринг? Наверно стоит пропускать отрисовку кругов, которые полностью закрыты каким-нибудь другим бОльшим кругом. Это легко проверять и, мне кажется, что это сильно уменьшит реально отрисовываемое количество объектов. Я выложу результаты, когда они будут готовы, если кому-то интересно. |
Цитата:
|
Цитата:
Сам принимал много тестовых заданий, причём со схожей тематикой. И просто по коду видно, как человек относится к некоторым вещам. Кто-то явно прописывает MVC-роли в именах классов, кто-то начинает подключать всякие фрэймворки, кто-то оптимизирует отрисовку блиттингоми и использует всякие инвалидации. Не всегда получившийся оверхед таких решений хорош для решения конкретной задачи, но иногда очень неплох для определения кругозора тестируемого. Одно из лучших решений просмотренных тестовых заданий на моём веку - это было решение от товарища ChuwY - он расписал по каждой задаче несколько вариантов решений, написал бенчмарктесты и описал в комментах лучшие и плохие стороны решения. Добавлено через 37 минут Цитата:
MainModel - содержит количество планет и лун PlanetModel, содержит соответственно модель планеты и лун. UniverseRenderer или MainView - рендерер вселенной GUIView - гуи. Когда имена сущностей более явные - сразу понятно, что некоторые вещи им нельзя позволять делать. |
| Часовой пояс GMT +4, время: 13:51. |
Copyright © 1999-2008 Flasher.ru. All rights reserved.
Работает на vBulletin®. Copyright ©2000 - 2026, Jelsoft Enterprises Ltd. Перевод: zCarot
Администрация сайта не несёт ответственности за любую предоставленную посетителями информацию. Подробнее см. Правила.