Нет, не кажется. Это лишь частично спецификация. Второй частью – это автоматизация проверки соответствия результата этой спецификации. Т.е. заменять тесты только спецификацией – в корне неверно. Вы еще обязаны для полного замещения организовать автоматизацию на другой тип написания спецификации. Если другие типы написания спецификации и будут проще, то вот их автоматизация – навряд ли. Соответственно и сумма спецификации в другом типе и её автоматизации выйдет дороже, чем тесты.
Проблема изменения тестов при изменении внутренней реализации давно решена: тестируются не детали внутренней реализации, а единица поведения. Подробнее в книге Хорикова про модульное тестирование.
Пирамида тестирования утверждает, что каждая единица поведения должна быть проверена ровно 1 раз и на том самом нижнем уровне, на котором её можно проверить. Не все можно проверить на самом нижнем уровне – уровне модульных тестов без интеграций. Но если уж вы проверили что-то на более низком уровне, то на более высоком дублирующих тестов быть не должно, это же очевидно.
Как результат, ситуация "функционал одного и того же компонента покрывается многократно" невозможна. Более того, если тесты пишутся именно на поведение, а не на детали внутренней реализации, то проблем с рефакторингом не будет. Почему, очень хорошо объяснено в книге Хорикова про модульное тестирование.
Спасибо за статью. Лучшее описание типов, что я на данный момент встречал. Хотя я и не читал-то слишком больше, чем академических учебников, где все описывается сухо и на советских примерах (ой, кажется, у Вас тоже на них же :)
С нетерпением ждем пост про грамотную расстановку людей и соответствующие ссылки.
Это может быть человек с любым преобладающим типом. Даже "избегательный" – для него маленький стартап – это возможность делать еще меньше, другие работают, а он отдыхает. Внезапно.
Не совсем понимаю, как верифицированный телефон связан с неверефицированным почтовым адресом? Тем более для Минцифры. Ей надо было запросить у mail.ru верификацию телефона для соответствующего почтового адреса? А это законно?
Все остальное официальным ответом не является. Бабушки-операционистки на почтовом ящике об этом знают, а потому и не отвечают СМИ.
Я далёк от СМИ, но очень удивлён, что СМИ готовы публиковать неофициальные ответы бабушек-операционисток (по сути без проверки) только для того, чтобы опубликовать новость быстрее остальных.
Подождите, но почему Вы не направили обращение по указанной Вам ссылке?
Уже лет 8 точно, как гос.органы РФ принимают обращения на специальных страничках своих сайтов, а не по e-mail. Причина проста: e-mail анонимен, а обращения у нас в стране принимаются только не анонимные.
Вот сейчас введут закон о регистрации имейлов только по паспорту и обязательном подтверждении имеющихся в н-ный срок и сможете писать с подтвержденных госуслугами ящиков :)
Да и функциональная парадигма даже старше, чем ООП...
Сначала придумали функциональный подход и только потом, что-то в нем не устроило и пришлось до ООП расширяться...
Кстати, ООП не отрицает функциональной парадигмы. Все так же можно создавать объекты, объединяющие данные и функции вместе, при этом функции в таких объектах будут pure, объекты не будут иметь сайд-эффектов и состояния и т.д.
Там есть второй более важный принцип, про который, похоже, и Вы забыли...
Принцип этот делает этот вопрос и всю статью далее просто бессмысленной: "Но вопрос в другом - можно ли с ним работать? Понять, поправить, развить, не впадая в экзистенциальный кризис."
Принцип называется Open/Closed и сводится он к тому, что ранее написанное уже никогда не должно "правиться" и даже "пониматься". Если следовать этому принципу, то необходимость в этом пропадает, можно, не изменяя ни буквы в старом коде, расширять его под новое поведение. А если это невозможно (чего в реальности не бывает), то писать рядом новый код, если написание нового будет дешевле расширения старого... Таким образом достигается развитие без "экзистенциального кризиса".
А самое прекрасное – что чек-лист теперь уже можно и пытаться автоматизировать, шаг за шагом. Автоматизация "с нуля" всего процесса была бы неподъемной задачей, просто потому, что процесс не был формализован и описан. Теперь он формализован, описан, закреплен "на бумаге" – чего бы не взяться за автоматизацию с уже созданным на 80% по пунктам планом? :) Молодцы! Действительно полезная вещь!
Подскажите, пожалуйста, а зачем в iOS реализовывать свои запросы с помощью curl? В инструкции по КриптоПРО нет ничего про это. Такое ощущение, что библиотека КриптоПРО подменяет системный уровень, аналогично тому, как это устроено на Android.
И ни слова про обратные стороны сего забавного когнитивного искажения. А они в АйТи на каждом шагу. Проявляются примерно так: "Смотрите я тут гениальный роутинг для АйОС собрал! Вот вам инструкция на 145 листах, первые 48 листов описывают инструменты, которые вам нужно подготовить, чтобы этот роутинг у себя собрать. Все просто! И естественно, гениально!"
Вот бы такую же подробную и полезную статью, а что делать-то, если эффект Икеи проявляется в обратную сторону: товарищ сочинил, а теперь из него этот табурет велосипедом не выколотить, или наоборот.
По теме статьи. У Apple в UIKit есть реализация шаблона "Команда": селекторы, таргеты, responder chain, first responder. Цель шаблона в том, чтобы доставлять команды (в том числе на навигацию) от источника до исполнителя, т.е.от условной кнопки для пользователя до условного контейнер-контроллера (например, UINavigationController), который уже и осуществит навигацию (в данном примере - push).
По сути, это системная реализация вашего Навигатора.
Ну, а коли он у вас все равно работает с UIKit, то не пробовали ли вы заменить Вашу реализацию Навигатора на системную через responder chain, first responder, таргеты и селекторы?
5 лет прошло. Интересно, как выглядит в итоге Ваша навигация. Хотим и уже попробовали навигацию через UIKit (Свифт у нас старенький по объективным в РФ событиям, использовать последние версии не можем), видим в ней потенциал, но не хотим реализовывать Навигатор, т.к.кажется, что в системе это уже все есть. Хочется скорректировать наше направление, во избежание...
Нет, не кажется. Это лишь частично спецификация. Второй частью – это автоматизация проверки соответствия результата этой спецификации. Т.е. заменять тесты только спецификацией – в корне неверно. Вы еще обязаны для полного замещения организовать автоматизацию на другой тип написания спецификации. Если другие типы написания спецификации и будут проще, то вот их автоматизация – навряд ли. Соответственно и сумма спецификации в другом типе и её автоматизации выйдет дороже, чем тесты.
Проблема изменения тестов при изменении внутренней реализации давно решена: тестируются не детали внутренней реализации, а единица поведения. Подробнее в книге Хорикова про модульное тестирование.
Пирамида тестирования утверждает, что каждая единица поведения должна быть проверена ровно 1 раз и на том самом нижнем уровне, на котором её можно проверить. Не все можно проверить на самом нижнем уровне – уровне модульных тестов без интеграций. Но если уж вы проверили что-то на более низком уровне, то на более высоком дублирующих тестов быть не должно, это же очевидно.
Как результат, ситуация "функционал одного и того же компонента покрывается многократно" невозможна. Более того, если тесты пишутся именно на поведение, а не на детали внутренней реализации, то проблем с рефакторингом не будет. Почему, очень хорошо объяснено в книге Хорикова про модульное тестирование.
Для конкретизации п.5 вот даже целую детальную статейку набросали, почему так выходит...
Спасибо за статью. Лучшее описание типов, что я на данный момент встречал. Хотя я и не читал-то слишком больше, чем академических учебников, где все описывается сухо и на советских примерах (ой, кажется, у Вас тоже на них же :)
С нетерпением ждем пост про грамотную расстановку людей и соответствующие ссылки.
Это может быть человек с любым преобладающим типом. Даже "избегательный" – для него маленький стартап – это возможность делать еще меньше, другие работают, а он отдыхает. Внезапно.
Не совсем понимаю, как верифицированный телефон связан с неверефицированным почтовым адресом? Тем более для Минцифры. Ей надо было запросить у mail.ru верификацию телефона для соответствующего почтового адреса? А это законно?
Все верно. Месяц на официальный ответ.
Все остальное официальным ответом не является. Бабушки-операционистки на почтовом ящике об этом знают, а потому и не отвечают СМИ.
Я далёк от СМИ, но очень удивлён, что СМИ готовы публиковать неофициальные ответы бабушек-операционисток (по сути без проверки) только для того, чтобы опубликовать новость быстрее остальных.
Так и живем...
Подождите, но почему Вы не направили обращение по указанной Вам ссылке?
Уже лет 8 точно, как гос.органы РФ принимают обращения на специальных страничках своих сайтов, а не по e-mail. Причина проста: e-mail анонимен, а обращения у нас в стране принимаются только не анонимные.
Вот сейчас введут закон о регистрации имейлов только по паспорту и обязательном подтверждении имеющихся в н-ный срок и сможете писать с подтвержденных госуслугами ящиков :)
А дядя Боб сам приводил формулы – зачем повторяться?
Очень странно, что их никто не считает... Хотя на одном из последних мобиусов показывали попытки подсчета...
Все эти паттерны уже реализованы в iOS и очень часто встречаются:
Chain of Responsibility -> Responder Chain;
Mediator, Strategy -> UIViewController и т.д.;
Composite - это UIView, сабвьюхи и контроллеры с их деревьями;
фабрики, билдеры – можно смотреть на сториборды, нибы и конструкторы различных форм и видов различных классов, не только вьюх, контроллеров;
...
Лучше бы проанализировали, как шаблоны у Эпла реализованы, как используются, есть ли отличия, почему, что из этого следует?
Не сочиняйте своего, учитесь у лучших! Только так можно превзойти лучших. А если будет сочинить, максимум добьетесь того же...
Ждем переработку Вашего цикла.
Да и функциональная парадигма даже старше, чем ООП...
Сначала придумали функциональный подход и только потом, что-то в нем не устроило и пришлось до ООП расширяться...
Кстати, ООП не отрицает функциональной парадигмы. Все так же можно создавать объекты, объединяющие данные и функции вместе, при этом функции в таких объектах будут pure, объекты не будут иметь сайд-эффектов и состояния и т.д.
Вот тут подробнее.
.
а у меня не получалось такого руководителя удерживать рядом более 5 лет... в итоге более 5 рядом не соберешь никогда.
есть советы?
Там есть второй более важный принцип, про который, похоже, и Вы забыли...
Принцип этот делает этот вопрос и всю статью далее просто бессмысленной: "Но вопрос в другом - можно ли с ним работать? Понять, поправить, развить, не впадая в экзистенциальный кризис."
Принцип называется Open/Closed и сводится он к тому, что ранее написанное уже никогда не должно "правиться" и даже "пониматься". Если следовать этому принципу, то необходимость в этом пропадает, можно, не изменяя ни буквы в старом коде, расширять его под новое поведение. А если это невозможно (чего в реальности не бывает), то писать рядом новый код, если написание нового будет дешевле расширения старого... Таким образом достигается развитие без "экзистенциального кризиса".
Вот если бы новичкам об этом написали...
А самое прекрасное – что чек-лист теперь уже можно и пытаться автоматизировать, шаг за шагом. Автоматизация "с нуля" всего процесса была бы неподъемной задачей, просто потому, что процесс не был формализован и описан. Теперь он формализован, описан, закреплен "на бумаге" – чего бы не взяться за автоматизацию с уже созданным на 80% по пунктам планом? :)
Молодцы! Действительно полезная вещь!
Подскажите, пожалуйста, а зачем в iOS реализовывать свои запросы с помощью curl? В инструкции по КриптоПРО нет ничего про это. Такое ощущение, что библиотека КриптоПРО подменяет системный уровень, аналогично тому, как это устроено на Android.
И ни слова про обратные стороны сего забавного когнитивного искажения. А они в АйТи на каждом шагу. Проявляются примерно так: "Смотрите я тут гениальный роутинг для АйОС собрал! Вот вам инструкция на 145 листах, первые 48 листов описывают инструменты, которые вам нужно подготовить, чтобы этот роутинг у себя собрать. Все просто! И естественно, гениально!"
Вот бы такую же подробную и полезную статью, а что делать-то, если эффект Икеи проявляется в обратную сторону: товарищ сочинил, а теперь из него этот табурет велосипедом не выколотить, или наоборот.
Ознакомился, спасибо. Полезно.
Подскажите, а подобного обзора для современной навигации на SUI случайно нет?
По теме статьи. У Apple в UIKit есть реализация шаблона "Команда": селекторы, таргеты, responder chain, first responder. Цель шаблона в том, чтобы доставлять команды (в том числе на навигацию) от источника до исполнителя, т.е.от условной кнопки для пользователя до условного контейнер-контроллера (например, UINavigationController), который уже и осуществит навигацию (в данном примере - push).
По сути, это системная реализация вашего Навигатора.
Ну, а коли он у вас все равно работает с UIKit, то не пробовали ли вы заменить Вашу реализацию Навигатора на системную через responder chain, first responder, таргеты и селекторы?
5 лет прошло. Интересно, как выглядит в итоге Ваша навигация. Хотим и уже попробовали навигацию через UIKit (Свифт у нас старенький по объективным в РФ событиям, использовать последние версии не можем), видим в ней потенциал, но не хотим реализовывать Навигатор, т.к.кажется, что в системе это уже все есть. Хочется скорректировать наше направление, во избежание...
Добрый день. Устранили? Или это все же оказалась "фича"?