![]() |
Почему мне отказали? - качество кода
Друзья, недавно, интереса ради, пытался сменить работу и в качестве собеседования у меня попросили посмотреть мой код.
Я выслал работодателю следующий класс: Код AS3:
Цитата:
|
|
Код AS3:
|
Цитата:
Подскажите, как я должен был поступить? Добавлено через 5 минут Цитата:
|
Судя по комментарию- как минимум, за наличие магических чисел.
|
Архитектура приложения, откуда выдран класс, очевидно неверная. Никаких обращений к родителям. Только родители решают, что им делать с подопечными.
|
1. Ничего не значащие имена переменных (назовите их нормально). Вместо "t", что-то типа updateTimer, хотя не понятно что он вообще делает в этом классе.
2. "Магические числа". Заведите константы для состояний и не сравнивайте числа как строки. 3. Постоянные обращения к вышестоящим объектам. Это нарушение принципа инкапсуляции. 4. Объект сам себя удаляет. Цитата:
|
> Объясните, пожалуйста, в чём мои ошибки и как их исправить?
Кода действительно мало. И то, что есть, плохое. 1. Обращение к объектам с логикой через DisplayList (это все ваши Object(this).root). А вдруг ваш root будет потом вложен в другой контейнер (мало ли, как изменятся требования)? Нужные объекты нужно через конструктор передавать и работать напрямую. 2. Вашему Sankship совершенно необязательно наследовать MovieClip. Он может создавать нужный клип и кто-то (он сам или пользователь класса) будет добавлять ui в список отображения. А сам класс останется контроллером. 3. Не понятно, кто такой IObstacle и зачем его implements ваш класс. Вроде бы методов из интерфейса нет. А маркер-интерфейсы обычно не нужны. 4. Совершенно не понятно, кто такое e3. Серьезно. Название должно отображать его логику. 5. Кто такие "2" и "3" - тоже не понятно. Это должны быть именованные константы. Литералы допустимы только в "натуральном" контексте. Это математика (там уместны числа, когда их назначение более-мене ясно). И строковые литералы для случаев, когда их содержимое явно обозначает назначение (т.е. константа звалась бы примерно так же, как сам литерал). 6. Самоубийство из DisplayList. Это плохо и, вероятно, не нужно. Удалять должен пользователь класса. Или сам класс, если он является контроллером и имеет ссылки на контейнер и UI. 7. Зачем у вас проверка t.hasEventListener(TIMER)? Она не нужна. removeEventListener вроде бы не ругается, если слушатель не существует. А вот у removeChild там же никакой проверки нет, хотя как раз parent может быть null (мало ли, кто еще ваш объект удалил из display list). К тому же dispose является публичной, так что может быть вызвана несколько раз (один раз из вашего обработчика таймера, например). 8. В checkCrush лично мне не нравится большая вложенность. if(!e3) return; 9. Там же какие-то поползнования и вызовы методов через display list. См. п. 1. Да и объект для hitTestPoint можно передавать в конструкторе, а не доставать из display list. Добавлено через 2 минуты > Понял, Вас смутило приведение к типу Object. Почему я так делаю, я не знаю. Ну так разберитесь, зачем вы это делаете. Вы должны быть в состоянии объяснить любое (абсолютно любое) решение в коде (выбор архитектуры/дизайна, выбор структур данных и алгоритом, выбор конкретных действий в коде). Программист должен хорошо понимать, как работает программа. Иначе нет никаких гарантий, что она вообще работает. |
Спасибо всем за ответы. Буду работать над собой.
|
Не пишите то, что не знаете как работает. Давайте нормальные имена переменным. Не используйте магических чисел.
Вот для начала. К Object лучше вообще не приводить, это "я не знаю, что это за штука и молюсь, чтоб у неё было то, к чему я обращаюсь". this.root - это ваш Document Class, к нему приводите. Ну и вообще советов уже понадавали) Про MVC я бы попозже разбирать советовал только. |
| Часовой пояс GMT +4, время: 02:18. |
Copyright © 1999-2008 Flasher.ru. All rights reserved.
Работает на vBulletin®. Copyright ©2000 - 2026, Jelsoft Enterprises Ltd. Перевод: zCarot
Администрация сайта не несёт ответственности за любую предоставленную посетителями информацию. Подробнее см. Правила.