В статье фокус на нативной разработке под iOS, однако некоторые из рекомендаций, например, про сохранение мотивации, создание собственных pet‑проектов и стажировки (вот Яндекс активно ищет талантливых Flutter‑разработчиков) точно будут полезны. Также вступительная часть о важности базовых знаний в Computer Science, я думаю, актуальна для всех разработчиков независимо от выбранной платформы.
Из похожих роадмапов есть в закладках этот — можно другу передать 🙂. Надеюсь, будет полезен для изучения.
Действительно, у каждого будет свой подход к обучению и применению конкретных знаний в реальных проектах.
Статья охватывает спектр навыков, которые могут быть полезны в процессе обучения и устройства на работу, и дает некий "средний по больнице" срез требований. Однако, я полностью согласен с вами, на практике не все перечисленные знания будут использоваться в равной мере. Конкретные требования и набор навыков могут варьироваться в зависимости от проекта и компании. Так, знание простых алгоритмов сортировки проверяется сильно реже, чем разница между value и reference типами в Swift.
И также верно, что умение эффективно представить свои качества и навыки часто играет решающую роль в процессе найма. Хорошее владение коммуникацией помогает продемонстрировать свою способность работать в команде и доносить свою позицию.
Важно помнить, что каждый путь к успеху индивидуален, и множество факторов, а где-то и удача, влияют на процесс достижения цели - получение оффера.
В данном случае речь идет о состоянии конкретного экранного модуля приложения, которое реализовано согласно принципов MVC. Это состояние содержит информацию о том, как отображать данные из слоя модели, как их интерпретировать согласно пользовательского ввода, куда именно отправлять для дальнейшей обработки, какие части View скрывать при наступлении какого-то события и т.д.
Безусловно, я с вами согласен, что вне контекста статьи утверждение «В классической архитектурной метафоре Model-View-Controller состояние будет в контроллере» звучит дико.
Вы описываете систему как полноценный ИИ. Но по факту ведь это не так. У каждой системы есть критерии приемки (даже у Face ID надежность — 1 к 1 000 000, но Apple считает это допустимым для выпуска продукта на рынок). Их можно автоматизировать. Что-то — через модульные тесты, что-то — через интеграционные и т.д.
Да, иногда для полноценного тестирования системы нужно количество тестовых данных, которое вызывает комбинаторный взрыв. Так может быть. Тогда оставляют только крайние значения и что-то из середины, чтобы проверить соответствие критериям надежности. Но вот удостовериться, что для старта ракеты указаны правильные координаты стартовой площадки, не так уж и сложно. Тут одной проверки достаточно.
В том-то и дело, что нельзя. Диапазон всех этих величин — вся сетка координат. На эти данные программа может реагировать совершенно по-разному.
Для борьбы с диапазоном значений существует понятие классов эквивалентности тестов. Для обеспечения полноты покрытия можно использовать pairwise testing. С точки зрения программной реализации также будет полезным property-based testing. Для многих языков, в том числе и для C++, существуют готовые инструменты.
Это чисто формальный подход
Если тестировать по методу «черного» ящика, то неважно, как устроена внутри программа. Есть набор входных данных, есть набор ожидаемых выходных. Этого достаточно. Можно тестировать и по методу «белого» ящика. Оба подхода не отрицают друга друга, а лишь дополняют.
Все эти случаи я даже перечислить не могу
Тогда проблема не в сложности тестирования и его автоматизации, а в том, что у вас нет требований к системе. Без их фиксации разрабатывать тестовую модель бессмысленно. Если вы не знаете, что тестировать, то и тестировать нечего.
Ни разу я не встретил статьи, где бы тестировалось реальное, относительно крупное приложение на Си/Си++ по полочкам. А вот такая статья очень-очень нужна
За C++ не ручаюсь, но про то, как мы пишем тесты для iOS-приложения (Objective-C + Swift), расскажем в одной из будущих статей.
Можно было написать тест, что поставщик данных, который отдает их в блок математики, работает правильно. Одного теста на это достаточно. То, что математика работает верно, проверяется другими тестами.
В коде, который вы прислали, нет ничего специфичного. Есть интерфейс классов или функции модулей, на них можно написать модульные тесты. Или написать интеграционные тесты на их взаимодействие. Вопрос, как и какими инструментами писать тесты, выходит за рамки этой статьи.
И тем, и другим. Менеджменту бизнеса важен time to market, менеджменту IT — предсказуемость поддержки и сроков. Тесты — один из кирпичиков в фундаменте обеспечения этих потребностей.
О балансе между разными видами автоматизированных тестов говорит пирамида тестирования. Модульные тесты — самые дешевые в разработке: они быстрее остальных пишутся и отдельный тест дешевле и реже меняется по сравнению с другими видами тестирования. Поэтому количественно их должно быть больше всего в общем ряду.
Писать модульные тесты (как и любые другие) на все подряд (чтобы code coverage был почти 100%) — неверно. Я бы даже назвал это антипаттерном поведения. Вы правильно указали, что зачастую бывает достаточно закрыть модульными тестами только фундамент приложения, автоматизировать приемочные тесты, а все остальное отдать на откуп ручникам. На мой взгляд, это позволяет соблюдать баланс между качеством тестирования и скоростью реакции на изменчивые требования рынка во многих проектах.
Если постоянно все по кругу полностью переписывается и живет в романтическом духе стартапа, то вы правы, тесты тут ни к чему. Они только будут тормозить развитие. Автоматизированные тесты нужны тогда, когда вы что-то фиксируете на длительный срок. В этом случае ваш QA скажет вам спасибо, ведь, как написано в статье, самые простые ошибки программист с большой вероятностью устранит сам, и тогда на поиск сложных у QA останется больше времени.
Сложность системы и необходимость его тестирования — понятия, связанные друг с другом лишь опосредованно. Писать тесты нужно тогда, когда вам необходимо явно убедиться, что ваше ПО работает и не деградирует с течением времени. Тут неважно, простой ли это транслятор из SQL в JSON, или компилятор. Важно, долго ли вам это ПО поддерживать. Если это простой MVP, который нужно как можно быстрее довести до пользователя и потом переписать, автоматические тесты могут лишь сделать хуже бизнесу. И от них в этом случае лучше отказаться.
При таком подходе надо быть осторожным: можно получить ошибку Missing proxy for identifier UIStoryboardPlaceholder. Решения есть (например), но прежде всего надо быть внимательным, потому что используется не поведение по умолчанию, а некий недокументированный хак, который загружает view для контроллера из другого файла (xib'а).
P.S. Если это не хак, а документированное поведение, — дайте знать.
Не очень понятно, почему логика роутера (логика переходов) определена вместе с контейнером для самих контроллеров. При таком подходе для каждого варианта контейнера придется создавать свой базовый роутер. Более логично смотрится вариант с отделением логики переходов от контроллеров в отдельном объекте. Конечно, тогда контроллер будет вынужден что-то знать о роутере, но это нормально: контроллер должен быть главным объектом и, соответственно, общим связующим звеном.
Не очень понял, нужно ли проходит сертификацию PCI DSS, если я только хочу показывать свою форму для ввода карточных данных, а сами данные шифровать и передавать процессинговому центру. В начале статьи вы пишите:
Проходить ее (сертификацию) обязаны все компании, которые обрабатывают данные кредитных карт, даже если в процессе обработки эти данные не сохраняются.
Потом ниже:
Единственный вариант избежать сертификации — не обрабатывать данные пластиковых карт самому.… Данные карты можно зашифровать в браузере, используя публичный ключ, и отправить форму напрямую платежному шлюзу
Получается, шифрование не будет являться обработкой карточных данных? А кто гарантирует, что в рамках использования своей кастомной страницы продавец не занимается сохранением карточных данных?
В статье фокус на нативной разработке под iOS, однако некоторые из рекомендаций, например, про сохранение мотивации, создание собственных pet‑проектов и стажировки (вот Яндекс активно ищет талантливых Flutter‑разработчиков) точно будут полезны. Также вступительная часть о важности базовых знаний в Computer Science, я думаю, актуальна для всех разработчиков независимо от выбранной платформы.
Из похожих роадмапов есть в закладках этот — можно другу передать 🙂. Надеюсь, будет полезен для изучения.
Действительно, у каждого будет свой подход к обучению и применению конкретных знаний в реальных проектах.
Статья охватывает спектр навыков, которые могут быть полезны в процессе обучения и устройства на работу, и дает некий "средний по больнице" срез требований.
Однако, я полностью согласен с вами, на практике не все перечисленные знания будут использоваться в равной мере. Конкретные требования и набор навыков могут варьироваться в зависимости от проекта и компании. Так, знание простых алгоритмов сортировки проверяется сильно реже, чем разница между value и reference типами в Swift.
И также верно, что умение эффективно представить свои качества и навыки часто играет решающую роль в процессе найма. Хорошее владение коммуникацией помогает продемонстрировать свою способность работать в команде и доносить свою позицию.
Важно помнить, что каждый путь к успеху индивидуален, и множество факторов, а где-то и удача, влияют на процесс достижения цели - получение оффера.
Безусловно, я с вами согласен, что вне контекста статьи утверждение «В классической архитектурной метафоре Model-View-Controller состояние будет в контроллере» звучит дико.
Да, иногда для полноценного тестирования системы нужно количество тестовых данных, которое вызывает комбинаторный взрыв. Так может быть. Тогда оставляют только крайние значения и что-то из середины, чтобы проверить соответствие критериям надежности. Но вот удостовериться, что для старта ракеты указаны правильные координаты стартовой площадки, не так уж и сложно. Тут одной проверки достаточно.
Для борьбы с диапазоном значений существует понятие классов эквивалентности тестов. Для обеспечения полноты покрытия можно использовать pairwise testing. С точки зрения программной реализации также будет полезным property-based testing. Для многих языков, в том числе и для C++, существуют готовые инструменты.
Если тестировать по методу «черного» ящика, то неважно, как устроена внутри программа. Есть набор входных данных, есть набор ожидаемых выходных. Этого достаточно. Можно тестировать и по методу «белого» ящика. Оба подхода не отрицают друга друга, а лишь дополняют.
Тогда проблема не в сложности тестирования и его автоматизации, а в том, что у вас нет требований к системе. Без их фиксации разрабатывать тестовую модель бессмысленно. Если вы не знаете, что тестировать, то и тестировать нечего.
За C++ не ручаюсь, но про то, как мы пишем тесты для iOS-приложения (Objective-C + Swift), расскажем в одной из будущих статей.
В коде, который вы прислали, нет ничего специфичного. Есть интерфейс классов или функции модулей, на них можно написать модульные тесты. Или написать интеграционные тесты на их взаимодействие. Вопрос, как и какими инструментами писать тесты, выходит за рамки этой статьи.
Писать модульные тесты (как и любые другие) на все подряд (чтобы code coverage был почти 100%) — неверно. Я бы даже назвал это антипаттерном поведения. Вы правильно указали, что зачастую бывает достаточно закрыть модульными тестами только фундамент приложения, автоматизировать приемочные тесты, а все остальное отдать на откуп ручникам. На мой взгляд, это позволяет соблюдать баланс между качеством тестирования и скоростью реакции на изменчивые требования рынка во многих проектах.
P.S. Если это не хак, а документированное поведение, — дайте знать.
Потом ниже:
Получается, шифрование не будет являться обработкой карточных данных? А кто гарантирует, что в рамках использования своей кастомной страницы продавец не занимается сохранением карточных данных?