К сожалению (или к счастью) многие программисты считают свой код очень личным и любые замечания к нему воспринимают очень болезненно, как будто это часть их тела. Каждый ревью превращается в битву мнений в таком случае.
Совершенно верно. И это довольно существенный пожиратель времени. Чтобы решить эту проблему, мы, в свое время, ввели такое правило: обязательны к устранению только те замечания, которые можно классифицировать хотя бы по одному из существующих каталогов Code Smells. Если ревьюер не может классифицировать замечание, то его оно считается таким же субъективным, как и мнение автора, который имеет такое же право на личное мнение.
Ну, и, кроме того, исчезла «болезненность» замечаний. Одно дело, когда автору противопоставляется мнение его коллеги, а другое дело, когда ему противопоставляется классифицированный Code Smell, задокументированный Робертом Мартином, Мартином Фаулером, или Уордом Кеннингемом. В последнем случае самолюбие не задевается так сильно.
Кроме того, улучшилось понимание цели «рефакторинга» — он должен снижать стоимость развития программы за счет управления сложностью. Если замечание ревьюера не влияет существенно на экономику разработки, то оно считается малозначимым, исходя из чего становится ясной и его приоритетность (т.е. ответ на вопрос «делать или нет» зависит от приоритетности других задач разработчика).
Не много, но проблема в том что с той стороны сидят люди из Бангалора и если раз десять им одно и тоже не покажешь, то толку не будет.
Можно внедрить использование Каталога Рефакторинга. Мы таким образом многократно сократили время на Code Review. Правда, сегодня этот каталог сильно изменился, и уже не так удобен в использовании как прежде (по моему собъективному мнению). Прелесть каталога в том, что не нужно тратить время на объяснения — за вас будет работать соответствующий раздел книги, на который можно пройти прямо со страницы каталога.
Автору спасибо за то, что он затронул важную и интересную тему. Психология и в самом деле существенно повлияла на становление Agile, и все потому что Kent Beck испытал в детстве приступ панической атаки, когда он заблудился вместе с мальчишками в лесу, об этом он рассказывает в "Planning Extreme Programming". А если открыть список использованной Кент Беком литературы в «Extreme Programming Explained» 1st edition, то можно обнаружить весьма внушительный список книг по психологии и философии.
Автору спасибо за тему статьи. Про TDD можно было, конечно, чуть больше раскрыть вопрос. Это не совсем методика тестирования, а методика проектирования, которая позволяет заметно ускорить темпы разработки за счет декомпозиции сложности, снижения нагрузки на человеческую память и использования обобщения.
Мы, когда-то, сильно облегчили процесс Code Review тем, что внедрили в работу Online Catalog of Refactorings. Раньше он выглядел немного по другому, там была краткая информация, диаграмма, и в правом верхнем углу — номер страницы книги, на которой разработчик мог получить исчерпывающую информацию. Использование этого каталога сильно экономило время, достаточно быстро повышало общий уровень разработчиков, устраняло эмоциональность из процесса. После выпуска в этом году второго издания книги, каталог был переделан, по моему, сугубо субъективному, мнению, не в лучшую сторону. Но он все еще остается полезным для процесса Code Review. Так же заметно устранили эмоциональность из процесса каталоги Code Smells так как они вносили в разногласия достаточно авторитетную аргументацию, которую признавали все.
VolCh говорит правильно, есть такая проблема (с оценкой в частности, и с мотивацией вообще) в аутсорсе. В продуктовых компаниях с этим существенно легче.
Есть ряд мероприятий для повышения точности оценки в Agile, например, в XP оценки делаются двухфазно, сперва Story оценивается коллективно, затем Task оценивается индивидуально. Кроме того, постоянно ведутся метрики и отслеживается динамика ресурсов, затрачиваемых на реализацию тикетов, предсказуемость эстимитов, ресурсы, отвлеченные на багфиксы и т.п., поскольку они свидетельствуют о качестве проектирования и состоянии кодовой базы. Но автор, по всей видимости, имел ввиду, оценку для проекта целиком, т.е. Waterfall.
Я с вами полностью согласен. Основная причина неработающего Agile заключается в том, что люди не понимают что это такое, и как его применять. Это как в притче Кент Бека про автомобиль, когда водитель заехал не туда, и начал обвинять в этом автомобиль.
Работающий Agile — это действительно редкость, особенно Scrum. Начнем с того, что Scrum — «is a framework within which you can employ various processes and techniques.». Это самое важное, что нужно знать про Scrum, и именно этим он отличается от полноценных методологий вроде XP. Итак, Scrum — это не методология, и в методологию его еще нужно превратить. Но об этом чуть позже.
Я не буду долго останавливаться на том, как и почему возник Agile, и в чем его суть. Если кому интересны подробности, то я могу предложить ссылку на свой блог-пост по этой теме "Про Agile на пальцах. Путь к быстрой разработке.". Поэтому, здесь я затрону этот вопрос только тезисно.
1. Agile во многом изобрели архитекторы. Одну из самых первых и, по сей день, одну из самых эффективных Agile методологий XP изобрел Кент Бек. Среди подписантов Agile-manifesto присутствует ряд авторитетных архитекторов.
2. Agile означает гибкий. Достижение гибкости программы — это вопрос качества проектирования. Грубо говоря, Agile — это значит достигнуть такого качества проектирования, которое позволит дешево внедрять проектные решения не заблаговременно (up-front), а итеративно, уже в процессе разработки и развития продукта, с учетом обратной связи от практического использования продукта. Иными словами, наладить Agile-разработку могут только специалисты, компетентные в вопросах проектирования и архитектуры, иначе Agile просто обречен, но не все могут это заметить на ранней стадии.
Вся суть Agile выражена в одном выражении Кент Бека: «If a flattened change cost curve makes XP possible, a steep change cost curve makes XP impossible.».
Agile — это использование бизнес-выгод, которые дает качественное проектирование. Это возможность управлять бизнес-рисками в условиях неопределенности. Правда, возможно это только в том случае, если стоимость изменения программы низкая.
А теперь самое интересное. Изначально Scrum содержал технические практики заимствованные из XP. Однако, позже решение о выборе конкретного набора технических практик было отдано на откуп самим разработчикам. Они считали, что это сдерживает проникновение Scrum в массы. Именно поэтому, Scrum — это не методология, а framework (каркас, скелет), на который еще необходимо нарастить практики.
К сожалению, в Scrum отсутствует именно то, что поддерживает стоимости изменения программы низкой и делает Agile возможным. Одним из вариантов решения этого вопроса является комбинация Scrum и XP. На практике же разработчики не уделяют этому вопросу должного внимания, и часто вообще не используют никаких технических практик, превращая Scrum в обычный Waterfall с итеративным планированием, но при этом рост графика стоимости изменения кода не позволяет сделать разработку гибкой.
Как показывает статистика, которую я знаю из авторитетных источников и по личному опыту, в среднем за 3-4 года стоимость изменения программы возрастает настолько, что дальнейшее развитие проекта становится нерентабельным, и приходится прибегать к радикальным действиям (эмиссия акций, замена руководства, закрытие проекта, сокращение штата и т.п.).
Очень тяжело сделать развернутый ответ в краткой форме, поэтому, я думаю что приведенная мною выше ссылка ответит на все, что я упустил.
По вопросам управления бизнес-логикой и логикой приложения, статья, конечно, вызывает ряд вопросов, но это все становится ожидаемым, если учесть контекст статьи: «я пишу эти статьи, чтобы помочь себе в обучении.» Момент неполного раскрытия вопросов присутствует, но это неизбежно на стадии обретения опыта. Сам факт обретения новых горизонтов знаний уже сам по себе вызывает похвалу.
Я, знаете ли, не до конца уверен, что его эффективность была всего лишь результатом применения «четырех принципов». Дело в том, что в истории нет абзаца «и вот мы внедрили эти четыре принципа в команде, и все стали работать так же быстро как он».
Хорошее замечание, спасибо, добавил пару строк.
На самом деле, темпы разработки выросли не только у тех, кто работал с ним, но и, по цепной реакции, у тех, кто работал уже с этими, и даже в других компаниях, и так на протяжении уже нескольких лет.
Мы сразу говорим, что самое главное для нас это лишь уложиться в сроки решения задачи (называет сам исполнитель) и в конце показать рабочий код в репозитории.
Тут вы немного нарушаете роль оценки и планирования в Agile. И раз уж Вы решили внедрить Scrum — одну из Agile методологий, то разобраться с ее ролью придется. Видеоролик на эту тему от одного из 17 подписантов Agile манифеста https://youtu.be/eisuQefYw_o
«My general rule of thumb: don’t violate DRY within a microservice, but be relaxed about violating DRY across all services. The evils of too much coupling between services are far worse than the problems caused by code duplication. There is one specific use case worth exploring further, though.»
Если интересуют подробности этой проблемы, то их полностью раскрывает Sam Newman в «Building Microservices. Designing Fine-Grained Systems». Микросервисы действительно поощряют дублирование кода, но только в тех случаях где это позволяет снизить сопряжение (coupling).
Никакого развивающегося проекта не бывает без рефакторинга. И, кстати, 90% встретившихся мне менеджеров не понимают, что такое Agile/SCRUM и как он работает.
Причины рефакторинга бывают разными. Бывают причины потому что в мастер-бранч мержится некачественный код. Т.е. в команде отсутствует Collaborative Development. В таком случае Agile никак не оправдывает низкое качество кода, и даже, более того, предписывает его не трогать, пока он не мешает и не влияет на экономику разработки. А бывает рефакторинг как элемент реализации Evolutionary Design и YAGNI. Тогда — да, это Agile. Но в таком случае, это не рефакторинг, а Evolutionary Design.
mad_nazgul, Вы, к сожалению, ошибаетесь. Если интересны подробности, то Sam Newman (коллега Мартина Фаулера по ThoughtWorks) отвечает на этот вопрос в своей книге “Building Microservices. Designing Fine-Grained Systems”.
Пусть он почитает книгу «NoSQL Distilled. A Brief Guide to the Emerging World of Polyglot Persistence.» by Pramod J. Sadalage, Martin Fowler. Там описано как решаются такие проблемы в распределенных системах, хотя книга и не про микросервисы.
Микросервисы применимы не везде. Есть вещи, которые не зависят от уровня программистов. Наибольшим препятствием для использования микросервисов являются CAP-теорема и распределенные транзакции. Поэтому микросервисы применимы лишь там, где эти проблемы допускаются бизнес-логикой.
Совершенно верно. И это довольно существенный пожиратель времени. Чтобы решить эту проблему, мы, в свое время, ввели такое правило: обязательны к устранению только те замечания, которые можно классифицировать хотя бы по одному из существующих каталогов Code Smells. Если ревьюер не может классифицировать замечание, то его оно считается таким же субъективным, как и мнение автора, который имеет такое же право на личное мнение.
Ну, и, кроме того, исчезла «болезненность» замечаний. Одно дело, когда автору противопоставляется мнение его коллеги, а другое дело, когда ему противопоставляется классифицированный Code Smell, задокументированный Робертом Мартином, Мартином Фаулером, или Уордом Кеннингемом. В последнем случае самолюбие не задевается так сильно.
Кроме того, улучшилось понимание цели «рефакторинга» — он должен снижать стоимость развития программы за счет управления сложностью. Если замечание ревьюера не влияет существенно на экономику разработки, то оно считается малозначимым, исходя из чего становится ясной и его приоритетность (т.е. ответ на вопрос «делать или нет» зависит от приоритетности других задач разработчика).
Можно внедрить использование Каталога Рефакторинга. Мы таким образом многократно сократили время на Code Review. Правда, сегодня этот каталог сильно изменился, и уже не так удобен в использовании как прежде (по моему собъективному мнению). Прелесть каталога в том, что не нужно тратить время на объяснения — за вас будет работать соответствующий раздел книги, на который можно пройти прямо со страницы каталога.
Парное программирование — это частный случай Continuous Review. Если Вы про Review, то таки относится, по крайней мере — формально…
Автору спасибо за то, что он затронул важную и интересную тему. Психология и в самом деле существенно повлияла на становление Agile, и все потому что Kent Beck испытал в детстве приступ панической атаки, когда он заблудился вместе с мальчишками в лесу, об этом он рассказывает в "Planning Extreme Programming". А если открыть список использованной Кент Беком литературы в «Extreme Programming Explained» 1st edition, то можно обнаружить весьма внушительный список книг по психологии и философии.
А вообще, существует разница между оценкой (estimate) и обязательством (commitment).
Есть ряд мероприятий для повышения точности оценки в Agile, например, в XP оценки делаются двухфазно, сперва Story оценивается коллективно, затем Task оценивается индивидуально. Кроме того, постоянно ведутся метрики и отслеживается динамика ресурсов, затрачиваемых на реализацию тикетов, предсказуемость эстимитов, ресурсы, отвлеченные на багфиксы и т.п., поскольку они свидетельствуют о качестве проектирования и состоянии кодовой базы. Но автор, по всей видимости, имел ввиду, оценку для проекта целиком, т.е. Waterfall.
Я с вами полностью согласен. Основная причина неработающего Agile заключается в том, что люди не понимают что это такое, и как его применять. Это как в притче Кент Бека про автомобиль, когда водитель заехал не туда, и начал обвинять в этом автомобиль.
Работающий Agile — это действительно редкость, особенно Scrum. Начнем с того, что Scrum — «is a framework within which you can employ various processes and techniques.». Это самое важное, что нужно знать про Scrum, и именно этим он отличается от полноценных методологий вроде XP. Итак, Scrum — это не методология, и в методологию его еще нужно превратить. Но об этом чуть позже.
Я не буду долго останавливаться на том, как и почему возник Agile, и в чем его суть. Если кому интересны подробности, то я могу предложить ссылку на свой блог-пост по этой теме "Про Agile на пальцах. Путь к быстрой разработке.". Поэтому, здесь я затрону этот вопрос только тезисно.
1. Agile во многом изобрели архитекторы. Одну из самых первых и, по сей день, одну из самых эффективных Agile методологий XP изобрел Кент Бек. Среди подписантов Agile-manifesto присутствует ряд авторитетных архитекторов.
2. Agile означает гибкий. Достижение гибкости программы — это вопрос качества проектирования. Грубо говоря, Agile — это значит достигнуть такого качества проектирования, которое позволит дешево внедрять проектные решения не заблаговременно (up-front), а итеративно, уже в процессе разработки и развития продукта, с учетом обратной связи от практического использования продукта. Иными словами, наладить Agile-разработку могут только специалисты, компетентные в вопросах проектирования и архитектуры, иначе Agile просто обречен, но не все могут это заметить на ранней стадии.
Вся суть Agile выражена в одном выражении Кент Бека: «If a flattened change cost curve makes XP possible, a steep change cost curve makes XP impossible.».
Agile — это использование бизнес-выгод, которые дает качественное проектирование. Это возможность управлять бизнес-рисками в условиях неопределенности. Правда, возможно это только в том случае, если стоимость изменения программы низкая.
А теперь самое интересное. Изначально Scrum содержал технические практики заимствованные из XP. Однако, позже решение о выборе конкретного набора технических практик было отдано на откуп самим разработчикам. Они считали, что это сдерживает проникновение Scrum в массы. Именно поэтому, Scrum — это не методология, а framework (каркас, скелет), на который еще необходимо нарастить практики.
К сожалению, в Scrum отсутствует именно то, что поддерживает стоимости изменения программы низкой и делает Agile возможным. Одним из вариантов решения этого вопроса является комбинация Scrum и XP. На практике же разработчики не уделяют этому вопросу должного внимания, и часто вообще не используют никаких технических практик, превращая Scrum в обычный Waterfall с итеративным планированием, но при этом рост графика стоимости изменения кода не позволяет сделать разработку гибкой.
Как показывает статистика, которую я знаю из авторитетных источников и по личному опыту, в среднем за 3-4 года стоимость изменения программы возрастает настолько, что дальнейшее развитие проекта становится нерентабельным, и приходится прибегать к радикальным действиям (эмиссия акций, замена руководства, закрытие проекта, сокращение штата и т.п.).
Очень тяжело сделать развернутый ответ в краткой форме, поэтому, я думаю что приведенная мною выше ссылка ответит на все, что я упустил.
Хорошее замечание, спасибо, добавил пару строк.
На самом деле, темпы разработки выросли не только у тех, кто работал с ним, но и, по цепной реакции, у тех, кто работал уже с этими, и даже в других компаниях, и так на протяжении уже нескольких лет.
Если будет интересно, буквально вчера я изложил наш опыт как мы в разы увеличили темпы разработки.
Тут вы немного нарушаете роль оценки и планирования в Agile. И раз уж Вы решили внедрить Scrum — одну из Agile методологий, то разобраться с ее ролью придется. Видеоролик на эту тему от одного из 17 подписантов Agile манифеста https://youtu.be/eisuQefYw_o
1. PostgreSQL implements table inheritance
2. Class Table Inheritance
3. Single Table Inheritance
4. Concrete Table Inheritance