К основному контенту

5 за 5 (истории 6-7)

Последняя неделя отпуска прошла в режиме "без связи", поэтому предыдущий выпуск пропустил.
В этом нагоняем, продолжая читать "Just Enough Software Architecture" и добавив интересных ссылок.

1. Работа команды над решением задачи снижения риска ухудшения архитектуры путем прояснения текущего ее состояния для новых членов команды:
we were aware of providing coverage of the three primary modelsthe domain, the design, and the code models —and also the three primary architectural viewtypesthe module, runtime, and allocation views.
We started with the easiest documentation to produce and gradually added in more expensive parts. After each one, we asked ourselves if the risk had substantially reduced and we calibrated that evaluation based on our coverage of the viewtypes and models. When possible, we built representative and textual models rather than fully general and graphical ones. We decided to create a graphical model of our modules and component assembly since they were relatively easy to produce and conveyed more information than our textual models. We stopped when we had covered the primary models and viewtypes, trusting that the new developers would be able to use what we provided as a skeleton of understanding and would hang detailed knowledge from it.

2. Risk-driven approach to software architecture consists of identifying risks, deciding the best set of techniques to mitigate the risks, and then evaluating the remaining risk...
Instead of applying architecture techniques until we ran out of them, until the documentation binder was complete, or until the project was canceled, we regularly re-evaluated the remaining risks and stopped when they had subsided.

3. The core of architectural understanding is to be able to get at the “why” questions. Having the understanding does not mean you must follow a certain process, or program in a certain language, or write diagrams on paper. Understanding software architecture means that you have internalised the (admittedly incomplete and imperfect) knowledge and abstractions that have been built up, and that you can apply that understanding when building new systems or analysing existing ones.

Дальше книга не идет :( Отложил пока в сторону.



Новости:
1.  Анонс Heisenbug 2018 Moscow. Ждем докладчиков, и можно уже планировать билеты и поездку.

2. Отличная статья про машинное обучение для тех, кто не знает, но стеснялся спросить: "Машинное обучение для людей. Разбираемся простыми словами".

3. Андрей Сатарин зафигачил хороший тред про тестирование.

4. How to measure exploratory tests?

5. Мысли вслух: институт team lead-ов в компании очень важная составляющая ее работы. Их нужно растить, искать, развивать. Без этого все очень сложно получается. Но, млин, так редко на моей памяти это происходит. Часто, а развитие чаще всего, это ложится на плечи самого лида. В целом то оно и правильно, но с помощью всегда лучше получается обычно. Если кому интересно, то тут вот в Питере правильная конфа будет в сентябре "Профессиональная конференция про тимлидов и для тимлидов".






Комментарии

Популярные сообщения из этого блога

Mock vs Stub

Когда мы начали изучать модульное тестирование, то одними из первых терминов, с которыми пришлось познакомиться, стали Mock и Stub.

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

Проверять работоспособность тестируемого объекта (system uder test - SUT) можно двумя способами: оценивая состояние объекта или его поведение.

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

Во-втором, мы проверяем набор и порядок действий (вызовов методов взаимодействующих объектов, других методов SUT), которое должен совершить метод SUT.

Собственно, если коротко, то в одном случае используется Stub, а в другом Mock. Это объекты, которые создаются и используются взамен реальных объектов, с которым взаимодействует SUT в процессе своей работы.

Теперь подробнее.

Gerard Meszaros использует термин Test Double (дублер), как обозначение для объекта, который зам…

План "Б" или как прикольно провести субботний день

Всем привет.
Вчера состоялась конференция "План Б". Организаторами выступили ребята из Яндекса, за что им большое спасибо. Судя по приблизительным подсчетам в мероприятии участвовало около 200 человек.

Основной темой конференции было планирование, планирование всего: проектов, разработки, тестирования, дизайнеров и даже организации музыкального фестиваля.
Сначала думал написать отчет в обычном своем стиле: кто и что говорил, но почитав твиттер по #pbconf понял, что просто потеряю время :) Поэтому кому оооочень интересно узнать подробности следуйте за птичкой и вы все узнаете (тэг #pbconf попал в top-30 твиттера)
Здесь приведу лишь те вещи, которые мне запали в мозг
Роман Чернин о продуктовой разработке: "нет заказчика, нет требований, нет сроков -> как принимать решения? ответ: заводим себе Product Manager-а"
Оля Павлова (@op): "бойтесь иллюзии точной формулировки" "заказчик - ребенок, выдаем ему игрушку как можно чаще" "не забываем, …

Полезные ресурсы для молодых (и не только) тестировщиков

Уже 3 месяца провожу собеседования тестировщиков.
Поначалу они просто  веселили - после 15-летнего опыта собеседования С++-разработчиков, общение с тестировщиками (чаще были "-цы") было чем то экзотическим и забавным.

Потом становилось все грустнее и грустнее, мимими закончилось. Началась печаль.