Последняя неделя отпуска прошла в режиме "без связи", поэтому предыдущий выпуск пропустил.
В этом нагоняем, продолжая читать "Just Enough Software Architecture" и добавив интересных ссылок.
1. Работа команды над решением задачи снижения риска ухудшения архитектуры путем прояснения текущего ее состояния для новых членов команды:
we were aware of providing coverage of the three primary models —the domain, the design, and the code models —and also the three primary architectural viewtypes — the 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-ов в компании очень важная составляющая ее работы. Их нужно растить, искать, развивать. Без этого все очень сложно получается. Но, млин, так редко на моей памяти это происходит. Часто, а развитие чаще всего, это ложится на плечи самого лида. В целом то оно и правильно, но с помощью всегда лучше получается обычно. Если кому интересно, то тут вот в Питере правильная конфа будет в сентябре "Профессиональная конференция про тимлидов и для тимлидов".
В этом нагоняем, продолжая читать "Just Enough Software Architecture" и добавив интересных ссылок.
1. Работа команды над решением задачи снижения риска ухудшения архитектуры путем прояснения текущего ее состояния для новых членов команды:
we were aware of providing coverage of the three primary models —the domain, the design, and the code models —and also the three primary architectural viewtypes — the 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-ов в компании очень важная составляющая ее работы. Их нужно растить, искать, развивать. Без этого все очень сложно получается. Но, млин, так редко на моей памяти это происходит. Часто, а развитие чаще всего, это ложится на плечи самого лида. В целом то оно и правильно, но с помощью всегда лучше получается обычно. Если кому интересно, то тут вот в Питере правильная конфа будет в сентябре "Профессиональная конференция про тимлидов и для тимлидов".
Комментарии
Отправить комментарий