Цитаты из книг автора «Роберт Мартин»

Мое определение компонента немного отличается: «Группа функциональных возможностей, находящихся за общим чистым интерфейсом, которые постоянно находятся внутри среды выполнения, такой как приложение».

Намного меньше команд сообщали мне, что они используют инструменты статического анализа (например, NDepend, Structure101, Checkstyle) для автоматической проверки и выявления архитектурных нарушений во время сборки.

Принципы проектирования. Вы должны знать принципы SOLID и хорошо разбираться в принципах компонентного проектирования. • Методы. Вы должны понимать суть методологий XP, Scrum, экономной[6] разработки (Lean), Kanban, каскадной разработки, структурного анализа и структурного проектирования. • Дисциплины. Практикуйтесь в практическом применении разработки через тестирование (TDD), объектно-ориентированного проектирования, структурного программирования

Аналитики разрабатывают требования и пишут для них автоматизированные приемочные тесты. Тестеры тоже пишут автоматизированные приемочные тесты, но отличаются от аналитиков направленностью. И те и другие пишут тесты, но аналитики ориентируются на коммерческую ценность, а тестеры – на правильность работы кода. Аналитики пишут «оптимистичные» тесты, а тестеры беспокоятся о том, что может пойти не так, и пишут тесты для выявления сбоев и граничных случаев. Руководитель проекта следит за прогрессом и принимает меры к тому, чтобы группа понимала сроки и приоритеты. Один из участников группы может совмещать выполнение своих обязанностей с ролью наставника, ответственного за соблюдение технологических процессов и методов. Он становится своего рода «коллективной совестью», когда у группы возникает соблазн нарушить правила под давлением сроков.

Группы формируются не сразу. Между участниками постепенно налаживаются отношения. Они учатся работать друг с другом, узнают странности, сильные и слабые стороны своих коллег. Со временем участники «притираются» друг к другу.

Бессмысленно приказывать программисту посвятить половину времени проекту A, а другую половину – проекту B

Возможно, вам кажется, что в одиночку вы будете работать эффективнее. Даже если это и так, отсюда вовсе не следует, что будет работать эффективнее. И в действительности крайне маловероятно, что в одиночку вы действительно лучше справляетесь со своей работой.

Профессионалы объединяются в пары, потому что это лучший способ рецензирования кода.

Профессионалы также объединяются в пары, потому что это лучший способ обмена знаниями.

Многие программисты не любят идею парного программирования. Мне это кажется странным, потому что в напряженных ситуациях большинство программистов в пары. Почему? Потому что парное программирование очевидным образом является самым эффективным способом решения задачи.