В разработке тесты больше помогают понять задачу, чем проверяют работоспособность. Тем более, как правильно писали выше, наличие тестов не гарантирует работоспособность модуля.
Я считаю, что тесты это больше слепок поведения, нежели проверки и нужны они для обезболивания расширения/изменения функционала. Тем более, привести в порядок тесты(написать/починить имеющиеся) + отрефачить код намного дешевле, чем рефачить без юнитов.
Я что-то подобное делал для решения N+1 у Hibernate и для реализации batch insert в одном запросе. В итоге не смог победить вменяемую отдачу id при возникновении конфликтов при insert.
Вот прочитал я статью. Ничего не понял. Сходил на сайт и также ничего не понял.
Далее вопросы:
Зачем вообще эта Deep.Foundation нужна и какую цель она преследует?
красивая визуализация дерева файлов приоритетнее архитектуры?
То ли на сайте, то ли в статье прочитал, что подход делает рефакторинг ненужным. Результат предсказуем: код абсолютно нечитаемый и к тому, кто его пропустил много неудобных вопросов:
Зачем импорты синхронизированны?
Куча переменных непонятно зачем. Если они нужны далее, то почему не сделать пайплайн?
Вся платформа это какие-то ультрамикросервисы (глянул в доке на деревья и увидел, что там КАЖДАЯ операция с деревом в своем модуле. Больше, правда, ничего не смотрел)
А чем CriteriaApi и Specification лучше данного подхода? Я, конечно понимаю, что мы все условия заворачиваем в спеки и основной сервис худеет засчет сервиса спецификаций.
Но по сути, это ровным счетом такая же дичь с теми же if-else, только реализация через еще более громоздкий синтаксис и без половины возможностей обычного SQL.
Имхо, hibernate вообще крайне неудачный выбор если мы хотим строить динамические запросы.
В таких случаях мы либо идем в сторону нативного SQL и StringBuilder, либо выбираем что-нибудь попроще. Например EBean.
Если даже он и самоучка, то явно знал куда идет и как там устроен процесс найма.
Он смог освоить язык и приемы работы с ним, так что ж ему помешало подготовиться к алгоритмическому собеседованию?
Про нужность алгоритмического собеседования:
Алгоритмическое собеседование нужно чтобы отсеять "ПРО-<подставь название ЯП>-девелоперов" которые знают все про архитектуру коллекций, но не понимают когда нужен стек, а когда массив.
Да, алгоритмы почти не используются в повседневной практике, но это не потому, что их там нет, а потому, что программист не привык видеть их. Классический пример: hibernate и n+1, когда линейная сложность внезапно превращается в степенную
Если интересно,то у Римана есть теорема о частично сходящихся рядах, которая, вроде, имеет некоторое отношение к теме статьи, но о ней, почему-то, ни слова...
В разработке тесты больше помогают понять задачу, чем проверяют работоспособность. Тем более, как правильно писали выше, наличие тестов не гарантирует работоспособность модуля.
Я считаю, что тесты это больше слепок поведения, нежели проверки и нужны они для обезболивания расширения/изменения функционала. Тем более, привести в порядок тесты(написать/починить имеющиеся) + отрефачить код намного дешевле, чем рефачить без юнитов.
Ну, пока он пишет код и где-то пол года после его хард-скилы еще сильные
Хм... Согласен.
Ты путаешь путь и длину пути.
Длину пути ищем с учетом прибавки
Я что-то подобное делал для решения N+1 у Hibernate и для реализации batch insert в одном запросе. В итоге не смог победить вменяемую отдачу id при возникновении конфликтов при insert.
А чем обычный алгоритм Дейкстры плох?
Находим самый маленький вес ребра и увеличиваем на него все веса. Путь при этом не изменится.
Вот прочитал я статью. Ничего не понял. Сходил на сайт и также ничего не понял.
Далее вопросы:
Зачем вообще эта Deep.Foundation нужна и какую цель она преследует?
красивая визуализация дерева файлов приоритетнее архитектуры?
То ли на сайте, то ли в статье прочитал, что подход делает рефакторинг ненужным. Результат предсказуем: код абсолютно нечитаемый и к тому, кто его пропустил много неудобных вопросов:
Зачем импорты синхронизированны?
Куча переменных непонятно зачем. Если они нужны далее, то почему не сделать пайплайн?
Вся платформа это какие-то ультрамикросервисы (глянул в доке на деревья и увидел, что там КАЖДАЯ операция с деревом в своем модуле. Больше, правда, ничего не смотрел)
Зачем такое дробление?
Если ты смотришь по набору полей, то БД возьмет индекс в котором присутствует ровно такой же набор полей
А чем CriteriaApi и Specification лучше данного подхода? Я, конечно понимаю, что мы все условия заворачиваем в спеки и основной сервис худеет засчет сервиса спецификаций.
Но по сути, это ровным счетом такая же дичь с теми же if-else, только реализация через еще более громоздкий синтаксис и без половины возможностей обычного SQL.
Имхо, hibernate вообще крайне неудачный выбор если мы хотим строить динамические запросы.
В таких случаях мы либо идем в сторону нативного SQL и StringBuilder, либо выбираем что-нибудь попроще. Например EBean.
Про самоучек:
Если даже он и самоучка, то явно знал куда идет и как там устроен процесс найма.
Он смог освоить язык и приемы работы с ним, так что ж ему помешало подготовиться к алгоритмическому собеседованию?
Про нужность алгоритмического собеседования:
Алгоритмическое собеседование нужно чтобы отсеять "ПРО-<подставь название ЯП>-девелоперов" которые знают все про архитектуру коллекций, но не понимают когда нужен стек, а когда массив.
Да, алгоритмы почти не используются в повседневной практике, но это не потому, что их там нет, а потому, что программист не привык видеть их. Классический пример: hibernate и n+1, когда линейная сложность внезапно превращается в степенную
Пункт 2 правильный.
Ошибка в п. 4. Там, как вы правильно заметили, невозможный переход от бесконечности к числу)
В копилку:
Представим себе бесконечное бинарное дерево.
Как известно, количество узлов в полном бинарном дереве равно 2^n-1, а количество путей 2^(n - 1).
Еще мы знаем, что в бесконечном бинарном дереве множество узлов счетно, а множество путей - нет.
Комбинируя пункты 3 и 4 получаем, что в бесконечном бинарном дереве количество путей нa 2^(n-1) - 1 раз меньше, чем количество узлов
Из пункта 4 вытекает, что в бесконечном бинарном дереве континуум меньше счетного множеста
Если интересно,то у Римана есть теорема о частично сходящихся рядах, которая, вроде, имеет некоторое отношение к теме статьи, но о ней, почему-то, ни слова...