Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 5
×
  • Писать ли Unit-тесты до готовности MVP

    А еще посчитай публичные методы тут en.cppreference.com/w/cpp/container/vector

    Слушай, ну там же блин даже жирным выделено — 4 секции методов (считай, каждая секция это интерфейс, отвечающий за некий аспект класса), в каждом не более 10 методов.

  • Писать ли Unit-тесты до готовности MVP

    Посмотри реальные библиотеки, даже стандартные библиотеки С++, Питона или Джавы. Посчитай публичные методы классов. 7 не будет. Будут десятки.

    Ты так говоришь, как будто стандартные библиотеки являются верхом архитектурной мысли. Кроме того, у стандартных библиотек несколько иное предназначение, нежели у кода приложения. Код библиотек должен быть как можно более общим, чтобы удовлетворить сотни тысяч разработчиков. Поэтому имеем, например десятки перегруженных методов, которые типа делают одно и то же, просто по-разному удобны. Код приложения в идеале должен делать каждую вещь одним способом, это кстати к вопросу о минимизации усилий — лучше потратить эти усилия на написание качественных тестов, чем на написание десятка перегруженных методов, делающих одно и то же на разный манер.

    Класс со 150 методами — было бы интересно на него посмотреть, что-то у меня чуйка что там треш адский.

    Підтримали: Bot Bot, anonymous
  • Писать ли Unit-тесты до готовности MVP

    Да совмещайте на здоровье. Не совсем понятно, почему это должно занять меньше времени, ведь в сухом остатке количество внесённых изменений не уменьшается.

    Просто этот подход более структурированный, и он неплохо работает в проектах с хорошим покрытием тестами и для людей, которые привыкли подходить к работе более структурно. Отделяем мух от котлет.

  • Писать ли Unit-тесты до готовности MVP

    «продукционный код» as opposed to «тестовый код». Сорри, последние три предложения — я не могу понять, как они относятся к тому, что я сказал.

  • Писать ли Unit-тесты до готовности MVP

    Мне как раз помогал другой подход — не трогать код, пока это не нужно.

    Это самый правильный подход. Рефакторить код только на основе того, что он хреново выглядит — одна из самых тупых затей. Рефакторить надо только то, над чем реально предполагается работать в ближайшее будущее.

  • Писать ли Unit-тесты до готовности MVP

    Тут отметает кто-то другой

    Какой конкретно инструмент я там отметаю? :) Это моё глубокое убеждение, что умение писать тесты делает программиста лучше, и лично не раз видел корреляцию между умением писать чистые читаемые тесты и умением писать чистый, гибкий код. Наверное, причина в том, что человек не может быть аккуратен в чём-то одном и неряшлив в другом, человек «равномерно» аккуратен, и если тесты неаккуратны, то и продукционный код имеет схожее качество. Это выполняется не всегда, но я видел это в моей практике довольно часто. Можно считать личным мнением.

    Підтримав: Андрей Литвинов
  • Писать ли Unit-тесты до готовности MVP

    Интеграционные тесты тут еще могли бы выжить, но пришлось бы еще столько же новых понаписывать. Юнит — вряд ли.

    Я, честно говоря, слабо улавливаю важность того, чтобы тесты «выжили». Вы ж не стремитесь к тому, чтобы каждая строчка продукционного кода выжила. Наоборот, рефакторинг преподносится как что-то, что мы делаем постоянно. Так почему тестовый код должен быть исключением? Он тоже должен рефакториться. Но чтобы с ним было удобно работать и его рефакторить, ему нужно уделять достаточное внимание, а не писать просто на отвали.

  • Писать ли Unit-тесты до готовности MVP

    Так я, по-моему, наоборот тут везде топлю за то, чтобы пользоваться теми инструментами и процессами, которые дают максимальную отдачу. Это и есть agile, а не слепое следование каким-то там методологиям. Но я выступаю против того, чтобы огульно отметать инструмент просто потому, что у человека не было релевантного опыта или он не знает, как его использовать.

  • Писать ли Unit-тесты до готовности MVP

    появляется иерархия классов там, где ее не было?

    По-моему, вы как-то превратно понимаете рефакторинг. Рефакторинг — это изменение формы кода без изменения её смысла. «появляется иерархия классов там где её не было» — это звучит как добавление новой функциональности. Если это так, то рекомендуется сначала хотя бы примерно определить, как должен измениться _существующий_ код для того, чтобы поддерживать новую функциональность и реализовать эти изменения посредством операций рефакторинга. А затем уже добавлять новую функциональность.

    Не страшно при редких релизах, когда есть время оттестировать.

    Поэтому я и говорил, что в вашем конкретном случае это может и не иметь смысла. Потому что большинство проектов наоборот стремится к как можно более частым релизам в продакшн (ультимативно — переход к Continuous Deployment).

    Скорее, от архитектуры, которую мерять не научились.

    Ну так надо значит пользоваться теми метриками, которые есть, потому что иначе мы просто плаваем в бездонном супе.

    По продуктивности команд можете почитать Organizational Patterns of Agile Software Development с реальными исследованиями. Возможно, расширите кругозор.

    Спасибо, посмотрю. В свою очередь тоже рекомендую хотя бы ознакомиться с основыми трудами на тему юнит тестирования: «xUnit Patterns», «Growing Software Guided by Tests». Даже если в вашем текущем проекте это не находит применения, возможно, будет полезно в будущем или поможет иначе взглянуть на вещи.

    Підтримав: Denys Poltorak
  • Писать ли Unit-тесты до готовности MVP

    Реальные метрики — это цена проекта, влияние на имидж, продажи, и удовлетворенность пользователей.

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

  • Писать ли Unit-тесты до готовности MVP

    Module ownership на это влияет в разы, наличие юнит тестов — тормозит разработку и серьезные рефакторинги.

    Не доказано. Я могу привести обратные аргументы. Большой рефакторинг кода всегда можно разбить на серию мелких операций рефакторинга (см. «Refactoring» by Fowler). Каждая такая операция достаточно мала, чтобы не требовать полной переработки юнит тестов. Если юнит тесты написаны хорошо (т.е. если к ним применялись такие же высокие стандарты качества, что и к продукционному коду), то такие тесты будут гибкими и не будут сильно мешать рефакторингу. В то же время делая рефакторинг очень легко упустить мелкие детали и в итоге получить кучу багов. В этом случае юнит- и другие тесты служат в качестве safety net. Исходя из всего этого, я могу сделать вывод, что юнит тесты _ускоряют_ рефакторинг, а не тормозят.

    Остальные 3 параметра — имидж, продажи и удовлетворенность — никак не зависят от Ваших метрик качества кода. Они зависят от количества и серьезности новых фич и дефектов у пользователей.

    Количество фич как минимум частично зависит от качества кода, от его гибкости, связности и прочих презираемых вами показателей :) Количество появляющихся дефектов в большой мере зависит от двух вещей — 1) от качества тестового покрытия (regression bugs), 2) от правильности понимания требований (грубо говоря, правильно ли вы поняли требования и правильно ли вы их реализовали). Регрессионные баги _напрямую_ зависят от автоматических тестов в целом, и юнит тестов в частности. Баги недопонимания требований зачастую также уменьшаются с улучшением тестовых практик. Например, если вы пишете тесты в технике TDD, вы сильнее задумываетесь о краевых условиях, которые зачастую ускользают из внимания.

    Итого, я написал два больших абзаца обоснований, основа которых — признанные авторитеты в мире software engineering (такие как Robert Martin, Martin Fowler, Steve Freeman, Gerard Meszaros). В твоём посте я вижу только личное, недостаточно обоснованное мнение и презрение к сабжу :)

    Итого — Вы считаете что-то, не влияющее на бизнес. Это может быть интересно как упражнение, но полезность — сомнительна.
  • Писать ли Unit-тесты до готовности MVP

    Я уже написал. Прежде всего, есть метрики качества самого кода (типа тех, которые показывает Sonar). Они конечно же не идеальны, но они могут дать общую статистическую картину качества кодовой базы. Наблюдение — почему-то чем меньше тестов в кодовой базе, тем хуже её общее состояние. Далее, maintenance. Можно оценивать количество появляющихся дефектов к количеству заделиверенных ченжей. Правда, без определённой каденции (например, как спринты в скраме) это довольно сложно оценить. Ещё — time to fix, или сколько времени проходит от обнаружения дефекта до его закрытия? Ещё — time to deliver, или сколько времени проходит от появления требования до его реализации в продукции. Думаю, можно найти ещё. Но в твоём сетапе это не выглядит очень нужным, учитывая что у вас два дева, из которых один уровня тех лид.

  • Писать ли Unit-тесты до готовности MVP

    так как бы в этом и вся суть тестов.

    Это очень узкое понимание целей автоматического тестирования. Помимо «говорить что сломалось», тесты ещё служат документацией, например. Тут подробнее — xunitpatterns.com/...​s of Test Automation.html.

    Підтримав: Beaver Green
  • Писать ли Unit-тесты до готовности MVP

    моё мнение основано после нескольких тысяч написанных и исправленных тестов, потому поверь мне, я хлебнул более чем.

    Можно иметь 6 лет опыта, а можно иметь шесть раз по 1 году.

  • Писать ли Unit-тесты до готовности MVP

    Нет метрик

    О чём тогда разговор. Как ты оцениваешь качество своего кода? Так невозможно оценить ничего.

  • Писать ли Unit-тесты до готовности MVP

    Ну ты сам отвечаешь на свой вопрос. 2 дева, которые не меняются шесть лет — это ни о чём. Таких проектов — хрен с гулькой.

    Підтримали: Michael Budash, Denys Poltorak
  • Писать ли Unit-тесты до готовности MVP

    возможно ли это реализовать с технической точки зрения.

    Причём тут вообще техническая возможность? POC вообще может использовать жёсткие техники наподобие painted door test. POC должен проверить feasibility _идеи_.

    Підтримав: Denys Poltorak
  • Писать ли Unit-тесты до готовности MVP

    just enough features to satisfy early customers

    Сам же цитируешь. И MVP, и POC имеют одну цель — ускорить доставку продукта и получить фидбек. MVP достигает этого путём урезания фунцкионала до минимума (minimum viable), но при этом не должно накапливаться технического долга, потому что MVP — это реальный продукт, просто маленький. POC же в свою очередь достигает цели путём закрывания глаз на технический долг, поэтому правило хорошего тона — выкидывать POC как только получен результат (например, получили фидбек от кастомеров или результаты A/B-тестирования).

  • Писать ли Unit-тесты до готовности MVP

    Опять же, 4 года в продакшне особо не говорит о том, умеют ли люди писать хороший код. Нужны метрики, например, количество закрываемых сторей к количеству появляющихся багов, средняя сложность сторей, время внесения изменений и легкость их внесения, time to fix, etc.

  • Писать ли Unit-тесты до готовности MVP

    Размер продукта, частота изменений, какого рода изменения вносятся (багфикс, полностью новые модули, постоянное изменение старых), количество людей, текучка?

← Сtrl 123456...25 Ctrl →