Нет, этот аргумент не прокатит, как как Ваша позиция строится именно на том обобщении. Более того, вот эта фраза не является корректным обоснованием:
И я вам скажу, позиций/должностей, которые имеют такую ситуацию до фига
, так как речь идет не о числе позиций/должностей, а о том, насколько частые в разработке/АйТи Ваш случай. Например, какая доля разработчиков Яндекс, ТАТА или Голдман Сакс вообще присутствуют на таких встречах? Ответ - очень малая доля пересекается с внешним заказчиком в таком режиме, как у Вас.
А потому, Ваш аргумент схож с "вот я работаю юристом и хожу в суды постоянно, а разработчики не понимают процессуальных тонкостей", ибо это редкое событие. А следовательно, корректным ответом будет "раз для других людей это редкость, то разумнее провести инструктаж, а если эта ситуация повторяется, то можно сделать документ/обучалку для сотрудников".
И вот это самый главный вывод, так как если мы подходим к формализации хотя бы части процессов, то мы и начинаем вводить культуру в коллективе. То есть это будет не продавец-самодур, который требует жесткого подчинения, а именно часть культуры компании, где будет определены роли в публичных продажах.
Как следствие, Ваша жалоба уйдет целиком, да еще и не только для Вас конкретно, но и для всей фирмы сразу.
Суть в том, что вы путаете внутренние встречи, где в целом такого нет, но и полноценными встречами их сложно назвать, с внешними
О том и речь. За мои 15 лет опыта, такие встречи были ровно два раза. В первом случае была маленькая фирма, говорил директор (а не тимлид, конечно же), он же все проинструктировал, раздал роли (мы все делали вид, что работаем только над одним проектом и так далее).
Во втором случае было очень неформальное общение, подготовки было мало, но народ понимал важность встречи.
Но, что самое важное: в случае громадного числа разработчиков, такие встречи очень редки, а потому нельзя использовать их вообще как пример, так как от организатора таких встреч требуется жестко проговаривать, кто и что говорит, а также репетировать, если планируется много обманывать (хотя лично я постараюсь уйти из такого коллектива).
Просто обычно разработчики на другие почти не ходят, но это как в известном фильме "про суслика" ... поэтому тут вопрос бэкграунда и понимания, что кто-то "не видит суслика, а он есть", а кто-то видит по 10 раз в день
Нет, я здесь просто Ваш пример не засчитаю вообще, так как он радикально редкий (это во-первых), а также потому, что Вы уже начали себе противоречить: ведь если специалист А (продажи) не знает про суслика, то разумно предположить, что и специалист Б не знает про суслика (технические вопросы), но Вы опустили эту часть. Более того, если специалист А уже знает о подводных камнях (переговоры), то ожидается, что он расскажет о деталях заранее, а не будет просто накручивать себе цену.
А потому, вот этот абзац пока просто является еще одним свидетельством пользы статьи:
Ну или банальное правило на совещании не открывать рот, если на нем присутствует твой руководитель, кроме случая когда он сам попросит прокоментировать конкретный вопрос. Дискриминация? Да нет, нормальный паттерн.
Ну ибо он имеет только тогда смысл, когда присутствуют внешние заказчики, когда управленец ведет разговор о деталях, в которых он не разбирается, за спиной специалистов, но от тех требуется беспрекословного согласия и так далее, что, по сути, и является армейским методом управления "я начальник - ты дурак".
Поэтому давайте счанала определимся, вы что имеете (какую встречу) в виду
Я же написал не вообще "не открывать рот", а не открывать рот пока не скажут.
Кстати, это отличный пример, почему эта статья очень корректная и правильная.
Как так получилось, что подчиненный "открывает рот" (с точки зрения управленца)?
У меня пока следующие варианты:
Низкая квалификация в команде, а потому люди просто не умеют слушать других. Как следствие, и управленец, и подчиненный делают очевидные ошибки: один не понимает ритуалов так, как их понимает управленец, а другой не понимает, что до подчиненных необходимо всегда доносить требования и ожидания.
Подчиненный играет против компании (другими словами - саботаж), но управленец, почему-то, пока это игнорирует.
Управленец занимается саботажем (намеренно вводит людей в заблуждение), а подчиненный думает, что тот слегка заблуждается.
Тема недостаточно проработана с точки зрения организатора (нет целей, нет человека, который бы собрал цели, не собраны ограничения, не подготовлена необходимая бюрократия и так далее), но об этом все молчат (недостаток опыта или запрет на критику).
Все всё уже решили, но почему-то требуется формальная галочка от специалиста, но самого специалиста вовремя не спросили, так как все понимают, что специалист возразит (это отличается от саботажа выше, так как саботаж был бы намеренным, здесь же, скорее, люди занимались темой, которая за рамками их полномочий). Как следствие, согласие просят дать быстро-быстро, не особо раздумывая.
Это очень редкая формальная встреча (например, суд), но управленец забыл проинструктировать подчиненного, который недостаточно опытен, чтобы знать делали самому (другими словами - это настолько редкий случай, что он не имеет отношения к большинству людей).
Возможно я, конечно же, что-то забыл, но, чаще всего, встречаются именно пункты из перечня выше.
Другими словами, если поиграть в рекурсивную игру "зачем это требуется", то ответом, скорее всего, будет ошибка в руководстве, которая не была решена только потому, что руководству нельзя докладывать об их ошибках.
Возможно, это следствие какой-нибудь ошибки в дизайне приложения, в стиле «мы используем ‘select * from …’, а поля присваиваем по индексу ради производительности».
Не думаю, что эти if'ы лишние, так как, ну как мне кажется, values должно прийти извне, ну или иначе лучше сразу использовать значение из первого элемента.
В Stream могут быть nullы, но Optional прячет это.
Почему jacoco считает их покрытыми - большой вопрос :)
Нет, с этим всё просто. В коде a.b() мы проверяем, что b() было вызвано (то есть будет физический вызов функции), а в коде a::b мы проверяем, что мы получили указатель на функцию. И Jacoco честно говорит, что указатель был получен.
final var values = List.of(50, 100, 150);
if(values.isEmpty()) {
return
}
final var firstElement = valies.get(0);
if(firstElement == null) {
return;
}
final var topCity = TopCitiesCount.findByValue(firstElement);
if(topCity == null) {
return;
}
final var location = topCity.getTopCityLocation();
if(location == null) {
return
}
final var currentCondition = location.getCurrentConditionByLocation();
if(currentCondition == null) {
return;
}
eventService.sendEvent(currentCondition);
Это очень многословно, но, что самое интересно, на анализе покрытия тестами большинство условий будет подсвечено желтым, так как Вы проверяете только одну часть условия, но не вторую. Например, нет проверки того, что нам хоть когда-то не надо отправлять событие.
Более того, вот этот код покажет 100% покрытия если просто его вызвать:
Тогда как мой код выше будет весь "красным". И это важный момент, который я хотел подсветить: .ifPresent(eventService::sendEvent) отмечается как "вызванный" вне зависимости того, вызывали ли Вы sendEvent или нет, так как здесь мы просто передаем ссылку на функцию (а она передается всегда).
Если честно, я не знаю, как исправлять эту ситуацию в Java, так как это приведет к диссертации в каждом классе (по объему). В Kotlin, например, код был бы таким:
val values = listOf(50, 100, 150);
val condition = values
.firstOrNull()
?.findByValue()
?.topCityLocation
?.currentConditionByLocation
if(condition != null) {
eventService.sendEvent(condition)
}
Судя по этому рейтингу, Cobol находится на одном уровне с Kotlin (который используется едва ли не в большинстве всех Android приложений, который является рекомендованным по-умолчанию для Gradle, и который входит (вместе с Java) в список языков, которые используются в документации Spring.
Собственно, есть подозрение, что этот рейтинг очень плохо отражает реальность...
Какие есть команды, чтобы прочитать последнее значение из observable RxJS?
Подобные вопросы на эрудицию, конечно же, не очень помогают найти именно хорошего синьора, тут спору нет. Вот только я видел кучу раз то, как люди заваливались на очень простых задачах на написание кода (буквально "найдите индесы всех букв 'а' в строке, выбирайте любой язык), хотя резюме претендовало очень крутого специалиста.
А потому, вопросы на live coding очень хороши (если берут не чистого управленца), но вопросы на глубокое знание одной конкретной библиотеки - это очень странно (если только человек не написал, что является экспертом в ней, тогда стоит проверить, как кандидат определяет слово эксперт).
Как проходить подобные интервью пока не понял, задают десяток подобных вопросов и всегда находят что-то что не помнишь здесь и сейчас и что по их мнению кодер всегда помнит.
Если в роли предполагается знания языков программирования (ну или определенного), то необходимо показать необходимый уровень, причем каждый следующий включает в себя предыдущий. Условно говоря, джуниор может завалиться на вопросе для мидла, а синьор (и, особенно, тимлид) - нет.
Другими словами, если Вы не пишете код (а потому собеседование будет пройти непросто), то лучше выбирать роли чистого управленца, где будут спрашивать про MBA, попросят показать, как Вы выбираете risk appetite и пр.
они ожидают одинаковой логики от этих абстракций, и в большинстве случаев получают ее.
Я не до конца этого понимаю.. Вот есть у меня Map в переменной. Могу ли я в цикле проверять "есть ли элемент в Map", если число проверок будет столько же, сколько и размер Map? Для HashMap - однозначно, а вот для TreeMap я свалюсь в NlogN (N проверок по logN), плюс в Java будут еще проблемы с нелокальностью памяти (но это, зачастую, уже мелочи).
Аналогично про List - отличный интерфейс, вот только могу ли я спокойно сохранить его в переменную (так как он неизменный, как и 99% List'ов в программе) или нет? А могу ли я добавлять туда элементы (так как это копия) или же я получу ошибку?
Ответы будут только тогда, когда я получу очень узкий интерфейс, который, по сути, будет полностью описывать реализацию.
они более всех ближе к той границе где за гранью хороших практик и все возможных общих советов уже идет сугубо индивидуальные задачи
Мне всё-таки так не кажется. Функциональный подход (для JVM это будет Scala/Kotlin) дает намного больше пользы. Он автоматически покрывает DDD (по сути, DDD из него и выходит), он сразу применяет Open-closed Principle (за счет того, что намного проще скрывать не только классы/методы, но и область видимости переменных) и так далее.
SPR не требует от нас ограничиваться одним методом, он лишь призывает к тому что бы класс, а именно его состояние и поведение, были ограничены одной зоной ответственности
И это очень сложное утверждение, так как, например, можно придраться, что логгирование действий выходит из зоны ответственности, как и проверка входных переменных, а можно сказать, что это не так. Тут очень тонкая философия, которую, с моей субъективной точки зрения, сложно синхронизовать в команде.
Довольно занятно, как в реальных проектах ломаются все озвученные принципы:
каждый класс должен иметь одну обязанность и, следовательно, одну причину для изменения.
И это приводит к разрастанию очень и очень маленьких классов (буквально по одному методу), а потому становится очень сложно понять, что же происходит.
Если в алгоритмах нужно что-то поменять, то у нас нет причин изменять сам класс родитель. И в том и в другом случае это плюс к одной причине для изменения. +1 SRP
Не совсем. Если меняются сигнатуры, то это запросто повлечет изменения в куче мест. Более того, тут используется термин "класс родитель", а потому можно предположить, что предлагается делать наследование. Если так, то добавление нового аргумента в конструктор базового класса поменяет вообще все классы наследники.
Декоратор. Добавляем дополнительное поведение объекту, не меняя внутренности других декораторов и самого класса. +1 OCP
Это очень опасный подход, кстати, так как декоратору придется реагировать на все-все изменения сигнатур методов, плюс сложно будет понять, правильный ли интерфейс используется или нет.
Liskov Substitution Principle - Принцип подстановки Барбары Лисков Объекты в программе должны быть заменяемыми на экземпляры их подтипов без изменения правильности выполнения программы.
Если исключить самые-самые простые примеры, это принцип не работает даже в небольших проектах. Несмотря на то, что интерфейс к базе может быть общий, синтаксис запросов будет очень разным (как пример). Несмотря на то, что существует интерфейс List в Java (IList в .Net), в реальной программе всё-таки требуется знать, изменяемый объект или нет, это ArrayList или LinkedList и так далее. Аналогично про интерфейс Map (это может быть и хеш таблица, и дерево).
Interface Segregation Principle - Принцип разделения интерфейса Клиенты не должны зависеть от методов, которые они не используют, в общем, это про правильное разделение интерфейсов.
Принцип разделения интерфейсов говорит о том, что слишком «толстые» интерфейсы необходимо разделять на более маленькие и специфические, чтобы программные сущности маленьких интерфейсов знали только о методах, которые необходимы им в работе. В итоге, при изменении метода интерфейса не должны меняться программные сущности, которые этот метод не используют.
И, в целом, идея даже правильная, вот только даже List, приведенный в пример выше, уже нарушает этот принцип. Собственно, если честно следовать этой логики, то у каждого интерфейса должен быть строго один метод, иначе можно быстро найти пример, когда код нарушает правило.
Модули верхних уровней не должны зависеть от модулей нижних уровней. Оба типа модулей должны зависеть от абстракций. То есть, абстракции не должны зависеть от деталей, детали должны зависеть от абстракций.
Это очень спорное правило, на самом деле. Как раз наоборот - если я использую драйвер к базе, я четко осознаю, как он работает. Если я читаю строки из файла, я именно понимаю, как всё будет происходить. Более того, если мы не делаем библиотеку, то мне намного легче видеть, что конкретно вызывается (с поправкой на unit тесты, где могут быть подмены), вместо того, чтобы иметь еще один проект посередине, чтобы каждый раз просить IDE перейти к реализации. Собственно, я привел примеры выше про List и Map.
Более того, если представить, что нам захочется сменить базу данных, то такая мелочь, как смена типов в программе, будет незаметна даже на фоне созвонов и договоренностей с Dev Ops.
На самом деле, основной совет должен быть "код должен легко поддерживать изменения в рамках ответственности проекта".
Условно говоря, если в проекте постоянно добавляются интеграции с другими сервисами, но всегда есть одна и только одна база данных, то можно смело рассчитывать на неизменность базы, но заодно следует готовиться к новым внешним сервисам.
Заодно правило выше будет толкать к написанию правильных текстов, к более читаемым и строгим типам, к наличию необходимой документации и корректного ревью кода.
Парниковый эффект меняет климат - где-то становится теплее, где-то холоднее. Условное таяние ледников запросто приведет к остановке гольфстрима, так что в Гренландии, Исландии, Норвегии и Швеции будет еще холодее.
Заодно запросто климат может поменяться на более засушливый (в некоторых районах), что создаст проблемы с земледелием. Ну или на более влажный, тогда будет больше рекордных наводнений и пр. Понятно, что, если есть возможность магическим образом перенести города чуть-чуть вбок, то проблем бы с теми же наводнениями не было, но, по факту, придется или строить дорогие дамбы, или сносить уже построенные здания (а города очень часто недалеко от рек, ибо в них очень много плюсов).
Также считается, что нарушение течения может стать результатом глобального потепления, поскольку на динамику течения оказывает значительное влияние солёность океанской воды, уменьшающаяся из-за таяния льдов. Возможно также влияние уменьшающейся разности температур между полюсом и экватором при усилении парникового эффекта. Таким образом, «глобальное потепление» грозит Европе катастрофическим похолоданием.
Время от времени хаотическое движение воздушных масс в атмосфере, а также взаимосвязанные с ними тепловые процессы на земле и в воздухе приводят к формированию исключительно крупных облачных объединений, содержащих огромное количество воды, которые накрывают довольно большие территории. В конечном итоге это приводит к обильным и продолжительным ливням. Если естественные водостоки в виде рек и почвы не успевают отводить выпадающую влагу, происходят наводнения. Мощные снегопады образуются практически по такой же схеме
Только для условного котлина вам придется искать кучу разных библиотек - работа с БД
Таких библиотек много, но добавим 1-2 часа на интеграцию.
всякая арифметика с датами, временем, фиксированной точкой
Мне сложно даже сказать, в какой технологии этого нет.
то прежде чем его использовать, вы обязаны провести полный аудит всего кода
В банках уже используется Java, Kotlin, Python, C++ и еще куча всего, если верить вакансиям. Я не знаю, откуда это дополнительно требование.
А потом убедиться, что все это по производительности и потреблению ресурсов не хуже и вам не потребуется в два-три раза больше железа подо все это ставить.
Мне сложно поверить, что современный JVM (с зелеными потоками и пр.) будет медленнее, чем Cobol. Разве есть хоть какие-то свидетельства этого?
И "более читаемым" оно будет только для того, кто этот самый котлин знает.
Это задача на один день для человека, который имеет опыт с другим языком JVM, ну или на 1-4 недели изучения и работы, если человек вообще новичок. Так-то Котлин в вузах изучают, на нем программы пишут уже после первых пары занятий (то есть буквально после потраченных 3-5 часов). Затраты только на поиск специалиста на Cobol будут больше.
а что там такого на этом Коболе написано, что нельзя взять и переписать?
Там нет ничего такого. Это язык полный по тьюрингу, уровень типизации у него низкий и так далее. Честная перепись на условный Kotlin (с корректной типизацией и пр.) не будет сколько-нибудь сложной вещью, да и финальное приложение будет более читаемое.
Основная проблема в том, что на Cobol осталось только дремучее легаси, которое переписать стоит больше, чем бюджет отдела на год. Более того, проблемы (если верить слухам) усугубляются тем, что ряд приложений уже одобрены/сертифицированы (пусть даже выдают не всегда корректные данные), а документация утеряна, так что перепись на любой другой язык несет в себе риск получить новые проблемы (пусть даже с исправлением всех старых).
Тут подходит пример с факсом - он еще используется, хотя проигрывает современным методам коммуникаций. Но его использование обусловлено наличием старых процессов, которые конкретно сейчас не собираются менять.
Да, всё так, вот только есть несколько (независимых и не очень) системных циклов, которые делают ровно то, что Вы описали. По сути, любая корутина будет выполняться в одном из Dispatcher'ов.
Во-первых, там уже живут люди. Например, климат Сочи лучше климата Питера, но я был рад тому, что в Питере построили дамбу, чтобы нивелировать ущерб от наводнений.
Во-вторых, там может находится что-то полезное, а потому рабочим надо будет где-то жить. А точнее:
Этот город может запустить туризм (а он требует очень много персонала)
Там может быть порт, добыча нефти или фермерские поля (не забываем про ГМО, которое может помочь адаптировать некоторые растения под климат)
Там могут быть электростанции или промышленность, которая требует большого объема энергии (например, сейчас кладут кабель из Туниса в Европу; по задумке солнечную энергию можно добывать в пустынях, а передавать дальше на север).
В-третьих, как я уже сказал, лично мне этот проект нравится тем, что он даст информацию для ученых и инженеров.
Атомную энергетику ведь уже признали зеленой? Ведь признали же?
В мире нет некой "единой комиссии", которая признает что-то зеленым или нет. В ряде стран есть определенные дотации для определенных направлений бизнеса, и их часто связывают с "зелеными", но тут, скорее, будет только корреляция.
Отвечая на вопрос, тут три момента: глобальный, локальный, политический.
Глобальный: основная проблема для текущего климата - это парниковый эффект. Земля получает громадную дозу энергии от Солнца, вот только она всё хуже и хуже рассеивается.
Любой подход, который сможет уменьшить этот самый парниковый эффект, в итоге, приведет к исправлению климата. ГЭС/АЭС позволят сжигать меньше ископаемого топлива, что, в итоге, решит проблему. Ветряки и солнечные панели тоже помогут Земле в целом, но с ними всё хуже (могу расписать детали).
Более того, можно еще компенсировать выбросы путем увеличения объема лесов: по сути, растительность будет "забирать" СО2 из атмосферы.
Локальный: ряд выбросов плохо влияет на людей, а потому переход на условный газ или вынос электростанции подальше из города решит эту проблему. Конечно же, АЭС поможет и тут.
Политический: такие вещи, как АЭС, требуют очень больших инвестиций на начальном этапе, а далее их будут очень долго строить, плюс потом их надо обслуживать и утилизировать отходы. Каждый пункт очень лакомый для коррупции, а то же самое топливо еще и закупать сложно (его продает малое число стран, с которыми тоже придется договариваться). Строительство же газовых электростанций и ветряков намного проще и подконтрольнее, а потому нередко их предпочитают.
Не знаю. Но, для научного эксперимента, так даже лучше. А вдруг получится удачно? В ОАЭ некоторые проекты получились достойными, а некоторые - не очень, но даже неудачные (такие, как искусственные острова) дали новые знания для человечества.
Нет, этот аргумент не прокатит, как как Ваша позиция строится именно на том обобщении. Более того, вот эта фраза не является корректным обоснованием:
, так как речь идет не о числе позиций/должностей, а о том, насколько частые в разработке/АйТи Ваш случай. Например, какая доля разработчиков Яндекс, ТАТА или Голдман Сакс вообще присутствуют на таких встречах? Ответ - очень малая доля пересекается с внешним заказчиком в таком режиме, как у Вас.
А потому, Ваш аргумент схож с "вот я работаю юристом и хожу в суды постоянно, а разработчики не понимают процессуальных тонкостей", ибо это редкое событие. А следовательно, корректным ответом будет "раз для других людей это редкость, то разумнее провести инструктаж, а если эта ситуация повторяется, то можно сделать документ/обучалку для сотрудников".
И вот это самый главный вывод, так как если мы подходим к формализации хотя бы части процессов, то мы и начинаем вводить культуру в коллективе. То есть это будет не продавец-самодур, который требует жесткого подчинения, а именно часть культуры компании, где будет определены роли в публичных продажах.
Как следствие, Ваша жалоба уйдет целиком, да еще и не только для Вас конкретно, но и для всей фирмы сразу.
О том и речь. За мои 15 лет опыта, такие встречи были ровно два раза. В первом случае была маленькая фирма, говорил директор (а не тимлид, конечно же), он же все проинструктировал, раздал роли (мы все делали вид, что работаем только над одним проектом и так далее).
Во втором случае было очень неформальное общение, подготовки было мало, но народ понимал важность встречи.
Но, что самое важное: в случае громадного числа разработчиков, такие встречи очень редки, а потому нельзя использовать их вообще как пример, так как от организатора таких встреч требуется жестко проговаривать, кто и что говорит, а также репетировать, если планируется много обманывать (хотя лично я постараюсь уйти из такого коллектива).
Нет, я здесь просто Ваш пример не засчитаю вообще, так как он радикально редкий (это во-первых), а также потому, что Вы уже начали себе противоречить: ведь если специалист А (продажи) не знает про суслика, то разумно предположить, что и специалист Б не знает про суслика (технические вопросы), но Вы опустили эту часть. Более того, если специалист А уже знает о подводных камнях (переговоры), то ожидается, что он расскажет о деталях заранее, а не будет просто накручивать себе цену.
А потому, вот этот абзац пока просто является еще одним свидетельством пользы статьи:
Ну ибо он имеет только тогда смысл, когда присутствуют внешние заказчики, когда управленец ведет разговор о деталях, в которых он не разбирается, за спиной специалистов, но от тех требуется беспрекословного согласия и так далее, что, по сути, и является армейским методом управления "я начальник - ты дурак".
Я отвечаю на Ваш комментарий выше.
Кстати, это отличный пример, почему эта статья очень корректная и правильная.
Как так получилось, что подчиненный "открывает рот" (с точки зрения управленца)?
У меня пока следующие варианты:
Низкая квалификация в команде, а потому люди просто не умеют слушать других. Как следствие, и управленец, и подчиненный делают очевидные ошибки: один не понимает ритуалов так, как их понимает управленец, а другой не понимает, что до подчиненных необходимо всегда доносить требования и ожидания.
Подчиненный играет против компании (другими словами - саботаж), но управленец, почему-то, пока это игнорирует.
Управленец занимается саботажем (намеренно вводит людей в заблуждение), а подчиненный думает, что тот слегка заблуждается.
Тема недостаточно проработана с точки зрения организатора (нет целей, нет человека, который бы собрал цели, не собраны ограничения, не подготовлена необходимая бюрократия и так далее), но об этом все молчат (недостаток опыта или запрет на критику).
Все всё уже решили, но почему-то требуется формальная галочка от специалиста, но самого специалиста вовремя не спросили, так как все понимают, что специалист возразит (это отличается от саботажа выше, так как саботаж был бы намеренным, здесь же, скорее, люди занимались темой, которая за рамками их полномочий). Как следствие, согласие просят дать быстро-быстро, не особо раздумывая.
Это очень редкая формальная встреча (например, суд), но управленец забыл проинструктировать подчиненного, который недостаточно опытен, чтобы знать делали самому (другими словами - это настолько редкий случай, что он не имеет отношения к большинству людей).
Возможно я, конечно же, что-то забыл, но, чаще всего, встречаются именно пункты из перечня выше.
Другими словами, если поиграть в рекурсивную игру "зачем это требуется", то ответом, скорее всего, будет ошибка в руководстве, которая не была решена только потому, что руководству нельзя докладывать об их ошибках.
Но я могу ошибаться, конечно же...
Возможно, это следствие какой-нибудь ошибки в дизайне приложения, в стиле «мы используем ‘select * from …’, а поля присваиваем по индексу ради производительности».
Не думаю, что эти if'ы лишние, так как, ну как мне кажется,
valuesдолжно прийти извне, ну или иначе лучше сразу использовать значение из первого элемента.В
Streamмогут бытьnullы, ноOptionalпрячет это.Нет, с этим всё просто. В коде
a.b()мы проверяем, чтоb()было вызвано (то есть будет физический вызов функции), а в кодеa::bмы проверяем, что мы получили указатель на функцию. И Jacoco честно говорит, что указатель был получен.Очень хорошая статья, спасибо. Неявно, Вы подсветили важный недостаток Java Streams, а именно - они накручивают покрытие тестами.
Давайте попробуем переписать Ваш код ниже:
Без Stream'ов (и Optional'ов) будет что-то вроде:
Это очень многословно, но, что самое интересно, на анализе покрытия тестами большинство условий будет подсвечено желтым, так как Вы проверяете только одну часть условия, но не вторую. Например, нет проверки того, что нам хоть когда-то не надо отправлять событие.
Более того, вот этот код покажет 100% покрытия если просто его вызвать:
Тогда как мой код выше будет весь "красным". И это важный момент, который я хотел подсветить:
.ifPresent(eventService::sendEvent)отмечается как "вызванный" вне зависимости того, вызывали ли ВыsendEventили нет, так как здесь мы просто передаем ссылку на функцию (а она передается всегда).Если честно, я не знаю, как исправлять эту ситуацию в Java, так как это приведет к диссертации в каждом классе (по объему). В Kotlin, например, код был бы таким:
или:
И вот тут уже отсутствие вызова
eventService.sendEvent(it)будет четко показано в JaCoCo.Судя по этому рейтингу, Cobol находится на одном уровне с Kotlin (который используется едва ли не в большинстве всех Android приложений, который является рекомендованным по-умолчанию для Gradle, и который входит (вместе с Java) в список языков, которые используются в документации Spring.
Собственно, есть подозрение, что этот рейтинг очень плохо отражает реальность...
Вы специально пропустили глагол "читать", чтобы подчеркнуть, что писать write only код очень легко? :)
Подобные вопросы на эрудицию, конечно же, не очень помогают найти именно хорошего синьора, тут спору нет. Вот только я видел кучу раз то, как люди заваливались на очень простых задачах на написание кода (буквально "найдите индесы всех букв 'а' в строке, выбирайте любой язык), хотя резюме претендовало очень крутого специалиста.
А потому, вопросы на live coding очень хороши (если берут не чистого управленца), но вопросы на глубокое знание одной конкретной библиотеки - это очень странно (если только человек не написал, что является экспертом в ней, тогда стоит проверить, как кандидат определяет слово
эксперт).Если в роли предполагается знания языков программирования (ну или определенного), то необходимо показать необходимый уровень, причем каждый следующий включает в себя предыдущий. Условно говоря, джуниор может завалиться на вопросе для мидла, а синьор (и, особенно, тимлид) - нет.
Другими словами, если Вы не пишете код (а потому собеседование будет пройти непросто), то лучше выбирать роли чистого управленца, где будут спрашивать про MBA, попросят показать, как Вы выбираете risk appetite и пр.
Я не до конца этого понимаю.. Вот есть у меня Map в переменной. Могу ли я в цикле проверять "есть ли элемент в Map", если число проверок будет столько же, сколько и размер Map? Для HashMap - однозначно, а вот для TreeMap я свалюсь в NlogN (N проверок по logN), плюс в Java будут еще проблемы с нелокальностью памяти (но это, зачастую, уже мелочи).
Аналогично про List - отличный интерфейс, вот только могу ли я спокойно сохранить его в переменную (так как он неизменный, как и 99% List'ов в программе) или нет? А могу ли я добавлять туда элементы (так как это копия) или же я получу ошибку?
Ответы будут только тогда, когда я получу очень узкий интерфейс, который, по сути, будет полностью описывать реализацию.
Мне всё-таки так не кажется. Функциональный подход (для JVM это будет Scala/Kotlin) дает намного больше пользы. Он автоматически покрывает DDD (по сути, DDD из него и выходит), он сразу применяет
Open-closed Principle(за счет того, что намного проще скрывать не только классы/методы, но и область видимости переменных) и так далее.И это очень сложное утверждение, так как, например, можно придраться, что логгирование действий выходит из зоны ответственности, как и проверка входных переменных, а можно сказать, что это не так. Тут очень тонкая философия, которую, с моей субъективной точки зрения, сложно синхронизовать в команде.
Довольно занятно, как в реальных проектах ломаются все озвученные принципы:
И это приводит к разрастанию очень и очень маленьких классов (буквально по одному методу), а потому становится очень сложно понять, что же происходит.
Не совсем. Если меняются сигнатуры, то это запросто повлечет изменения в куче мест. Более того, тут используется термин "класс родитель", а потому можно предположить, что предлагается делать наследование. Если так, то добавление нового аргумента в конструктор базового класса поменяет вообще все классы наследники.
Это очень опасный подход, кстати, так как декоратору придется реагировать на все-все изменения сигнатур методов, плюс сложно будет понять, правильный ли интерфейс используется или нет.
Если исключить самые-самые простые примеры, это принцип не работает даже в небольших проектах. Несмотря на то, что интерфейс к базе может быть общий, синтаксис запросов будет очень разным (как пример). Несмотря на то, что существует интерфейс List в Java (IList в .Net), в реальной программе всё-таки требуется знать, изменяемый объект или нет, это ArrayList или LinkedList и так далее. Аналогично про интерфейс Map (это может быть и хеш таблица, и дерево).
Возможно, это странный перевод, так как википедия говорит, что:
И, в целом, идея даже правильная, вот только даже List, приведенный в пример выше, уже нарушает этот принцип. Собственно, если честно следовать этой логики, то у каждого интерфейса должен быть строго один метод, иначе можно быстро найти пример, когда код нарушает правило.
Это очень спорное правило, на самом деле. Как раз наоборот - если я использую драйвер к базе, я четко осознаю, как он работает. Если я читаю строки из файла, я именно понимаю, как всё будет происходить. Более того, если мы не делаем библиотеку, то мне намного легче видеть, что конкретно вызывается (с поправкой на unit тесты, где могут быть подмены), вместо того, чтобы иметь еще один проект посередине, чтобы каждый раз просить IDE перейти к реализации. Собственно, я привел примеры выше про List и Map.
Более того, если представить, что нам захочется сменить базу данных, то такая мелочь, как смена типов в программе, будет незаметна даже на фоне созвонов и договоренностей с Dev Ops.
На самом деле, основной совет должен быть "код должен легко поддерживать изменения в рамках ответственности проекта".
Условно говоря, если в проекте постоянно добавляются интеграции с другими сервисами, но всегда есть одна и только одна база данных, то можно смело рассчитывать на неизменность базы, но заодно следует готовиться к новым внешним сервисам.
Заодно правило выше будет толкать к написанию правильных текстов, к более читаемым и строгим типам, к наличию необходимой документации и корректного ревью кода.
Парниковый эффект меняет климат - где-то становится теплее, где-то холоднее. Условное таяние ледников запросто приведет к остановке гольфстрима, так что в Гренландии, Исландии, Норвегии и Швеции будет еще холодее.
Заодно запросто климат может поменяться на более засушливый (в некоторых районах), что создаст проблемы с земледелием. Ну или на более влажный, тогда будет больше рекордных наводнений и пр. Понятно, что, если есть возможность магическим образом перенести города чуть-чуть вбок, то проблем бы с теми же наводнениями не было, но, по факту, придется или строить дорогие дамбы, или сносить уже построенные здания (а города очень часто недалеко от рек, ибо в них очень много плюсов).
Пруфы:
https://ru.wikipedia.org/wiki/Гольфстрим
https://www.nkj.ru/archive/articles/23229/
Это нормально. У меня:
Собственно, только в 2014 у меня получилось написать такую статью, чтобы её одобрило НЛО в песочнице.
Таких библиотек много, но добавим 1-2 часа на интеграцию.
Мне сложно даже сказать, в какой технологии этого нет.
В банках уже используется Java, Kotlin, Python, C++ и еще куча всего, если верить вакансиям. Я не знаю, откуда это дополнительно требование.
Мне сложно поверить, что современный JVM (с зелеными потоками и пр.) будет медленнее, чем Cobol. Разве есть хоть какие-то свидетельства этого?
Это задача на один день для человека, который имеет опыт с другим языком JVM, ну или на 1-4 недели изучения и работы, если человек вообще новичок. Так-то Котлин в вузах изучают, на нем программы пишут уже после первых пары занятий (то есть буквально после потраченных 3-5 часов). Затраты только на поиск специалиста на Cobol будут больше.
Там нет ничего такого. Это язык полный по тьюрингу, уровень типизации у него низкий и так далее. Честная перепись на условный Kotlin (с корректной типизацией и пр.) не будет сколько-нибудь сложной вещью, да и финальное приложение будет более читаемое.
Основная проблема в том, что на Cobol осталось только дремучее легаси, которое переписать стоит больше, чем бюджет отдела на год. Более того, проблемы (если верить слухам) усугубляются тем, что ряд приложений уже одобрены/сертифицированы (пусть даже выдают не всегда корректные данные), а документация утеряна, так что перепись на любой другой язык несет в себе риск получить новые проблемы (пусть даже с исправлением всех старых).
Тут подходит пример с факсом - он еще используется, хотя проигрывает современным методам коммуникаций. Но его использование обусловлено наличием старых процессов, которые конкретно сейчас не собираются менять.
Да, всё так, вот только есть несколько (независимых и не очень) системных циклов, которые делают ровно то, что Вы описали. По сути, любая корутина будет выполняться в одном из Dispatcher'ов.
Во-первых, там уже живут люди. Например, климат Сочи лучше климата Питера, но я был рад тому, что в Питере построили дамбу, чтобы нивелировать ущерб от наводнений.
Во-вторых, там может находится что-то полезное, а потому рабочим надо будет где-то жить. А точнее:
Этот город может запустить туризм (а он требует очень много персонала)
Там может быть порт, добыча нефти или фермерские поля (не забываем про ГМО, которое может помочь адаптировать некоторые растения под климат)
Там могут быть электростанции или промышленность, которая требует большого объема энергии (например, сейчас кладут кабель из Туниса в Европу; по задумке солнечную энергию можно добывать в пустынях, а передавать дальше на север).
В-третьих, как я уже сказал, лично мне этот проект нравится тем, что он даст информацию для ученых и инженеров.
В мире нет некой "единой комиссии", которая признает что-то зеленым или нет. В ряде стран есть определенные дотации для определенных направлений бизнеса, и их часто связывают с "зелеными", но тут, скорее, будет только корреляция.
Отвечая на вопрос, тут три момента: глобальный, локальный, политический.
Глобальный: основная проблема для текущего климата - это парниковый эффект. Земля получает громадную дозу энергии от Солнца, вот только она всё хуже и хуже рассеивается.
Любой подход, который сможет уменьшить этот самый парниковый эффект, в итоге, приведет к исправлению климата. ГЭС/АЭС позволят сжигать меньше ископаемого топлива, что, в итоге, решит проблему. Ветряки и солнечные панели тоже помогут Земле в целом, но с ними всё хуже (могу расписать детали).
Более того, можно еще компенсировать выбросы путем увеличения объема лесов: по сути, растительность будет "забирать" СО2 из атмосферы.
Локальный: ряд выбросов плохо влияет на людей, а потому переход на условный газ или вынос электростанции подальше из города решит эту проблему. Конечно же, АЭС поможет и тут.
Политический: такие вещи, как АЭС, требуют очень больших инвестиций на начальном этапе, а далее их будут очень долго строить, плюс потом их надо обслуживать и утилизировать отходы. Каждый пункт очень лакомый для коррупции, а то же самое топливо еще и закупать сложно (его продает малое число стран, с которыми тоже придется договариваться). Строительство же газовых электростанций и ветряков намного проще и подконтрольнее, а потому нередко их предпочитают.
Не знаю. Но, для научного эксперимента, так даже лучше. А вдруг получится удачно? В ОАЭ некоторые проекты получились достойными, а некоторые - не очень, но даже неудачные (такие, как искусственные острова) дали новые знания для человечества.