Если не читали 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 тестах бывает чаще, чем в других. Как минимум из-за взаимодействия с системой через пользовательский интерфейс, который иногда бывает довольно изменчив. Если с разработчиками фронтенда удается выстроить работу так, чтобы изменения во фронте не сильно влияли на результаты тестов,, это, конечно, замечательно.
Если не читали 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 тестах бывает чаще, чем в других. Как минимум из-за взаимодействия с системой через пользовательский интерфейс, который иногда бывает довольно изменчив. Если с разработчиками фронтенда удается выстроить работу так, чтобы изменения во фронте не сильно влияли на результаты тестов,, это, конечно, замечательно.