Обновить
52
4.8

Пользователь

Отправить сообщение

Я джавист обычный, под андроид не пишу. Но там вроде уже есть Koin, Kodein, Dagger. На бэкенде есть Spring и Guice. Тут и компайлтайм и райнтайм решения. Что инновационного вы предлагаете?

Вопрос - использует ли кто-то такой подход в компаниях?

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

Кроме того, никто не запрещает вам приобрести субъектность и самому задавать тренд на культуру тестирования.

Волож внезапно стал «израильским предпринимателем из Казахстана»

Главное - зачем? Любой комплаенс и так в курсе, откуда дровишки. А всем остальным в целом параллельно.

Я не пойму, в чем ваш тезис? Есть некий процесс Х. На процесс написан тест. Из теста понятно, что делает процесс Х при тех или иных входных параметрах. Всё - это документация. Нравится это кому-то или нет, полезна ли она лично вам или нет - но оно вот так работает.

Если тест не помогает понять на более высоком уровне, как процесс работает с другими процессами - так он и не должен. Документация на тормозной диск помогает вам 100% понять, как работает вся машина? Нет, и это было бы абсолютно бредовым требованием.

Ок, пишем тесты так, что "подаем на вход А - получаем на выходе Б" или "подаем на вход Г - получаем ошибку". Готова документация для другого разработчика.

нашел там нужный текст и из него понял бизнес-подоплёку

А что именно вам тут кажется невероятным? В инструментах вроде кукумбера у каждого теста есть текстовое описание типа "подаем на вход А - получаем на выходе Б" или "подаем на вход Г - получаем ошибку". Если это не документация, то что? Та же история на более низком уровне юнит-тестов.

Это сарказм? Посмотрел свою статистику в сонаре - 950 тестов с начала 2023 года. Это же юниты. Они по самой идее маленькие, простые и многочисленные.

А вы только до букв SRP дочитали? Я в конце как раз и пишу, что ответ и есть "зависит от ситуации". Для человека, у которого все эти принципы на кончиках пальцев, это совершенно несложный вопрос.

Мне вот кажется, что проще всего объяснить LSP на примере от противного, который мы можем найти в JVM.

Есть интерфейс java.utils.List, у него есть метод add. И должно это все работать так:

List<String> list = new ArrayList<>();
list.add("x");
list.contains("x") //true

Однако можно сделать так:

List<String> list = Collections.unmodifiableList(new ArrayList<>());
list.add("x"); // низззяяя, UnsupportedOperationException

или так

List<String> list = Collections.emptyList()
list.add("x"); // низззяяя, UnsupportedOperationException

То есть у нас на руках тип List, а работать как с листом мы с ним не можем. Косямба? Косямба. Вот LSP говорит, что так делать не надо.

Кто так делает?

Примерно каждый второй.

А если и так, то это такое требование к вакансии?

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

По мне так совершенно не имеющее к никакого отношения к действительности требование

Ок, практики написания кода не имеют отношения к написанию кода. Так и запишем.

как здесь поможет прогон по книжкам Мартина или Эванса

Очень даже поможет. Вот человек заявляет, что пишет по SOLID. Заявляешь - отвечай. Происходит такой диалог.

  • Я: Вот есть у нас класс-оркестратор, который делает то-то и то-то и то-то - оркестрирует, короче. Можем ли мы лишь на основании этой вводной сказать, нарушает он SRP или нет?

  • Типичный знаток SOLID: Точно нарушает, т.к. делает сразу много всего, а должен что-то одно.

  • Я: Ок, получается SRP явно запрещает существование оркестрации в рамках класса? А где тогда ее организовывать?

  • Типичный знаток SOLID: Ээээ...

Правильный ответ: лишь на основании этой вводной сказать невозможно, нужно изучить ряд других нюансов. Простейший "прогон по Мартину" показывает, что человек врет в своем резюме. Собес, конечно, не прекращаем. Но это лишний довод в пользу "не берем".

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

Ай да Дуров, ай да визионер

Вообще цены и погода не интересует

Ну как сказать. Климат это вещь, которую по кнопке не выключишь. Я был в Черногории туристом и меня тамошнее пекло + 100% влажность доконали за неделю. А в Армении или Казахстане, например, жара сухая - если под прямым солнцем не тусишь, то просто тепло.

Проблема в том, что в подобных баттлах авторы забывают об огромном пласте средних компаний

Не забывают, а относят к "маленьким". Просто есть обобщенной параметр ощущаемой корпоративной шизы. В него входят, например, простота коммуникаций и отношение объема работы к объему дурацких ненужных приседаний. Пока шизы мало - и компания "маленькая". Потом резко становится "большой".

Цикл почти завершен? Лень читать маны - посмотрю индусов на ютабе. Лень смотреть индусов на ютабе - почитаю пересказ.

Stack Overflow враждебен ко своим пользователям

Это господа на Cyberforum'е не были. Там ты был виноват уже в том, что посмел к интернету подключиться.

ИИ быстр — не нужно ждать, пока на ваш вопрос ответят.

Автор как будто не понимает, что ИИ быстр как раз там, где и так все разжевано. Вам реально не нужно писать на SO, если хотите спросить, как на языке Х сабстринг делать. Приходите, когда что-то нетривиальное будет.

Дерево, TreeMap, TreeSet

Неа. Типичное заблуждение. Поведение объекта характеризуется его интерфейсом. TreeMap и TreeSet - это прежде всего Map и Set. Они не реализуют какие-то специфичные древесные интерфейсы. Соответственно, вы не можете работать с ними как с деревьями и выполнять например поиски в глубину и ширину. В плане ООП мы не можем сказать TreeSet is a Tree. Зато можем сказать TreeSet has a Tree - но это совсем другая история.

Вы сами придумали что "литкодить на скорость" == "писать боевой код" и теперь размахиваете этим тезисом с великим восторгом. Заявление уровня "не служил - не мужик", короче. А для меня это не абсолютная истина, а так, частный случай. Можно хорошо литкодить и плохо писать боевой код. А можно плохо литкодить и хорошо писать боевой код. И остальные 2 комбинации тоже бывают. Так что выдохните уже.

Как-будто, если бы они не проверяли всех алгоритмами, то код был бы идеально вылизан.

Скажем там, если бы давали хоть что-то, кроме алгоритмов, то результат мог быть другой. Недавняя история с 6 задачками на 3 собесах в Небиус (экс-Яндекс) это же чисто буффонада.

Информация

В рейтинге
919-й
Зарегистрирован
Активность

Специализация

Бэкенд разработчик
Старший
Java
Kotlin