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

Опускаться до ТДД? Ой-вей... Что не так с ТДД?

я для него тупой, у меня не хватает оперативной памяти моего мозга, чтобы все держать в голове и нормально все написать. мне надо сначала собрать mvp того, что я хочу, потом привести это в порядок, и потом тестами покрыть, а не наоборот

я для него тупой, у меня не хватает оперативной памяти моего мозга, чтобы все держать в голове и нормально все написать. мне надо сначала собрать mvp того, что я хочу, потом привести это в порядок, и потом тестами покрыть, а не наоборот

Вы же когда обсуждаете тесты имеете ввиду генеративные/property тесты, да?

unit тесты

В целом идея хорошая называть driven design по имени того кто пишет bdd - boris driven design ddd - dmitry driven design tdd - тупой driven design

я для него тупой, у меня не хватает оперативной памяти моего мозга, чтобы все держать в голове и нормально все написать. мне надо сначала собрать mvp того, что я хочу, потом привести это в порядок, и потом тестами покрыть, а не наоборот

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

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

Опускаться до ТДД? Ой-вей... Что не так с ТДД?

хочется сказать что интерактивная разработка с РЕПЛ это тдд без боли, но никто не поймет и нужно будет объяснять

я для него тупой, у меня не хватает оперативной памяти моего мозга, чтобы все держать в голове и нормально все написать. мне надо сначала собрать mvp того, что я хочу, потом привести это в порядок, и потом тестами покрыть, а не наоборот

Одна из целей TDD не держать все в голове. У большинства противников TDD все представление о нем сформировано из названия. Одна из практик в TDD это spike - именно то, что вы называете MVP с обязательным условием, что весь написнаный код выбрасывается на помойку.

И суть как раз в минимальности. Написание теста вперед кода - это гарантия как раз того, что не будешь писать много кода.

А как это помогает? По мне такое покрытие с вертухи - это слишком крепкий цемент. Потому что меняются требования бизнеса, обстановка, одно, другое и тут не до тдд Потому в реально боевых условиях все эти прекрасные концепции программирования скукуеживаются до каких то прикладных приёмов, которые просто делают работу проще, причем скорее здесь и сейчас, чем что-то стратегическое Я так подумал подумал, и пришёл к тому что писать код с багами в прод - тоже вариант нормы. В конце концов это часть процесса, главное с этим не злоупотреблять. А тестами покрывать либо когда починил баг и надо его "зацементировать", либо когда уже написанное начинаешь менять. И тем более если это нечто используется больше 1 раза И так постепенно тестами покроются только реально стрелявшие и важные места, а не вообще все Ну и мне понравилась идея подпереть тестом сразу что то важное в процессе разработки, но тоже не злоупотреблять Это я так это все концептуально подумал, но сам пока не следую, меня то в одну крайность качает то в другую, наверное все же стоит попробовать

если вы не покрываете как правило код юнит-тестами, то TDD, конечно вам не подходит

Лично я сразу пишу интеграционные, когда задач на работе нет можно дописать юниты

если вы не покрываете как правило код юнит-тестами, то TDD, конечно вам не подходит

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

Одна из целей TDD не держать все в голове. У большинства противников TDD все представление о нем сформировано из названия. Одна из практик в TDD это spike - именно то, что вы называете MVP с обязательным условием, что весь написнаный код выбрасывается на помойку.

если вы не покрываете как правило код юнит-тестами, то TDD, конечно вам не подходит

Tdd и юниттесты - весьма мало друг с другом связаны.

Tdd и юниттесты - весьма мало друг с другом связаны.

почему-то спустя >15 лет (!) после изобретения quickcheck тесты все равно пишутся как 2-3 примера, а не property + simulation testing

Как лучше, получить Спо по финансам,потом бакалавриат по программированию; или наоборот?

Как лучше, получить Спо по финансам,потом бакалавриат по программированию; или наоборот?

Tdd и юниттесты - весьма мало друг с другом связаны.

🖥 Типичный собес Гоффера @golang_google

4+ чем не подходит, если в этих 4х есть опыт в Яндексе, баням пофигу на опыт в яндексе ? 🙂 Георгий Лишний :) что вообще за пятый год есть у человека по сравнению с прошлыми 4?

🚀 ITKey (UAE) — 12 лет строим облака на OpenStack / Kubernetes, развиваем собственную платформу KeyStack. Для блока Managed K8s ищем: Senior Go / Kubernetes Engineer 📍 Remote worldwide (кроме РФ и КЗ) 💰 $3 000 – 7 000 (net) Чем займёшься • Разработка операторов и контроллеров Managed K8s‑платформы (k0s, KubeVirt, Metal3) • Автоматизация bare‑metal + GPU для ML/LLM‑задач • Вклад в open‑source, code‑review, System Design распределённых сервисов Что нужно • 5 + лет Go, из них 3 + года — продакшн‑разработка K8s операторов/контроллеров • Глубокое понимание REST/gRPC, CRD, reconciliation loop • Опыт System Design и технической документации • Практика operator-sdk, controller-runtime, kubebuilder, envtest, kind, e2e‑тестов • Английский: С1 (команда не владеет русским языком) 💡 Не планируем долгий онбординг по Kubernetes internals — нужен человек, который уже писал контроллеры/операторы в продакшене. Что предлагаем • Вилка $3 k – 7 k (net), «белый» доход • 100 % remote, гибкий график, оплачиваемый отпуск • Современное железо (GPU, bare‑metal) • Обучение, KubeCon 📨 Отправляй CV / GitHub / LinkedIn 👉 @Andreev_Denis_IT

