После всех переделывать, это миф

что можно написать хороший код :) сказки для детей

раз в 2-3 года перепишите - все, если проект живой

за джуниорами - просто говно за миддлами - переписывать фантазии в области новых трендов за синьорами - сраные конструкторы, которые не несут никакой бизнес пользы :)

Насчёт строк у мну тут хохма была. Я в прошлый спринт удалил в районе 200 строк кода и ещё штук 15 тестов, качество кода в целом выросло, но количество уменьшилось. За измерение количества строк кода в качестве метрики надо бить. Лучше ногами

Коммиты где "-" больше чем "+" - это практически всегда победа

это и есть позитивный импакт

Коммиты где "-" больше чем "+" - это практически всегда победа

* если код покрыт тестами ** если это делал не новый в проекте человек

Открою секрет)

ребята, разработчиков нельзя объективно померить. Померить можно только продукт который они совместно делают

Хороший код = код любого качества, но с правильными тестами)

Хороший код = код любого качества, но с правильными тестами)

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

Ибо всегда можно сделать лучше, а тесты есть гарантия что не переломаешь

хороший код - это который выполняет то, что позволяет основной пользовательский сценарий реализовать :)

написанный за разумное время

Тесты разные бывают, есть те, которые проверяют поведение, а есть такие, которые проверяют внутреннюю структуру

А есть тесты гарантирующие правильность тестов?

ну это вопрос стоимости ) посчитать стоимость фичи нерелаьно

только если не продавать часы

Есть Павел, запушить код на продакшен

Первые можно рефакторить, вторые лишь создают видимость теста

Там и узнаете, правильные ли были тесты :)))

Нет серебряной пули, есть бюджет и ресурсы

Там и узнаете, правильные ли были тесты :)))

Всё фигня, я миллион раз пушил в прод неработающий код и юзеры этого не замечали или находили воркэраунды. Сильно зависит от заказчика и методологии разработки

В этом все и дело

все иллюзии по поводу кода на продакшене встречают реальность

писали фичу две недели, выпустили, собрали статистику - увидели что никто не пользуется ЗАТО ТЕСТАМИ ВСЕ ПОКРЫТО

Кто-то с тремя разработчиками может за спринт делать проект, а кто-то такой же может пилить в 20 касок и не суметь составить конкуренцию

Миф про 100% покрытие тестами разводят мошенники

Вполне достаточно 70-80% основной бизнес-логики

Я не заю ни одного человека который делает зачем-то 100% покрытие и при этом говорит что у него в софте нет ошибок )

с мобилками боль из-за этого :с релизы редкие, быстро не захотфиксить ничего, приходится и тестить много, и нет уверенности, что фича не шлак. но это не только про юнит-тесты

у меня покрытие — 93% и при этом есть баги. Просто эти баги в коде, кторый не написан ))

TDD

так беда-то вголове, а не в том когда тесты пишутся

с мобилками боль из-за этого :с релизы редкие, быстро не захотфиксить ничего, приходится и тестить много, и нет уверенности, что фича не шлак. но это не только про юнит-тесты

а какая минимальная частота релиза?

Беда в акцептанс критериях

не, вот у меня они написаны

но я одного не прочитал )

Покажи

и всё сделал кроме этого одного

Кто дурак?)

я дурак

так я ж не оправдываю никого

но у меня будет хоть 130% покрытие — а этот критерий написан не будет

Разработчик бросающийся в код - опасный зверь

опасный зверь - хорошо звучит, мне нравится

Ибо еще надо хотя бы раз проверить актуальность задачи

А есть тесты гарантирующие правильность тестов?

Mutation testing

Мутации это метод монтекарло)

Да, мутационное…

Я пробовал

Но в котлине получается нерепрезентативно

потому что они начинают ломать конструкции языка

Ибо еще надо хотя бы раз проверить актуальность задачи

у нас спринты и вообще скрам, задач не так много, описан ыони сравнительно коротко, в актуальности сомнений не возникает

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

Что страшнее - отсутствие тестов или отсутствие актуального репорта о проблема на продакшене? Что ценнее - уметь быстро выкатывать патчи или удлинение времени проверки гипотезы? :)

Разработчик пишет юнит-тесты и не говорит о них - молодец, разработчик рассуждает о необходимости тестов - тратит время свои и коллег.

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

Разработчик пишет юнит-тесты и не говорит о них - молодец, разработчик рассуждает о необходимости тестов - тратит время свои и коллег.

вот тут не согласен. Людей надо приучать писать тесты, не говоря о них сделать это достаточно сложно

Хотя я уже сколько лет как не разработчик, может мне просто положено? )))

приучать можно только собак писать по месту :)

Я не найму в 201х году человека не пишущего тесты

не самый плохой критерий для найма :)

А от старослужащих легко избавиться, кинув на саппорт

Сами настрогали, сами наслаждайтесь

старослужащие встали и ушли с саппорта кого отправлять дальше будете :)

Новые уже умеют в тдд

Микросервисы тем и хороши, что изолируют домен, объем кода таков, что можно хоть каждый месяц переписывать на любом языке, соблюдай только контракты

Да, нагрузка на девопс, но эти парни на канбане)

Звучит жестко, но бизнес не богадельня

Вы хотите сказать что система с подсчетом строк кода реально где-то работает?

возьмите статистику со своего репозитария

за пол года

и тогда можно будет что-то обсудить :)

"систему" вроде никто не обсуждал

безусловно я увижу разницу, но я же понимаю что строчку кода нельзя считать условной единицей и приравнивать к другой строчке кода

да не, мне просто стало интересно кто занимался этим подсчетом

с т.з. статистики если данные накоплены за большой период времени, то неважно какие вы таски делали

берете например нормальное распределение