Вероятно для hello world проектов с двумя тремя файлами текстового редактора достаточно, но если у вас сложный проект с зависимостями, библиотеками, системами сборки вроде Maven и Gradle, сложными фреймворками и т.д., просто невозможно представить эффективную работу без нормального IDE.
Vim был хорош в своё время, но как можно спорить, что сейчас, когда выбор IDE так велик, можно обойтись текстовым редактором для сложного проекта?
В целом общее замечание, как и к первой статье, очень много лишнеготекста. Примеров побольше, но в тексте они теряются.
По содержанию, было интересно посмотреть на "Сопротивляемость рефакторингу". К сожалению мои ожидания не оправдались. Я думаю, что это свойство можно было раскрыть гораздо шире, чем тривиальное утверждение "если меняется только тело метода, то тесты переписывать не нужно ".
То, что Вы назвали "Зависимость от интерфейса", имеет устоявшееся в "науке" наименование "inversion of control". Для солидности неплохо было бы привести ссылку на статью об этом паттерне.
Компоненты, которые Вы назвали "Humble object" можно и даже нужно тестировать. Представьте, что у вас в репозитории написан гигантский SQL запрос с join и подзапросами. Для тестирования таких объектов существуют специальные библиотеки. В Java это testcontainers и mockserver. Наверняка что-то существует и для Вашей платформы (это вроде бы Nodejs)
Было бы неплохо хотя бы одно предложение насчёт языка программирования: какой язык используется в примерах и валидно ли всё, что Вы написали выше, для других языков тоже.
Интересно посмотреть, что Вы имеете в виду под "сопротивляемость рефакторингу". Надеюсь в следующей серии будет меньше текста и больше примеров на эту тему.
Один из моих коллег-автоматизаторов упомянул, что к нему обращаются разработчики с вопросом: "А как написать unit-тест?".
Наверно прозвучит не слишком вежливо, но почему разработчики у Вас обращаются не к более опытным коллегам своего профиля, а к инженерам по автоматизации тестирования?
Любой более-менее опытный разработчик с лёгкостью объяснит, как писать юнит-тесты, да и легко подскажет, какие стоит покрыть сценарии. Никаких секретных навыков QA для этого не требуется.
Конечно можно всё, что угодно, создать динамически, только зачем?
В статье критически не хватает раздела с постановкой проблемы.
Если доводить до абсурда, то такое приложение должно динамически создавать таблицы в базе данных и топики в Кафке, а эндпоинт, создающий листенер, должен принимать байт код листенера в качестве параметра.
Даже до того, как увидел весь список, было понятно, что в реальности он не знает ни один из этих языков. Он просто к ним прикасался.
Утверждать, что знаешь какой-то язык можно лишь после 5-6 лет опыта реальной работы.
Но когда увидел в списке Arduino (это вообще не язык, а технология для микроконтрллеров), а также 3 варианта SQL, всё стало ясно.
Вероятно для hello world проектов с двумя тремя файлами текстового редактора достаточно, но если у вас сложный проект с зависимостями, библиотеками, системами сборки вроде Maven и Gradle, сложными фреймворками и т.д., просто невозможно представить эффективную работу без нормального IDE.
Vim был хорош в своё время, но как можно спорить, что сейчас, когда выбор IDE так велик, можно обойтись текстовым редактором для сложного проекта?
Наконец дождался второй части :)
В целом общее замечание, как и к первой статье, очень много лишнеготекста. Примеров побольше, но в тексте они теряются.
По содержанию, было интересно посмотреть на "Сопротивляемость рефакторингу". К сожалению мои ожидания не оправдались. Я думаю, что это свойство можно было раскрыть гораздо шире, чем тривиальное утверждение "если меняется только тело метода, то тесты переписывать не нужно ".
Позвольте несколько замечаний:
То, что Вы назвали "Зависимость от интерфейса", имеет устоявшееся в "науке" наименование "inversion of control". Для солидности неплохо было бы привести ссылку на статью об этом паттерне.
Компоненты, которые Вы назвали "Humble object" можно и даже нужно тестировать. Представьте, что у вас в репозитории написан гигантский SQL запрос с join и подзапросами. Для тестирования таких объектов существуют специальные библиотеки. В Java это testcontainers и mockserver. Наверняка что-то существует и для Вашей платформы (это вроде бы Nodejs)
Было бы неплохо хотя бы одно предложение насчёт языка программирования: какой язык используется в примерах и валидно ли всё, что Вы написали выше, для других языков тоже.
Интересно посмотреть, что Вы имеете в виду под "сопротивляемость рефакторингу". Надеюсь в следующей серии будет меньше текста и больше примеров на эту тему.
Наверно прозвучит не слишком вежливо, но почему разработчики у Вас обращаются не к более опытным коллегам своего профиля, а к инженерам по автоматизации тестирования?
Любой более-менее опытный разработчик с лёгкостью объяснит, как писать юнит-тесты, да и легко подскажет, какие стоит покрыть сценарии. Никаких секретных навыков QA для этого не требуется.
Конечно можно всё, что угодно, создать динамически, только зачем?
В статье критически не хватает раздела с постановкой проблемы.
Если доводить до абсурда, то такое приложение должно динамически создавать таблицы в базе данных и топики в Кафке, а эндпоинт, создающий листенер, должен принимать байт код листенера в качестве параметра.