Раунд программирования считается одним из самых важных этапов в выборе разработчика. Кандидаты должны рассматривать этот раунд как демонстрацию своего таланта в программировании чистого и надежного приложения. Для разработчиков iOS, как правило, он содержит очень простое функциональное приложение, такое как приложение погоды, извлекающее и отображающее данные в пользовательском интерфейсе, но ваш код оценивается на основе стандартов кодирования рекрутинговой компании.
За последнее десятилетие я взял сотни интервью у разработчиков iOS. В коде есть распространенные ловушки, которые, если их избежать, могут превратить этот раунд в легкую прогулку.
Ниже приведены некоторые из хороших методов, которые кандидат должен использовать в своем коде:
- Архитектура
Приложение должно следовать единой архитектуре. При использовании старых архитектур всегда есть некоторые недостатки. Попытайтесь решить все проблемы в архитектуре, прежде чем отправлять окончательный код в репозиторий.
Пример: кандидаты обычно используют MVVM в качестве архитектуры в приложении, но не решают никаких проблем, связанных с жесткой связью, единой ответственностью или 100% тестируемым кодом.
Вышеприведенный код имеет две основные проблемы:
- Несмотря на то, что разработчик знает, LoginViewController не выполняет никаких функций без ViewModel. Экземпляр ViewModel является необязательным.
2. Тесная связь между ViewController и ViewModel.
Как устранить
- Чтобы устранить тесную связь, вы можете ввести интерфейс, который можно реализовать с помощью протоколов.
2. Чтобы решить необязательную проблему, вы можете выполнить внедрение зависимостей.
2. Безопасность
Это одна из самых важных парадигм при рассмотрении кода приложения. Исходный код не должен содержать никаких ключей доступа к API. Если вам нужно как-то использовать его, укажите в комментариях, где его хранить в исходном коде фактического производственного приложения. например, если серверная часть использует Azure, хранилище ключей Azure может быть местом для него.
3. Блоки завершения
Старайтесь избегать использования блоков завершения с несколькими параметрами, которые можно использовать для отправки данных родительскому вызывающему методу в асинхронных операциях. Блоки завершения задействованы в проблеме 2 степени n случаев, некоторые из которых даже не имеют смысла.
Предположим, что обработчик завершения имеет две переменные. Первая — необязательная кодируемая модель (для получения модели), а вторая — логическая переменная (для получения успеха/неудачи). Некоторые из этих возвращаемых типов не могут происходить или существовать в реальных приложениях, но ваши вызывающие функции должны обрабатывать их и даже ваши тестовые примеры.
Как решить
4. 100% тестируемый код
Исходный код должен быть на 100% тестируемым. Кроме того, каждый тест-кейс должен содержать только одну цель. Тестовые случаи не должны быть написаны только для улучшения покрытия кода. Например, приведенный ниже код считается плохим программированием, поскольку его нельзя полностью протестировать, если в код не будут переданы неправильные значения.
5. Функциональное модульное тестирование
Код, помещенный в репозиторий, должен содержать все функциональные модульные тесты. Кроме того, ни один модульный тест не должен провалиться при оценке интервьюером. Кроме того, старайтесь не думать, что юнит-тесты доводят покрытие кода до 100%, вместо этого старайтесь думать обо всех сценариях и соответствующим образом писать юнит-тесты.
6. Тестирование пользовательского интерфейса
Кандидат также должен написать тестовые примеры пользовательского интерфейса, чтобы оценщик знал, что кандидат знает об этом. Поскольку большинство разработчиков избегают написания UITestCases, это может дать вам несколько дополнительных баллов во время оценки. Обычно рассматриваемое приложение не может создавать проблем в производственной среде только в том случае, если имеет 100% автоматизированный функционал и UITestCases.
7. Используйте методы линтинга
Попробуйте использовать методы linting для решения распространенных проблем, таких как принудительное приведение и т. д. Вы можете использовать Swiftlint, если создаете приложение в swift.
8. Обработка ошибок
Попробуйте обработать ошибки, используя обработку ошибок в коде. Как правило, разработчики делают ошибку, обрабатывая два условия с помощью Bool, и если возникает третье условие, они преобразуют возвращаемый тип метода в необязательный Bool. Код не является надежным и совершенно нечитаемым в таких ситуациях, поскольку вы и единственный человек, который проходит через всю обработку, может понять ваш код.
Как решить
9. Соглашение об именах
Используйте правильное соглашение об именах. например, UIViewController должен иметь только имя в соответствии с представлением, а не в соответствии с содержащимися в нем функциями. Функция действия submit UIButton в LoginViewController должна получить имя как submitTapped/submitButtonTapped или что-то, относящееся к пользовательскому интерфейсу, но она никогда не должна получать имя функции как login, authenticationUser. Эти имена должны иметь смысл в вашей ViewModel или файле, который обрабатывает логику.
10. Страница «Прочитай меня»
Попробуйте создать read me и попробуйте рассказать об архитектуре приложения. Кроме того, вы можете указать, что было упущено во время разработки и что можно улучшить, если уделить больше времени программированию. Попробуйте создать небольшое видео о приложении и вставьте его на страницу .readme репозитория.
11. Ноль ошибок и предупреждений
Не пытайтесь использовать устаревший метод, который не разрешен в базовой версии iOS SDK, настроенной вами в проекте. Это также может дать вам отрицательные очки.
Дополнительный совет: добавьте совместимую версию Xcode и версию программного приложения, используемую для разработки приложения, чтобы во время оценки оценщику не отображались ошибки или предупреждения. Кроме того, я хотел бы порекомендовать использовать последнюю версию как Xcode, так и языка программирования, и упомянуть об этом при отправке.
Всем удачи в следующем раунде программирования :)
