Как стать автором
Обновить
11
0

iOS Developer

Отправить сообщение

Спасибо за статью. Интересный материал. Хорошо прям проработан подход, но все-таки думается, что могут существовать ситуации, в которых для реализации бизнес-требований будет выгоднее использовать enum.
Предлагаю рассмотреть такой случай:
пусть в ленте 100500 итемов (ячеек) 15 разных типов (посты, клипы и т.д.) и нужно дать пользователю возможность выбирать из них два итема, но с обязательным условием, что итемы должны быть разных типов.
Например, если первой выбрана ячейка постов, то вторую можно выбрать "только-не-посты" (а например клипы) и наоборот.
Кажется, что тут будет выгоднее оставить пришедший из сети enum и паттерн-матчить по нему.

Если честно выполнить это:

мы пишем тест по принципу черного ящика, проверяя только входные и выходные параметры

То на основе вышеприведенных тестов нельзя быть уверенным, что метод createGreeting вернет "Welcome, ${name}!" для произвольного name.

Факт 100% покрытия - не может дать такой уверенности потому, что раз мы имеем дело с черным ящиком, то мы должны считать, что не знаем как реализована подстановка строк "Welcome, ${name}!". Например, "Welcome, ${name}!" мог бы для некоторых предопределенных name возвращать пустую строку.

Выглядит так, что приведенные тесты дают уверенность в правильном поведении, только когда мы прочитали код реализации и точно знаем как работает каждая операция.

Если же мы хотим уверенности работая с черным ящиком - то нам нужен тест проверяющий все варианты name. И в плюс к этому нужно откуда-то получить гарантию, что createGreeting - чистая (pure) функция.
Если нет гарантии чистоты createGreeting , то возможность использовать черный ящик пропадает полностью: для уверенности в правильной работе createGreeting нужно прочитать весь её код, найти обращения к методам зависящим от сайд-эффектов и протестировать её для [(все возможные сайд-эффекты) X (все возможные значения агрументов)].

Понятно, что для синтетического примера с подстановкой строки приведенные выше рассуждения выглядят надуманными. Но представим, что в createGreeting 10, или 20, или (как бывает в реальных проектах с миллионами строк кода) 100+ строк. И сразу рассуждения такого рода становятся насущной необходимостью.

Будет ли более верным сказать, что на практике TDD может работать только с "белым ящиком"?

Подобный материал на гитхабе JetBrains. На английском, но с симпатичными гифками и немного более подробными шагами. Последнее мне (как человеку далекому от Андроид разработки и Gradle) помогло.
Поздравляю с почином и желаю удачи!

Новое мобильное приложение, еще и in-house, и даже статья на Хабре — это повод надеяться, что банк решил повернуться лицом к физическим лицам (каламбур, да).
Насчёт самой статьи: написано как будто для руководства, а не для Хабра.

Аргументирую:
  1. Во втором предложении вводится термин «стримы». Откуда-кому знать, что назвали стримами в вашей конкретной компании? Да, неявная расшифровка есть, но намного позже.
  2. Обзор всего галопом. Всё в кучу: люди и их рассказы, старое легаси, новое приложение. Местами технические детали, местами по верхам. На мой вкус: нет рассказа, есть обрывки и маркетинговое продвижение: «мы крутые — у нас большая команда и новое крутое приложение».
  3. Про объем легаси — одна строчка «обновили более 1000 экранов». В итоге это осталось совсем незаметным. Пишу задним умом, но, судя по комментариям, стоило полнее раскрыть подробности того, что было, и сколько всего переделали.
  4. Вы переписали очень много кода, но цепочка рассуждений, которая приводит к тому, что компании это было нужно — разбросана по тексту и неполна. Если бы Вы выступали с этой статьей внутри компании — все бы всё поняли. Здесь же, естественно, это вызвало вопросы.
  5. Почему для компании плох тонкий клиент? Почему хорошо идти к омниканальности? Много вопросов, но почти всё не раскрыто. Кмк, лучше меньше, да лучше.
  6. «Новая архитектура на старом фундаменте» — а что осталось от старого фундамента в конце? Тоже не раскрыто.
  7. Даже раздел «Что мы получили» написан так, что точно понять, что произошло — не получается. В начале фраза: «В итоге мы полностью ушли от старого дизайна и сделали приложение в минималистичном стиле». Сделали новое рядом со старым и переливали трафик? Сделали полностью новое совсем начисто и выкатили обновление, заменяющее старое приложение? А зачем тогда обновляли старое на 1000 экранов, чтобы через месяц его заменить? Или сделали новое подновив кодовую базу старого? Таким образом даже главное, что произошло по тексту статьи — описано неконкретно. И дальше до конца раздела реклама «как стало хорошо» (что плохо).

