В каких интересно командах ценятся "долгие и бессмысленные коммуникации"?
На мой взгляд это совершенно правильное стремление развивать культуру инженерных коммуникаций на базе формальных описаний, а не пустопорожних рассуждений. Особенно если посмотреть на все это со стороны, которая платит за разработку. Меньше всего хочется оплачивать бесконечные и бесполезные совещания и планерки.
На мой взгляд как раз мода на черные корпуса была. Мой первый 486-ой был в черном корпусе. Сложнее было купить монитор в черном корпусе, но даже в Тюмени, в относительно небольшом компьютерном салоне мне такой нашли.
Такое нереальное количество времени на запуск модульных тестов требуется только тогда, когда все разработчики все поведение раскладывают именно в Angular компоненты. Поэтому сокращение количества времени на выполнение модульных тестов обычно дает банальное разделение ответственности, упоминающееся в SOLID. Все поведение, не использующее ничего из пространства имен angular, реализуем в отдельных классах, которые затем используем уже собственно в компонентах. При таком раскладе необязательно и в броузерах тесты запускать вовсе. А компоненты являются просто фасадами и адаптерами для низлежащего, уже протестированного поведения.
Ну и в каких командах разработчики счастливее? В тех, что используют TDD, или в тех, где TDD не используется?
Считаете ли вы важной возможность повторного использования кода? Практикуется ли повторное использование кода, в том числе кода, написанного другой командой?
Не вижу особых проблем с реализацией подобных тестовых сценариев. Может конечно у вас какой-то неожиданно особый environment, без примеров кода сложно судить.
Не видел еще ни одного проекта, где к примеру модульные тесты занимали бы хоть сколько-нибудь значительное время. Около 3000 модульных тестов в проекте бэкенда, написанного на C# с использованием ASP.NET занимало несколько секунд.
Меньше всего мне хочется спорить с кем бы то ни было о вкусах. У меня вообще нет такой цели: "За меньшее время написать тесты, имеющие наибольшее покрытие" потому что я всегда сначала пишу тест, а потом код. Я сначала пишу тесты потому что это:
Улучшает внутренний дизайн и архитектуру программной системы
Удешевляет и упрощает последующее изменение кода
Порождает "исполняемую" документацию по коду, которая никогда не врет
Упрощает повторное использование кода
Снижает стоимость эксплуатации программной системы
Юнит тесты тестируют именно поведение классов. Модули, состоящие из множества классов тестируют интеграционными тестами.
Классический подход прост. Сначала пишем тест, потом пишем код, поведение которого проверяется в тесте. Ну а поведенческий код в объектно-ориентированной парадигме обычно упаковывается в класс. Поэтому юнит тесты обычно тестируют методы одного класса.
У меня есть такой опыт. И он свидетельствует о том, что чтобы людей, годами программирующих традиционно, перевести на рельсы XP, требуются недюжинные усилия и вагон времени.
Люди — это устройства с несовместимыми интерфейсами, а парное программирование требует очень хороших коммуникационных навыков, которые как правило отсутствуют у программистов, годами работающих в одиночку.
К тому же ни один из известных мне руководителей или собственников софтверных компаний не готов нести затраты на внедрение практик, перспективных в долгосрочной перспективе, особенно на фоне того, что старый подход "каждый новый проект, как первый", приносит неплохой доход.
В каких интересно командах ценятся "долгие и бессмысленные коммуникации"?
На мой взгляд это совершенно правильное стремление развивать культуру инженерных коммуникаций на базе формальных описаний, а не пустопорожних рассуждений. Особенно если посмотреть на все это со стороны, которая платит за разработку. Меньше всего хочется оплачивать бесконечные и бесполезные совещания и планерки.
На мой взгляд как раз мода на черные корпуса была. Мой первый 486-ой был в черном корпусе. Сложнее было купить монитор в черном корпусе, но даже в Тюмени, в относительно небольшом компьютерном салоне мне такой нашли.
Такое нереальное количество времени на запуск модульных тестов требуется только тогда, когда все разработчики все поведение раскладывают именно в Angular компоненты. Поэтому сокращение количества времени на выполнение модульных тестов обычно дает банальное разделение ответственности, упоминающееся в SOLID. Все поведение, не использующее ничего из пространства имен angular, реализуем в отдельных классах, которые затем используем уже собственно в компонентах. При таком раскладе необязательно и в броузерах тесты запускать вовсе. А компоненты являются просто фасадами и адаптерами для низлежащего, уже протестированного поведения.
В очередной раз убедился что не все, что порой хочется сказать обязательно писать… и публиковать...
Бальзам на душу. А я то уж думал что у меня одного такое положительное ощущение от использования TDD.
Улучшает ли использование TDD внутренний дизайн приложений? Позволяет ли качество написанных тестов считать их исполняемой документацией по коду?
Ну и в каких командах разработчики счастливее? В тех, что используют TDD, или в тех, где TDD не используется?
Считаете ли вы важной возможность повторного использования кода? Практикуется ли повторное использование кода, в том числе кода, написанного другой командой?
А тесты в процессе разработки пишутся по TDD? Или потом, когда весь код уже написан?
На мой взгляд создатели Agile-манифеста вполне исчерпывающе высказались на эту, и похожие темы.
Не вижу особых проблем с реализацией подобных тестовых сценариев. Может конечно у вас какой-то неожиданно особый environment, без примеров кода сложно судить.
Не видел еще ни одного проекта, где к примеру модульные тесты занимали бы хоть сколько-нибудь значительное время. Около 3000 модульных тестов в проекте бэкенда, написанного на C# с использованием ASP.NET занимало несколько секунд.
А в чем проблема то с тестированием "асинхронщины"?
Главная задача для меня — получать удовольствие от программирования.
Что означает "начинаю проектировать на каком-то достаточно высоком уровне"?
Ответы на ваши вопросы есть в книгах Роберта Мартина, Кента Бека и "банды четерех" (Эрих Гамма, Ричард Хелм, Ральф Джонсон, Джон Влиссидес).
Меньше всего мне хочется спорить с кем бы то ни было о вкусах. У меня вообще нет такой цели: "За меньшее время написать тесты, имеющие наибольшее покрытие" потому что я всегда сначала пишу тест, а потом код. Я сначала пишу тесты потому что это:
ActiveRecord на мой взгляд — антишаблон. Модель данных не должна зависеть от механизмов хранения.
Юнит тесты тестируют именно поведение классов. Модули, состоящие из множества классов тестируют интеграционными тестами.
Классический подход прост. Сначала пишем тест, потом пишем код, поведение которого проверяется в тесте. Ну а поведенческий код в объектно-ориентированной парадигме обычно упаковывается в класс. Поэтому юнит тесты обычно тестируют методы одного класса.
Сервак, базейка, таски, фиксятся… я вдруг начал беспокоиться за свои счета в Альфа-Банке… Или это у меня признаки паранойи все ж? А?
У меня есть такой опыт. И он свидетельствует о том, что чтобы людей, годами программирующих традиционно, перевести на рельсы XP, требуются недюжинные усилия и вагон времени.
Люди — это устройства с несовместимыми интерфейсами, а парное программирование требует очень хороших коммуникационных навыков, которые как правило отсутствуют у программистов, годами работающих в одиночку.
К тому же ни один из известных мне руководителей или собственников софтверных компаний не готов нести затраты на внедрение практик, перспективных в долгосрочной перспективе, особенно на фоне того, что старый подход "каждый новый проект, как первый", приносит неплохой доход.
Не вопрос, могу перефразировать свой вывод — компаний, практикующих XP значительно-значительно меньше, нежели компаний XP не практикующих.