Я джавист обычный, под андроид не пишу. Но там вроде уже есть Koin, Kodein, Dagger. На бэкенде есть Spring и Guice. Тут и компайлтайм и райнтайм решения. Что инновационного вы предлагаете?
Вопрос - использует ли кто-то такой подход в компаниях?
Кто-то пользуется, кто-то нет. Мы пользуемся. Пилим очень даже коммерческий и проприетарный продукт. Для выяснения таких нюансов как раз и существует секция "ваши вопросы" на собеседованиях. Кто-то на ней выясняет, как в компании амазоны кубернетятся. А кто поумнее - спрашивает полезные вещи в том числе про практики тестирования.
Кроме того, никто не запрещает вам приобрести субъектность и самому задавать тренд на культуру тестирования.
Я не пойму, в чем ваш тезис? Есть некий процесс Х. На процесс написан тест. Из теста понятно, что делает процесс Х при тех или иных входных параметрах. Всё - это документация. Нравится это кому-то или нет, полезна ли она лично вам или нет - но оно вот так работает.
Если тест не помогает понять на более высоком уровне, как процесс работает с другими процессами - так он и не должен. Документация на тормозной диск помогает вам 100% понять, как работает вся машина? Нет, и это было бы абсолютно бредовым требованием.
Ок, пишем тесты так, что "подаем на вход А - получаем на выходе Б" или "подаем на вход Г - получаем ошибку". Готова документация для другого разработчика.
нашел там нужный текст и из него понял бизнес-подоплёку
А что именно вам тут кажется невероятным? В инструментах вроде кукумбера у каждого теста есть текстовое описание типа "подаем на вход А - получаем на выходе Б" или "подаем на вход Г - получаем ошибку". Если это не документация, то что? Та же история на более низком уровне юнит-тестов.
А вы только до букв SRP дочитали? Я в конце как раз и пишу, что ответ и есть "зависит от ситуации". Для человека, у которого все эти принципы на кончиках пальцев, это совершенно несложный вопрос.
как здесь поможет прогон по книжкам Мартина или Эванса
Очень даже поможет. Вот человек заявляет, что пишет по SOLID. Заявляешь - отвечай. Происходит такой диалог.
Я: Вот есть у нас класс-оркестратор, который делает то-то и то-то и то-то - оркестрирует, короче. Можем ли мы лишь на основании этой вводной сказать, нарушает он SRP или нет?
Типичный знаток SOLID: Точно нарушает, т.к. делает сразу много всего, а должен что-то одно.
Я: Ок, получается SRP явно запрещает существование оркестрации в рамках класса? А где тогда ее организовывать?
Типичный знаток SOLID: Ээээ...
Правильный ответ: лишь на основании этой вводной сказать невозможно, нужно изучить ряд других нюансов. Простейший "прогон по Мартину" показывает, что человек врет в своем резюме. Собес, конечно, не прекращаем. Но это лишний довод в пользу "не берем".
Ну это в общем не секрет, что в горной стране можно найти все природные зоны. Другое дело, что вакансии я видел только в Бар и Подгорицу. Ну и не всякий экспат готов жить в хуторе среди альпийских лугов.
Ну как сказать. Климат это вещь, которую по кнопке не выключишь. Я был в Черногории туристом и меня тамошнее пекло + 100% влажность доконали за неделю. А в Армении или Казахстане, например, жара сухая - если под прямым солнцем не тусишь, то просто тепло.
Проблема в том, что в подобных баттлах авторы забывают об огромном пласте средних компаний
Не забывают, а относят к "маленьким". Просто есть обобщенной параметр ощущаемой корпоративной шизы. В него входят, например, простота коммуникаций и отношение объема работы к объему дурацких ненужных приседаний. Пока шизы мало - и компания "маленькая". Потом резко становится "большой".
Это господа на Cyberforum'е не были. Там ты был виноват уже в том, что посмел к интернету подключиться.
ИИ быстр — не нужно ждать, пока на ваш вопрос ответят.
Автор как будто не понимает, что ИИ быстр как раз там, где и так все разжевано. Вам реально не нужно писать на SO, если хотите спросить, как на языке Х сабстринг делать. Приходите, когда что-то нетривиальное будет.
Неа. Типичное заблуждение. Поведение объекта характеризуется его интерфейсом. TreeMap и TreeSet - это прежде всего Map и Set. Они не реализуют какие-то специфичные древесные интерфейсы. Соответственно, вы не можете работать с ними как с деревьями и выполнять например поиски в глубину и ширину. В плане ООП мы не можем сказать TreeSet is a Tree. Зато можем сказать TreeSet has a Tree - но это совсем другая история.
Вы сами придумали что "литкодить на скорость" == "писать боевой код" и теперь размахиваете этим тезисом с великим восторгом. Заявление уровня "не служил - не мужик", короче. А для меня это не абсолютная истина, а так, частный случай. Можно хорошо литкодить и плохо писать боевой код. А можно плохо литкодить и хорошо писать боевой код. И остальные 2 комбинации тоже бывают. Так что выдохните уже.
Как-будто, если бы они не проверяли всех алгоритмами, то код был бы идеально вылизан.
Скажем там, если бы давали хоть что-то, кроме алгоритмов, то результат мог быть другой. Недавняя история с 6 задачками на 3 собесах в Небиус (экс-Яндекс) это же чисто буффонада.
Я джавист обычный, под андроид не пишу. Но там вроде уже есть Koin, Kodein, Dagger. На бэкенде есть Spring и Guice. Тут и компайлтайм и райнтайм решения. Что инновационного вы предлагаете?
Кто-то пользуется, кто-то нет. Мы пользуемся. Пилим очень даже коммерческий и проприетарный продукт. Для выяснения таких нюансов как раз и существует секция "ваши вопросы" на собеседованиях. Кто-то на ней выясняет, как в компании амазоны кубернетятся. А кто поумнее - спрашивает полезные вещи в том числе про практики тестирования.
Кроме того, никто не запрещает вам приобрести субъектность и самому задавать тренд на культуру тестирования.
Главное - зачем? Любой комплаенс и так в курсе, откуда дровишки. А всем остальным в целом параллельно.
Я не пойму, в чем ваш тезис? Есть некий процесс Х. На процесс написан тест. Из теста понятно, что делает процесс Х при тех или иных входных параметрах. Всё - это документация. Нравится это кому-то или нет, полезна ли она лично вам или нет - но оно вот так работает.
Если тест не помогает понять на более высоком уровне, как процесс работает с другими процессами - так он и не должен. Документация на тормозной диск помогает вам 100% понять, как работает вся машина? Нет, и это было бы абсолютно бредовым требованием.
Ок, пишем тесты так, что "подаем на вход А - получаем на выходе Б" или "подаем на вход Г - получаем ошибку". Готова документация для другого разработчика.
А что именно вам тут кажется невероятным? В инструментах вроде кукумбера у каждого теста есть текстовое описание типа "подаем на вход А - получаем на выходе Б" или "подаем на вход Г - получаем ошибку". Если это не документация, то что? Та же история на более низком уровне юнит-тестов.
Это сарказм? Посмотрел свою статистику в сонаре - 950 тестов с начала 2023 года. Это же юниты. Они по самой идее маленькие, простые и многочисленные.
А вы только до букв SRP дочитали? Я в конце как раз и пишу, что ответ и есть "зависит от ситуации". Для человека, у которого все эти принципы на кончиках пальцев, это совершенно несложный вопрос.
Мне вот кажется, что проще всего объяснить LSP на примере от противного, который мы можем найти в JVM.
Есть интерфейс
java.utils.List, у него есть методadd. И должно это все работать так:Однако можно сделать так:
или так
То есть у нас на руках тип List, а работать как с листом мы с ним не можем. Косямба? Косямба. Вот LSP говорит, что так делать не надо.
Примерно каждый второй.
Да, мы применяем эти практики и довольны результатом. Ожидаем, что и новые члены команды будут их применять.
Ок, практики написания кода не имеют отношения к написанию кода. Так и запишем.
Очень даже поможет. Вот человек заявляет, что пишет по SOLID. Заявляешь - отвечай. Происходит такой диалог.
Я: Вот есть у нас класс-оркестратор, который делает то-то и то-то и то-то - оркестрирует, короче. Можем ли мы лишь на основании этой вводной сказать, нарушает он SRP или нет?
Типичный знаток SOLID: Точно нарушает, т.к. делает сразу много всего, а должен что-то одно.
Я: Ок, получается SRP явно запрещает существование оркестрации в рамках класса? А где тогда ее организовывать?
Типичный знаток SOLID: Ээээ...
Правильный ответ: лишь на основании этой вводной сказать невозможно, нужно изучить ряд других нюансов. Простейший "прогон по Мартину" показывает, что человек врет в своем резюме. Собес, конечно, не прекращаем. Но это лишний довод в пользу "не берем".
Ну это в общем не секрет, что в горной стране можно найти все природные зоны. Другое дело, что вакансии я видел только в Бар и Подгорицу. Ну и не всякий экспат готов жить в хуторе среди альпийских лугов.
Ай да Дуров, ай да визионер
Ну как сказать. Климат это вещь, которую по кнопке не выключишь. Я был в Черногории туристом и меня тамошнее пекло + 100% влажность доконали за неделю. А в Армении или Казахстане, например, жара сухая - если под прямым солнцем не тусишь, то просто тепло.
Не забывают, а относят к "маленьким". Просто есть обобщенной параметр ощущаемой корпоративной шизы. В него входят, например, простота коммуникаций и отношение объема работы к объему дурацких ненужных приседаний. Пока шизы мало - и компания "маленькая". Потом резко становится "большой".
Цикл почти завершен? Лень читать маны - посмотрю индусов на ютабе. Лень смотреть индусов на ютабе - почитаю пересказ.
Это господа на Cyberforum'е не были. Там ты был виноват уже в том, что посмел к интернету подключиться.
Автор как будто не понимает, что ИИ быстр как раз там, где и так все разжевано. Вам реально не нужно писать на SO, если хотите спросить, как на языке Х сабстринг делать. Приходите, когда что-то нетривиальное будет.
Неа. Типичное заблуждение. Поведение объекта характеризуется его интерфейсом. TreeMap и TreeSet - это прежде всего Map и Set. Они не реализуют какие-то специфичные древесные интерфейсы. Соответственно, вы не можете работать с ними как с деревьями и выполнять например поиски в глубину и ширину. В плане ООП мы не можем сказать TreeSet is a Tree. Зато можем сказать TreeSet has a Tree - но это совсем другая история.
Вы сами придумали что "литкодить на скорость" == "писать боевой код" и теперь размахиваете этим тезисом с великим восторгом. Заявление уровня "не служил - не мужик", короче. А для меня это не абсолютная истина, а так, частный случай. Можно хорошо литкодить и плохо писать боевой код. А можно плохо литкодить и хорошо писать боевой код. И остальные 2 комбинации тоже бывают. Так что выдохните уже.
Скажем там, если бы давали хоть что-то, кроме алгоритмов, то результат мог быть другой. Недавняя история с 6 задачками на 3 собесах в Небиус (экс-Яндекс) это же чисто буффонада.