В такой формулировке проблемы складывается ощущение, что приложения на ReactJS сложно тестировать, хотя это не так. Я в данный момент читаю книгу TDD на React — www.packtpub.com/product/mastering-react-test-driven-development/9781789133417. Те же самые принципы в действии, а самое сложное — моки и стабы, которые являются сложностью и при test-last.
В этой статье не затрагивались примеры самого использования TDD. Но, мне кажется, на ваш вопрос отвечает раздел Test-First Thinking.
Вы же как-то узнаете, что на экране правильно отобразилось то, что ожидается (чаще всего просто текст на экране)? Как вы демонстрируете бизнесу, что сделали функцию?
Практически все, что может проверить человек, может проверить и тест. Осталось только понять, из чего у программиста складывается уверенность в правильной работе кода.
Если я правильно понял вашу первичную идею, то путем TDD невозможно написать великий алгоритм. Т.е. дойти до решения, которое еще не известно.
Постановка задачи «написать quicksort» подразумевает, что алгоритм уже известен. Т.е. любая реализация ни докажет, ни опровергнет ваш тезис, потому что постановка задачи уже содержит способ имплементации. TDD не заменяет знание, он меняет путь прохождения по неизвестному.
Тут вижу два варианта. Или оставлять требование quicksort и тогда я буду проверять состав деревьев на каждом шаге, что странно попахивает. Или поставить требование на сложность алгоритма n*log(n), и тогда не факт, что у меня получится quicksort.
С другой стороны, если бы речь шла о «написать сортировку», то я на текущем уровне своего развития, скорее всего, написал бы сортировку вставкой или сортировку выбором. Получил бы пачку тестов «входные данные» => «выходные данные», которые могли бы принести пользу для проверки любой другой сортировки.
Древняя статья про эффективность TDD в цифрах — www.infoq.com/news/2009/03/TDD-Improves-Quality
Вполне удобная аргументация от инженера бизнесу.
А в контексте топика я бы добавил к цифрам, что это еще и экономит мыслительную энергию разработчиков (не всех).
И ни один из великих алгоритмов, которые мы учим в рамках профессионального образования, таким образом никогда не получился бы.
Я не очень силен в теории алгоритмов. Буквально только книга «Грокаем алгоритмы». Но я вижу некую схожесть TDD подхода и подхода «жадных алгоритмов», когда на каждом шаге определяется оптимальное решение только для этого шага. У этого есть и минусы, но есть и плюсы.
В этой книге описывает алгоритм Дейкстры и говорится, что это пример «жадного алгоритма». Его, наверное, нельзя отнести к «великим» (книга то для начинающих), но меня впечатлила его изысканность. Когда понятными шагами была решена задача, которую я не понимал как решать в целом.
Ну почему же вы сразу лень отсекаете? Это вполне естественное чувство/поведение человека. Особенно, когда 8 часов в день делаешь одну и ту же работу (не делая полноценные перерывы с переключением контекста). Особенно, когда человек находится наедине с самим собой — когда работает один, а не в паре или на встречах, и когда за спиной только стена.
Только, к сожалению, за это денег не платят.
У меня, получается, другой опыт. Мне платили намного более низкую ЗП, когда я клепал задачи за задачей в местах, где тестирование делал сам программист. И развивался в профессии я очень медленно.
А, пока что, самая большая моя ЗП была в тех местах, где стараются писать юниты, где есть отдел автоматического тестирования (E2E-тесты) и где менеджеры и скрам-мастера просят пробовать XP практики и все-таки писать юниты тех, кто их избегает. И развиваться в таких местах я стал намного быстрее.
В русском переводе один из принципов agile звучит как: "Инвесторы, разработчики и пользователи должны иметь возможность поддерживать постоянный ритм бесконечно. Agile помогает наладить такой устойчивый процесс разработки."
В моем понимании, это как разная полная противоположность тому, что написали вы. Работа с чувством постоянно давлеющего дедлайна — это как раз то, что agile стремится избегать, называя команду самоорганизующейся и профессионалами и позволяя команде самой определять объем задач на спринт.
Давление близкого дедлайна влияет на качество и вызывает страх (дискомфорт, неприязнь). Для меня очевидно, что это не про agile или scrum.
Понятно, что перевод, но статья не отличается должным уровнем рефлексии. Можно было и побольше покопаться в себе, а то все «грехи» от высоких идей исходят. А мне кажется все достаточно банальнее и примитивнее.
1. Вроде не такой плохой пункт. И Agile не против, если все зафиксировано. Выполняя первым попавшимся способом, лишаешь себя удовольствия сделать более качественную вторую идею. Но это явно лучше, чем 3. Оверинжиниринг.
2 и 5. Чистая лень и недисциплинированность, на самом базовом уровне. Решается элементарно, донесением ценности и культивации самодисциплины или автодисциплины (линтер).
3. «не хватает мотивирующих задач»? «кусочек кода пригодится в будущем»? Я вас умоляю… А как же страх? Боязнь не предусмотреть все, не сделать идеально? Перфекционизм, синдром отличника, как угодно. Или у западных коллег такого нет? Решение: признать ценность ошибок, каждая из которых ценнее, чем успех с 1ой попытки, и почитать про XP практики (я сам только погружаюсь, и по этой проблеме отличное решение для меня TDD и pair programming).
Выше еще про гордыню писали. Сам не понимаю этих эмоций, т.к. я ближе к вышеописанному, но со стороны кажется, что таких тоже много.
4. Тут не так очевидно, но тут ведь та же самая лень. Не хочется разбираться с библиотекой, не хочется подстраиваться и быть гибким. А тут опять о высоком «отличный способ понять». Прям спекуляция какая-то, что все люди 80% времени обезьянки, а программисты, внезапно, — нет.
6. И опять о высоком… «в тупике или проект «не заходит»». Какое там. Каждый раз, когда «надо» работать, вылазит и прокрастинация. Если задачи приходят сверху, то «стоять» на проект будет достаточно редко. Мотивация — ресурс очень ограниченный. И тут и проявляется профессионализм и дисциплина. Самое важное, не бороться с прокрастинацией силой воли. Силы воли всегда будет меньше, чем случаев прокрастинации. Надо научиться готовить прокрастинацию. Декомпозировать на мелкие и, главное, понятные куски. Ставить перед собой микро цели и фокусироваться на них. Попробуйте TDD, для меня прям средство №1 от прокрастинации.
P.S. Хочу выращить огромную благодарность М. Дорофееву и его «Джедайским техникам пустого инбокса». Прям супер средство от прокрастинации и необоснованной гордыни.
— A Longitudinal Study of the Use of a Test-Driven Development Practice in
Industry
— nagappan_tdd.pdf
— ITEA-AGILE-D2.7_v1.0
В этой статье не затрагивались примеры самого использования TDD. Но, мне кажется, на ваш вопрос отвечает раздел Test-First Thinking.
Вы же как-то узнаете, что на экране правильно отобразилось то, что ожидается (чаще всего просто текст на экране)? Как вы демонстрируете бизнесу, что сделали функцию?
Практически все, что может проверить человек, может проверить и тест. Осталось только понять, из чего у программиста складывается уверенность в правильной работе кода.
Постановка задачи «написать quicksort» подразумевает, что алгоритм уже известен. Т.е. любая реализация ни докажет, ни опровергнет ваш тезис, потому что постановка задачи уже содержит способ имплементации. TDD не заменяет знание, он меняет путь прохождения по неизвестному.
Тут вижу два варианта. Или оставлять требование quicksort и тогда я буду проверять состав деревьев на каждом шаге, что странно попахивает. Или поставить требование на сложность алгоритма n*log(n), и тогда не факт, что у меня получится quicksort.
С другой стороны, если бы речь шла о «написать сортировку», то я на текущем уровне своего развития, скорее всего, написал бы сортировку вставкой или сортировку выбором. Получил бы пачку тестов «входные данные» => «выходные данные», которые могли бы принести пользу для проверки любой другой сортировки.
Вполне удобная аргументация от инженера бизнесу.
А в контексте топика я бы добавил к цифрам, что это еще и экономит мыслительную энергию разработчиков (не всех).
Я не очень силен в теории алгоритмов. Буквально только книга «Грокаем алгоритмы». Но я вижу некую схожесть TDD подхода и подхода «жадных алгоритмов», когда на каждом шаге определяется оптимальное решение только для этого шага. У этого есть и минусы, но есть и плюсы.
В этой книге описывает алгоритм Дейкстры и говорится, что это пример «жадного алгоритма». Его, наверное, нельзя отнести к «великим» (книга то для начинающих), но меня впечатлила его изысканность. Когда понятными шагами была решена задача, которую я не понимал как решать в целом.
У меня, получается, другой опыт. Мне платили намного более низкую ЗП, когда я клепал задачи за задачей в местах, где тестирование делал сам программист. И развивался в профессии я очень медленно.
А, пока что, самая большая моя ЗП была в тех местах, где стараются писать юниты, где есть отдел автоматического тестирования (E2E-тесты) и где менеджеры и скрам-мастера просят пробовать XP практики и все-таки писать юниты тех, кто их избегает. И развиваться в таких местах я стал намного быстрее.
Перефразировал, подчеркнув акцент на контр-продуктивности персонально для себя.
В русском переводе один из принципов agile звучит как: "Инвесторы, разработчики и пользователи должны иметь возможность поддерживать постоянный ритм бесконечно. Agile помогает наладить такой устойчивый процесс разработки."
В моем понимании, это как разная полная противоположность тому, что написали вы. Работа с чувством постоянно давлеющего дедлайна — это как раз то, что agile стремится избегать, называя команду самоорганизующейся и профессионалами и позволяя команде самой определять объем задач на спринт.
Давление близкого дедлайна влияет на качество и вызывает страх (дискомфорт, неприязнь). Для меня очевидно, что это не про agile или scrum.
1. Вроде не такой плохой пункт. И Agile не против, если все зафиксировано. Выполняя первым попавшимся способом, лишаешь себя удовольствия сделать более качественную вторую идею. Но это явно лучше, чем 3. Оверинжиниринг.
2 и 5. Чистая лень и недисциплинированность, на самом базовом уровне. Решается элементарно, донесением ценности и культивации самодисциплины или автодисциплины (линтер).
3. «не хватает мотивирующих задач»? «кусочек кода пригодится в будущем»? Я вас умоляю… А как же страх? Боязнь не предусмотреть все, не сделать идеально? Перфекционизм, синдром отличника, как угодно. Или у западных коллег такого нет? Решение: признать ценность ошибок, каждая из которых ценнее, чем успех с 1ой попытки, и почитать про XP практики (я сам только погружаюсь, и по этой проблеме отличное решение для меня TDD и pair programming).
Выше еще про гордыню писали. Сам не понимаю этих эмоций, т.к. я ближе к вышеописанному, но со стороны кажется, что таких тоже много.
4. Тут не так очевидно, но тут ведь та же самая лень. Не хочется разбираться с библиотекой, не хочется подстраиваться и быть гибким. А тут опять о высоком «отличный способ понять». Прям спекуляция какая-то, что все люди 80% времени обезьянки, а программисты, внезапно, — нет.
6. И опять о высоком… «в тупике или проект «не заходит»». Какое там. Каждый раз, когда «надо» работать, вылазит и прокрастинация. Если задачи приходят сверху, то «стоять» на проект будет достаточно редко. Мотивация — ресурс очень ограниченный. И тут и проявляется профессионализм и дисциплина. Самое важное, не бороться с прокрастинацией силой воли. Силы воли всегда будет меньше, чем случаев прокрастинации. Надо научиться готовить прокрастинацию. Декомпозировать на мелкие и, главное, понятные куски. Ставить перед собой микро цели и фокусироваться на них. Попробуйте TDD, для меня прям средство №1 от прокрастинации.
P.S. Хочу выращить огромную благодарность М. Дорофееву и его «Джедайским техникам пустого инбокса». Прям супер средство от прокрастинации и необоснованной гордыни.