Чтобы починить всё это — стоило бы дать вычитать статью нескольким «свежим» людям.

В завершение: ещё раз желаю успеха в работе!
Спасибо за статью!
Хотел бы предложить легенду перенести в начало и скрыть под спойлер для удобства, тех кто и так её знает. «Легенда в конце текста» — заставляет пробежаться вниз-вверх.
Классная статья, спасибо!
Разрешение зависимости с опорой на класс автоматически приводит к:
> Не получится закрыть зависимость протоколом
> Не надо регистрировать зависимости (вообще не надо)
> Извлечение из контейнера никогда не сломается
Эти плюсы и минус — разные стороны одной медали ;)
«генератор простых чисел из главы 8» — на самом деле из главы 10.
И перевод здесь точен. Казалось бы, ерунда. Но в итоге, вместо обсуждения примера, который предназначался в определенном контексте иллюстрировать определенные идеи, получается обсуждение того, как плохо, что данный пример — это не образец Абсолютно Идеального Чистого Кода.
Спасибо, да, у меня в комментарии ошибка по невнимательности. Прямо из начала упомянутой выше статьи Евгения в блоге RedMadRobot:
    «DI (внедрение зависимости, англ. Dependency injection)»
    «IoC (Инверсия управления, англ. Inversion of Control)»
Евгений как раз хорошо написал о различиях этих терминов и о том, почему они зачастую упоминаются вместе. У меня в статье больше про DI, конечно. IoC хоть и присутствует в «решении Василия», но явным образом об этом не сказано.
Спасибо, прочитал, раньше не попадалось)) Видимо это судьба: статьи об инверсии зависимости должны быть написаны каждым поколением снова и снова))
Кстати, рекомендую статью Евгения всем, кому нравится более спокойный стиль изложения. Также мне показалось интересным: взгляд под другим углом, другие акценты, более обширные и приближенные к UIViewController примеры.
На примере Swift, поэтому и протоколы)
И как корректно тестировать статик синглтоны?
Не очень сварщик в плане того, что нечасто удается писать тесты. Но тестирование синглтона — мне не видится проблемой. Синглтон: обычный класс со статическим полем, в котором лежит предсозданный экземпляр. Можно тестировать этот уже готовый экземпляр, а можно — создать ещё экземпляры, и гонять тесты на них.
Другой вопрос — это тестирование кода, в котором происходит работа с синглтоном. Но опять же, если синглтон инъектить как зависимость закрытую протоколом, то класс, в который синглон инъектирован, тестируется так же как обычно.
То есть с точки зрения тестируемости, синглтон может быть вполне безвреден.
Что касается
изоляция глобального публичного состояния
— тут, да, код выглядит довольно опасным. Все места в программе работающие с синглтоном будут работать с общим проперти dataArray, и если пользователь зачем-то начнёт работать с этим синглтоном из разных потоков, то начнется гонка за dataArray. Результатом станет емнип неопределенное поведение.
Спасибо, приятно получить положительную оценку. Мне стоило добавить примечание в начало. Немного поправил.
Я не автор оригинала, и я не работаю в LinkedIn.
Ого! Спасибо! Какая интересная ссылка. Думаю, вовсе не будет плохо, если я отправлю её автору.
промахнулся с ответом

Информация

В рейтинге
Не участвует
Откуда
Москва, Москва и Московская обл., Россия
Работает в
Зарегистрирован
Активность

Специализация

Mobile Application Developer
Senior
iOS development
SWIFT
Objective-C
UIKit
GCD