И в этом случае страница будет «прикольно» прыгать по мере загрузки данныхв компонент что мы модем наблюдать на сайтах даже на самых авторитетных типа NYTimes.
В случае с NYTimes будет уместно задать вопрос: "Зачем вам Single Page Application, если вы не сильно сложнее, чем Wikipedia и можете использовать Multi Page Application?"
У baseView, ошибся. Нужен, если модель поменяли, привязаться к новой.
Я понял сам кейс, но не могу представить случай, когда в рантайме нужно будет поменять модель у компонента. Если это реальная необходимость, то функциональность всегда можно дописать, это же Software. За такую гибкость его многие и любят.
Про modelUpdated у базовой вью тоже не совсем верно. Так уж сложилось, что в реакте для этого принято использовать High ordered component
HOC — это же лишь подход, и при использовании MVC я им принебрегаю и обновляю компоненты при изменении модели. Плюс ко всему, как я написал в статье, мне не нравится сама идея Container Components.
хотя бы посмотрите где этот смалталк сейчас, а сколько реализаций с более привычным подходом
Не стоит презирать этот язык только потому что он сейчас не фигурирует на рынке. Благодаря Smalltalk мы с вами можем как пользоваться UI, так и программировать его. Smalltalk дал толчок развитию Apple и персональных компьютеров. Если будет время и желание. предлагаю прочитать The Early History Of Smalltalk.
вы все ещё превращаете реакт в кривую версию бэкбона, от чего в целом при его создании и пытались уйти
Но я же использую React по назначению — только как View. Моя реализация модели никак не отражается на удобстве его использования. А если вы видите, что отражается, то всегда можете изменить реализацию BaseModel и BaseView, я лишь направил вектор размышлений по направлению оригинального MVC.
Простой пример — если у вас есть несколько моделей, использующих одно и то же значение (фейсбук приводил в пример количество непрочитанных сообщений), то в стейте оно всегда будет храниться и браться из одного места, когда «модельки» же в свою очередь зачастую будут хранить свои экземпляры.
Не будет много моделек, Facebook обманывает :)
Будет модель Chat, которая содержит список Thread. Каждый Thread имеет количество непрочитанных сообщений. Chat суммирует количество всех непрочитанных сообщений в Thread'е и возвращает их с помощью getCountOfUnreadMessages(). При получении нового сообщения Thread оповещает Chat, что он обновился.
Вообще рекомендую ознакомиться с mobx, они делают что-то похожее, только на стероидах. Правда они тоже рекомендуют использовать единый стейт, и такой же connect.
На mobx заглядывался, но руками не трогал. Видимо, пришло время потрогать, спасибо.
У вас получился MV без C с последующими проблемами: жесткая завязка представления на модель с невозможностью подменять последнюю.
Создаем новую модель с таким же интерфейсом и заменяем старую, в чем проблема?
Controller есть — это callback'и onClick, onBlur и прочие.
Сontroller может быть связан только с одним View
Сильное заявление, проверять я его конечно же не буду.
Можете проверить, это несложно. Откройте описание MVC в Smalltalk-80 и найдите пункт "The View — Controller Link". В этом пункте написано:
Unlike the model, which may be loosely connected to multiple MVC triads, Each view is
associated with a unique controller and vice versa.
с непонятного перепуга модель должна знать о всех вью, на нее подписанных, так еще фактически убивается использование shouldComponentUpdate
Опять же цитата из описания MVC:
In that case the object which depends upon the model's state — its view — must be notified that the model has changed. Because only the model can track
all changes to its state, the model must have some communication link to the view.
…
When a new view is given its model, it
registers itself as a dependent of that model. When the view is released, it removes itself as a
dependent
Действительно можно использовать forceUpdate, спасибо. На самом деле нужно было у базового View реализовать метод modelUpdated(model: BaseModel), но я поленился.
Стандартный вопрос на собеседовании: почему так делать не стоит и как это писать правильно.
Меня очень удивляет, когда работодатель просить показать профиль на Github или выполнить тестовое задание, но при этом сам не имеет публичного Github-аккаунта или отказывается показать свой "закрытый" код. Я понимаю, что есть часть кода, которая содержит уникальные знания, приносящие прибыль. Но также есть инфраструктурная часть, утилиты для разработчиков, тестовые библиотеки, которые не обладают бизнес-ценностью, для меня остается загадкой, почему такой код не выносят на Github или хотя бы не дают с ним ознакомиться во время интервью.
Интервью — это диалог, в котором обе стороны принимают решение, а не монолог перед "учителем", в котором только "учитель" может давать оценку, но никак не наоборот. Надеюсь, в скором времени будет появляться больше компаний, которые понимают, что многие разработчики ищут работу, чтобы создавать качественный продукт и получать от этого удовольствие, а не сидеть в уютном офисе, в окружении команды профессионалов, кушая печеньки и фрукты, запивая все это кофе и различными сортами чая.
У Кента Бека, например, есть паттерны именования переменных. В книге "Smalltalk best practice patterns" он дает паттернам такое определение "A pattern is a decision an expert makes over and over."
Почему ценности Форда не коррелируют с ценностями автора статьи? Все цитаты взяты из книги "Генри Форд. Моя жизнь, мои достижения"
Ценность автора статьи: "Самое важное — сотрудничество"
В деловой жизни придавали слишком много цены титулам, и само дело страдало от этого. Одно из вредных последствий этого заключается в разделении ответственности между различными титулованными лицами; это заходит нередко так далеко, что уничтожается, вообще, всякая ответственность. Там, где ответственность раздроблена на мелкие доли между множеством ведомств, причем каждое ведомство подчинено шефу, который, в свою очередь, окружен венком подчиненных чиновников с красивыми, звучными титулами, трудно найти того, кто бы чувствовал себя, действительно, ответственным.
Всем, чему мы научились с течением времени, всем нашим уменьем и искусством мы обязаны нашим сотрудникам. Я убежден, что если дать людям свободу развития и сознание служебного долга, они всегда приложат все свои силы и все свое уменье даже к самой незначительной задаче.
Ценность автора статьи: "Второе — непрерывная адаптация"
Из подобного же самообмана, считающего жизнь сражением, которое может быть проиграно каждую минуту, благодаря ложному ходу, проистекает сильная любовь к регулярности. Люди привыкают быть лишь наполовину живыми. Сапожник редко усвоит «новомодный способ» подшивать подошву, ремесленник лишь весьма неохотно переймет новый метод труда. Привычка соблазняет к известной тупости, всякое препятствие отпугивает подобно горю или несчастью.
Это свидетельствует о дурном ведении дела — когда прибыль выжимается из рабочих или покупателей. Ее должно дать более искусное руководство делом. Берегитесь ухудшать продукт, берегитесь понижать заработную плату и обирать публику. Побольше мозга в вашем рабочем методе — мозга и еще раз мозга! Работайте лучше, чем прежде, только таким путем можно оказать помощь и услугу для всех стран.
Есть мнение, что такой тип визуализации — статический — подходит для печатных изданий. В нашу эпоху, когда персональные электронне устройства широко распространены, любой визуальной информации нужна динамика. Очень советую посмотреть впечатляющие доклады Bret Victor на эту тему: https://youtu.be/ZfytHvgHybA
А какие профессиональные качества программиста существуют в отрыве от процесса разработки? Спрашиваю не шутки ради, а потому что каждый человек по-разному представляет себе "правильный" набор профессиональный качеств.
Если говорить про веб и мобильную разработку, то лично мне сложно рассматривать профессионализм программиста в отрыве от процесса. Только лишь технические навыки не позволят выпускать продукт часто и с меньшим количеством ошибок. Если в компании принято "перебрасывать" продукт от программистов в тестирование и забывать о нем, то насколько бы хорошо программист не владел техниками написания тестов, его в такой компании скорее всего "сожрут", потому что он идет против существующих ценностей. Если в компании программисты отдают код в эксплуатацию и их не волнует его дальнейшая судьба, то новому программисту даже не дадут шанса провести созданный им код до боевого окружения самостоятельно, потому что это работа другого отдела. Если руководитель команды никому не доверяет декомпозицию user story, а только спускает на программистов конкретные задачи, то как бы программист не хотел взять на себя ответственность за оценку, декомпозицию и выполнение всей user story, ему эту ответственность не дадут, потому что он посягает на работу руководителя.
Или программист, который прикладывает все силы, чтобы выпустить в срок качественный продукт, который точно будет работать на боевом окружении — это ненастоящий профессионал?
Если не читали Extreme Programming Explained: Embrace Change (2nd Edition), то очень советую с ней ознакомиться, особенно с главами, которые касаются ценностей и принципов. Книга почти полностью про взаимоотношения людей, а не про технологии и техники и в вашей ситуации может пригодиться. Вот несколько цитат, чтобы заинтересовать еще больше:
I took two lessons from that experience. One is that no matter what the client says the problem is, it is always a people problem. Technical fixes alone are not enough. The other lesson I took was how important it is to sit together, to communicate with all our senses.
The biggest problem I encounter in what people “just know” about software development is that they are focused on individual action. What actually matters is not how any given person behaves as much as how the individuals behave as part of a team and as part of an organization.
Value in software is created not just by what people know and do but also by their relationships and what they accomplish together. Ignoring the value of relationships and trust just to simplify the scheduling problem is false economy.
In software development, “perfect” is a verb, not an adjective. There is no perfect process. There is no perfect design. There are no perfect stories. You can, however, perfect your process, your design, and your stories.
Обидно, что проводить такие эксперементы и менять культуру внутри компании позволяют только специальным людям, а не разработчикам.
Agile != (scrum + kanban). Agile в смысле Agile Manifesto — это нечто куда большее.
Именно! Только это большее мало кто понимает, начинают "внедрять Agile", а потом он почему-то "не работает". Extreme Programming Explained: Embrace Change (2nd edition) отлично рассказывает и про ценности, и про принципы эффективной работы, которые важны намного больше, чем конкретные практики.
Манифест гибкой разработки программного обеспечения (http://agilemanifesto.org) появился более 15 лет назад. О "Agile" стали говорить на конференциях, выбросив из гибкой разработки все ее ценности и принципы кроме одного “Deliver working software frequently, from a
couple of weeks to a couple of months, with a
preference to the shorter timescale”. Сейчас слово “Agile” можно встретить в вакансиях практически каждой компании. Эти компании все также продолжают работать по водопаду, сохраняя развесистую иерархию, планируя и проектируя наперед и перебрасывая задачи из одного отдела в другой, но с более короткими итерациями."Agile” организации схватились за инструмент в виде коротких итераций, сохранив привычные процессы, а значит продолжают ценить процессы и инструменты больше, чем людей и их взаимодействие. То есть не принимают первую ценность гибкой разработки “Individuals and interactions over processes and tools”.
Принципы, следующие из первой ценности, которые разделяет автор статьи, но не организации, описанные выше: "Business people and developers must work together daily throughout the project”, “Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done”. Невозможно совмещать несколько ролей в организации, которая ценит фиксированные роли и четкое разделение обязанностей. Невозможно добиться доверия там, где ценится сокрытие реального положения дел. Невозможно следовать любым принципам, которые основываются на ценностях, отличных от действительных ценностей организации.
В конечном итоге, настоящие ценности — это самое важное, что есть в организации. Все остальное: используемые технологии, процесс принятия решений, способы коммуникации и постановки задачи, организационная структура и прочее, вытекают из ценностей. Автору статьи, видимо, не удавалось понять ценности организации во время собеседований. Мне тоже еще ни разу не удавалось их понять. Хабравчане, есть ли у вас подходы к выяснению настоящих ценностей компании во время собеседований?
Есть смысл соблюдать DRY, только когда логика, которую можно обобщить, уже выражена в коде. Если логика для обобщения находится только в голове у автора, скорее всего, полученный в итоге DRY-подобный код будет сложно переиспользовать, он будет казаться чужеродным в остальных частях приложения. По-сути это одна из форм проявления преждевременной оптимизации.
class ColourMix:
def __init__(self, colours):
self.colours = colours
def print_colours(self):
for colour in self.colours:
print(f"Colour RGB: ({colour.red}, {colour.green}, {colour.blue})")
При разработке другой части приложения клиент не хочет раскрывать реализацию и опирается только на интерфейс. Но интерфейс не говорит ничего о том, чем же является colours, и что он содержит внутри. Тогда единственным способом работы с данным классом является чтение его реализации и поиск всех методов, которые он дергает у colours и элементов colours. Это неэффективно и замедляет разработку. Если явно сказать, что colours — это список, содержащий объекты-значения, то в реализацию не нужно раскрывать:
from typing import NamedTuple, List
class Colour(NamedTuple):
red: int
green: int
blue: int
class ColorMix:
def __init__(self, colours: List[Colour]):
self.colours = colours
def print_colours(self):
for colour in self.colours:
print(f"Color RGB: ({colour.red}, {colour.green}, {colour.blue})")
Но при этом мы не лишаемся возможностей, которые предоставляет нам утиная типизация, только теперь нам известно, что для работы ColourMix нужен объект, который реализует интерфейс списка, причем не обязательно наследованием от списка.
Если у нас есть .get, то нам всё равно у какого он типа. Если у метода есть .next(), то мы можем его итерировать.
Это, конечно, верно. Статья о том, что интерфейс объекта должен явно говорить о наличии .get или .next.
Для таких вещей есть @staticmethod, а функция нас не «обманывает», так как в нормальном режиме (как член класса) она имеет ещё и self в аргументах.
self в аргументах ничем не поможет, если в конструкторе будет внешняя зависимость:
from utils import DatabaseConfig
# DatabaseConfig предоставляет доступ к конфигу,
# который хранится в БД
class PasswordUtils:
def __init__(self):
self.min_length = DatabaseConfig().password_min_length
def is_password_valid(self, password: str) -> bool:
return len(password) > self.min_length
Инстанцирование класса в "неправильном" окружении снова возбудит ошибку. Функция или метод класса — это инструменты для демонстрации примера внешней зависимости, которая раскрывает реализацию. Суть примера не в применяемых инструментах, а в необходимости явной передачи всех внешних зависимостей.
Паттерны разработки — это борьба со сложностью программ. Если в приложении в нескольких местах есть повторяющийся код инстанцирования и настройки объекта, я вынесу его в фабрику — единое место для получения "готового к работе" инстанса — и не важно, на каком языке я программирую. Необходимость инкапсулировать сложное создание объекта не зависит от языка, а вот реализация зависит. Паттерны рассказывают о том, как увидеть эту необходимость, а не о том, какой конкретно код нужно писать.
А с чего бы это вдруг? Команда разработки будет делать эти тесты как? Коллегиально, каждый по 100 строк? Фронтендеры или бекэндеры, кто лучше справится?
Один из вариантов: GUI End-to-End покрывают фронтенд-разработчики, API End-to-End — бэкенд-разработчики. Фичи же получается как-то коллегиально делать, с автотестами тоже не возникнет проблем.
Чтобы разрабатывать End-to-End тесты, разработчики внезапно должны залезть уж очень глубоко в бизнес-домен
По-моему писать бизнес-логику, не понимая как должен будет выглядеть конечный результат, довольно странно. А для понимания конечного результата придется залезать в бизнес-домен в любом случае.
И правильно делают, что начинают с нее — первые 10 строк GUI-тестов заменят первые десять тысяч строк юнит-тестов.
Если стоит задача создать хоть какое-нибудь покрытие автотестами проекта, на котором отсутствуют автотесты, правильнее начинать с небольшого количества End-to-End тестов, и продолжить спускаться на более низкие уровни. Но когда в создании автотестов заинтересована только Automation QA команда, этого спуска не происходит, и все заканчивается на End-to-End.
Ничего подобного, если есть CI.
Это действительно возможный вариант. влияния отдела Automation QA на разработку, если разработка и менеджмент доверяют и понимают результаты прогонов с CI.
Автотест не бывает «нестабильный» просто так
Просто так не бывает, но в End-to-End тестах бывает чаще, чем в других. Как минимум из-за взаимодействия с системой через пользовательский интерфейс, который иногда бывает довольно изменчив. Если с разработчиками фронтенда удается выстроить работу так, чтобы изменения во фронте не сильно влияли на результаты тестов,, это, конечно, замечательно.
В случае с NYTimes будет уместно задать вопрос: "Зачем вам Single Page Application, если вы не сильно сложнее, чем Wikipedia и можете использовать Multi Page Application?"
Я понял сам кейс, но не могу представить случай, когда в рантайме нужно будет поменять модель у компонента. Если это реальная необходимость, то функциональность всегда можно дописать, это же Software. За такую гибкость его многие и любят.
HOC — это же лишь подход, и при использовании MVC я им принебрегаю и обновляю компоненты при изменении модели. Плюс ко всему, как я написал в статье, мне не нравится сама идея Container Components.
Не стоит презирать этот язык только потому что он сейчас не фигурирует на рынке. Благодаря Smalltalk мы с вами можем как пользоваться UI, так и программировать его. Smalltalk дал толчок развитию Apple и персональных компьютеров. Если будет время и желание. предлагаю прочитать The Early History Of Smalltalk.
Но я же использую React по назначению — только как View. Моя реализация модели никак не отражается на удобстве его использования. А если вы видите, что отражается, то всегда можете изменить реализацию BaseModel и BaseView, я лишь направил вектор размышлений по направлению оригинального MVC.
Не будет много моделек, Facebook обманывает :)
Будет модель
Chat, которая содержит списокThread. КаждыйThreadимеет количество непрочитанных сообщений. Chat суммирует количество всех непрочитанных сообщений в Thread'е и возвращает их с помощьюgetCountOfUnreadMessages(). При получении нового сообщенияThreadоповещаетChat, что он обновился.На mobx заглядывался, но руками не трогал. Видимо, пришло время потрогать, спасибо.
Создаем новую модель с таким же интерфейсом и заменяем старую, в чем проблема?
Controller есть — это callback'и onClick, onBlur и прочие.
Можете проверить, это несложно. Откройте описание MVC в Smalltalk-80 и найдите пункт "The View — Controller Link". В этом пункте написано:
Опять же цитата из описания MVC:
Действительно можно использовать forceUpdate, спасибо. На самом деле нужно было у базового View реализовать метод modelUpdated(model: BaseModel), но я поленился.
Правильно так:
Но выглядит это немного громоздко
А зачем он нужен модели?
Меня очень удивляет, когда работодатель просить показать профиль на Github или выполнить тестовое задание, но при этом сам не имеет публичного Github-аккаунта или отказывается показать свой "закрытый" код. Я понимаю, что есть часть кода, которая содержит уникальные знания, приносящие прибыль. Но также есть инфраструктурная часть, утилиты для разработчиков, тестовые библиотеки, которые не обладают бизнес-ценностью, для меня остается загадкой, почему такой код не выносят на Github или хотя бы не дают с ним ознакомиться во время интервью.
Интервью — это диалог, в котором обе стороны принимают решение, а не монолог перед "учителем", в котором только "учитель" может давать оценку, но никак не наоборот. Надеюсь, в скором времени будет появляться больше компаний, которые понимают, что многие разработчики ищут работу, чтобы создавать качественный продукт и получать от этого удовольствие, а не сидеть в уютном офисе, в окружении команды профессионалов, кушая печеньки и фрукты, запивая все это кофе и различными сортами чая.
Паттерны бывают не только архитектурные.
У Кента Бека, например, есть паттерны именования переменных. В книге "Smalltalk best practice patterns" он дает паттернам такое определение "A pattern is a decision an expert makes over and over."
Почему ценности Форда не коррелируют с ценностями автора статьи? Все цитаты взяты из книги "Генри Форд. Моя жизнь, мои достижения"
Ценность автора статьи: "Самое важное — сотрудничество"
Ценность автора статьи: "Второе — непрерывная адаптация"
Сделано!
Спасибо за замечание, поработаю над этим в ближайшее время.
Есть мнение, что такой тип визуализации — статический — подходит для печатных изданий. В нашу эпоху, когда персональные электронне устройства широко распространены, любой визуальной информации нужна динамика. Очень советую посмотреть впечатляющие доклады Bret Victor на эту тему: https://youtu.be/ZfytHvgHybA
А какие профессиональные качества программиста существуют в отрыве от процесса разработки? Спрашиваю не шутки ради, а потому что каждый человек по-разному представляет себе "правильный" набор профессиональный качеств.
Если говорить про веб и мобильную разработку, то лично мне сложно рассматривать профессионализм программиста в отрыве от процесса. Только лишь технические навыки не позволят выпускать продукт часто и с меньшим количеством ошибок. Если в компании принято "перебрасывать" продукт от программистов в тестирование и забывать о нем, то насколько бы хорошо программист не владел техниками написания тестов, его в такой компании скорее всего "сожрут", потому что он идет против существующих ценностей. Если в компании программисты отдают код в эксплуатацию и их не волнует его дальнейшая судьба, то новому программисту даже не дадут шанса провести созданный им код до боевого окружения самостоятельно, потому что это работа другого отдела. Если руководитель команды никому не доверяет декомпозицию user story, а только спускает на программистов конкретные задачи, то как бы программист не хотел взять на себя ответственность за оценку, декомпозицию и выполнение всей user story, ему эту ответственность не дадут, потому что он посягает на работу руководителя.
Или программист, который прикладывает все силы, чтобы выпустить в срок качественный продукт, который точно будет работать на боевом окружении — это ненастоящий профессионал?
А если за чесность и попытки изменить ценности компании уволняют программиста, значит ли это, что программист хороший?
Если не читали Extreme Programming Explained: Embrace Change (2nd Edition), то очень советую с ней ознакомиться, особенно с главами, которые касаются ценностей и принципов. Книга почти полностью про взаимоотношения людей, а не про технологии и техники и в вашей ситуации может пригодиться. Вот несколько цитат, чтобы заинтересовать еще больше:
Обидно, что проводить такие эксперементы и менять культуру внутри компании позволяют только специальным людям, а не разработчикам.
Именно! Только это большее мало кто понимает, начинают "внедрять Agile", а потом он почему-то "не работает". Extreme Programming Explained: Embrace Change (2nd edition) отлично рассказывает и про ценности, и про принципы эффективной работы, которые важны намного больше, чем конкретные практики.
Манифест гибкой разработки программного обеспечения (http://agilemanifesto.org) появился более 15 лет назад. О "Agile" стали говорить на конференциях, выбросив из гибкой разработки все ее ценности и принципы кроме одного “Deliver working software frequently, from a
couple of weeks to a couple of months, with a
preference to the shorter timescale”. Сейчас слово “Agile” можно встретить в вакансиях практически каждой компании. Эти компании все также продолжают работать по водопаду, сохраняя развесистую иерархию, планируя и проектируя наперед и перебрасывая задачи из одного отдела в другой, но с более короткими итерациями."Agile” организации схватились за инструмент в виде коротких итераций, сохранив привычные процессы, а значит продолжают ценить процессы и инструменты больше, чем людей и их взаимодействие. То есть не принимают первую ценность гибкой разработки “Individuals and interactions over processes and tools”.
Принципы, следующие из первой ценности, которые разделяет автор статьи, но не организации, описанные выше: "Business people and developers must work together daily throughout the project”, “Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done”. Невозможно совмещать несколько ролей в организации, которая ценит фиксированные роли и четкое разделение обязанностей. Невозможно добиться доверия там, где ценится сокрытие реального положения дел. Невозможно следовать любым принципам, которые основываются на ценностях, отличных от действительных ценностей организации.
В конечном итоге, настоящие ценности — это самое важное, что есть в организации. Все остальное: используемые технологии, процесс принятия решений, способы коммуникации и постановки задачи, организационная структура и прочее, вытекают из ценностей. Автору статьи, видимо, не удавалось понять ценности организации во время собеседований. Мне тоже еще ни разу не удавалось их понять. Хабравчане, есть ли у вас подходы к выяснению настоящих ценностей компании во время собеседований?
Есть смысл соблюдать DRY, только когда логика, которую можно обобщить, уже выражена в коде. Если логика для обобщения находится только в голове у автора, скорее всего, полученный в итоге DRY-подобный код будет сложно переиспользовать, он будет казаться чужеродным в остальных частях приложения. По-сути это одна из форм проявления преждевременной оптимизации.
Например, у нас имеется простой класс:
При разработке другой части приложения клиент не хочет раскрывать реализацию и опирается только на интерфейс. Но интерфейс не говорит ничего о том, чем же является
colours, и что он содержит внутри. Тогда единственным способом работы с данным классом является чтение его реализации и поиск всех методов, которые он дергает уcoloursи элементовcolours. Это неэффективно и замедляет разработку. Если явно сказать, что colours — это список, содержащий объекты-значения, то в реализацию не нужно раскрывать:Но при этом мы не лишаемся возможностей, которые предоставляет нам утиная типизация, только теперь нам известно, что для работы
ColourMixнужен объект, который реализует интерфейс списка, причем не обязательно наследованием от списка.Это, конечно, верно. Статья о том, что интерфейс объекта должен явно говорить о наличии .get или .next.
selfв аргументах ничем не поможет, если в конструкторе будет внешняя зависимость:Инстанцирование класса в "неправильном" окружении снова возбудит ошибку. Функция или метод класса — это инструменты для демонстрации примера внешней зависимости, которая раскрывает реализацию. Суть примера не в применяемых инструментах, а в необходимости явной передачи всех внешних зависимостей.
Паттерны разработки — это борьба со сложностью программ. Если в приложении в нескольких местах есть повторяющийся код инстанцирования и настройки объекта, я вынесу его в фабрику — единое место для получения "готового к работе" инстанса — и не важно, на каком языке я программирую. Необходимость инкапсулировать сложное создание объекта не зависит от языка, а вот реализация зависит. Паттерны рассказывают о том, как увидеть эту необходимость, а не о том, какой конкретно код нужно писать.
Спасибо за замечание,
__contains__здесь действительно лучше подходит. Добавил в UPDИменно поэтому QA-отдел и должен осуществлять «Помощь разработчикам при написании тестов из первой категории».
А JIRA разрабатывают с 6 QA-инженерами на 70 девелоперов, причем QA-инженеры отвечают не за написание тест-кейсов и называются немного иначе.
Один из вариантов: GUI End-to-End покрывают фронтенд-разработчики, API End-to-End — бэкенд-разработчики. Фичи же получается как-то коллегиально делать, с автотестами тоже не возникнет проблем.
По-моему писать бизнес-логику, не понимая как должен будет выглядеть конечный результат, довольно странно. А для понимания конечного результата придется залезать в бизнес-домен в любом случае.
Если стоит задача создать хоть какое-нибудь покрытие автотестами проекта, на котором отсутствуют автотесты, правильнее начинать с небольшого количества End-to-End тестов, и продолжить спускаться на более низкие уровни. Но когда в создании автотестов заинтересована только Automation QA команда, этого спуска не происходит, и все заканчивается на End-to-End.
Это действительно возможный вариант. влияния отдела Automation QA на разработку, если разработка и менеджмент доверяют и понимают результаты прогонов с CI.
Просто так не бывает, но в End-to-End тестах бывает чаще, чем в других. Как минимум из-за взаимодействия с системой через пользовательский интерфейс, который иногда бывает довольно изменчив. Если с разработчиками фронтенда удается выстроить работу так, чтобы изменения во фронте не сильно влияли на результаты тестов,, это, конечно, замечательно.