Интересно как это? Какая глубина в сантиметрах хотябы. :)

5-й от 4-го отличается также кардинально как 3-й от 4-го. Ничем Всем Чем-то

то есть нужно это все и это что-то, а без этого резюме не рассматриваются?

4+ чем не подходит, если в этих 4х есть опыт в Яндексе, баням пофигу на опыт в яндексе ? 🙂 Георгий Лишний :) что вообще за пятый год есть у человека по сравнению с прошлыми 4?

🖥 Типичный собес Гоффера @golang_google

Почему Яндекс выставляется как нечто такое, что сразу должно повышать в глазах нанимателей? Там куча позиций есть, где ты сидишь круды пишешь

Сначала закон Ома надо спросить, это основа всех основ 😊

🖥 Типичный собес Гоффера @golang_google

Физика ядерных частиц первее! Пусть для начала парочку квантовых уравнений напишет и интегралы от них возьмёт.

Закон Ома - это действительно основа всей электроники, а квантовая физика это только если для квантовых компьютеров

🚀 ITKey (UAE) — 12 лет строим облака на OpenStack / Kubernetes, развиваем собственную платформу KeyStack. Для блока Managed K8s ищем: Senior Go / Kubernetes Engineer 📍 Remote worldwide (кроме РФ и КЗ) 💰 $3 000 – 7 000 (net) Чем займёшься • Разработка операторов и контроллеров Managed K8s‑платформы (k0s, KubeVirt, Metal3) • Автоматизация bare‑metal + GPU для ML/LLM‑задач • Вклад в open‑source, code‑review, System Design распределённых сервисов Что нужно • 5 + лет Go, из них 3 + года — продакшн‑разработка K8s операторов/контроллеров • Глубокое понимание REST/gRPC, CRD, reconciliation loop • Опыт System Design и технической документации • Практика operator-sdk, controller-runtime, kubebuilder, envtest, kind, e2e‑тестов • Английский: С1 (команда не владеет русским языком) 💡 Не планируем долгий онбординг по Kubernetes internals — нужен человек, который уже писал контроллеры/операторы в продакшене. Что предлагаем • Вилка $3 k – 7 k (net), «белый» доход • 100 % remote, гибкий график, оплачиваемый отпуск • Современное железо (GPU, bare‑metal) • Обучение, KubeCon 📨 Отправляй CV / GitHub / LinkedIn 👉 @Andreev_Denis_IT

Всем привет, мы в m2.ru расширяемся и ищем Data/DevOps инженера! Обязанности: • Развёртывание, настройка и поддержка аналитических СУБД (ClickHouse, Trino, PostgreSQL) в продакшене и тестовой среде. • Настройка мониторинга, логирования и алертинга для систем хранения и обработки данных. • Автоматизация процессов развертывания и масштабирования с использованием инструментов IaC (Terraform, Ansible и пр.). • Участие в построении отказоустойчивой архитектуры хранения и обработки данных. • Оптимизация производительности СУБД и обеспечение их безопасности. • Работа совместно с аналитиками и разработчиками для обеспечения надёжного доступа к данным. • Создание и поддержка CI/CD пайплайнов для компонентов аналитической платформы. Требования: • Уверенное знание Linux и принципов работы сетей. • Опыт настройки, администрирования и мониторинга ClickHouse и Trino. • Опыт работы с PostgreSQL: настройка, репликация, резервное копирование. • Понимание принципов работы распределённых СУБД и OLAP-систем. • Опыт написания и сопровождения инфраструктурного кода (Terraform, Ansible или аналогичные инструменты). • Знание систем мониторинга (Prometheus + Grafana, Zabbix или аналогичные). • Опыт работы с Docker и Kubernetes. • Навыки отладки проблем производительности (CPU, IO, план выполнения запросов и т.д.). Будет плюсом: • Опыт построения high-load аналитической инфраструктуры. • Знание систем брокеров сообщений (у нас Kafka). • Опыт использования Airflow • Опыт работы с облачными провайдерами (AWS, Yandex Cloud, GCP и пр.). • Навыки скриптинга (bash, Python, Go). По всем вопросам можно писать @vika_nkl

https://www.youtube.com/watch?v=icEaRYTZgS4 мнения

https://www.youtube.com/watch?v=icEaRYTZgS4 мнения

ПОЧЕМУ МЫ МОЖЕМ ПЕРЕДАТЬ ФУНКЦИЮ КАК АРГУМЕНТ? НУ У НАС ЕСТЬ ВОЗМОЖНСТЬ ЭТО СДЕЛАТЬ