В моем случае - https://github.com/Citi/gradle-helm-plugin . Создатель проекта перестал его поддерживать, а потому самая последняя версия ссылалась на уязвимые библиотеки.
Мне говорят “можем только 450, нам тут налогов за тебя надо заплатить еще”?
Я думаю, что постепенно будет как в западных странах: сообщать будут gross, а люди сами будут считать налог (он же будет разный - чем выше ставка, тем выгоднее следить за вычетами).
Ну а фирма знает, сколько заплатит за год, а потому может посчитать эффективную ставку (например, будет 15.63%), так что каждый месяц будут отчислять именно эту долю от дохода (а не 13%). Если пришла премия, то пересчитают на лету. Если у человека есть дополнительные вычеты или доходы, то в конце года это сам человек покажет в декларации.
Я работал в небольших компаниях. Да, там такое возможно, но не более того. Условно 100+ человек - и это почти исключено.
Увы, это не так, если говорить про крупные фирмы. Любой проект начинается с теории, можно ли вообще такое сделать, а здесь необходим специалист.
Ваш комментарий совершенно очевидно говорит о том, что для вас проект начинается с ТЗ, хотя в реальности уме предшествует куча шагов.
Как Вы будете определять бюджет без понимания того, что требуется сделать, а также опознавания того, что можно сделать?
Я принимаю участие практически во всех этапах, которые указал.
Возможно, Вы не видите себя со стороны. Вы говорите, что Вы принимаете участие в этапах, которые Вы перечислил, не более чем.
Чесно говоря, мнение отдельного разработчика про самодура начальника вообще не релевантно.
И это частный случай для вашей компании, опять-таки. Далее Вы опять приводите примеры частных случаев того, как заведено у Вас. И да, вполне возможно, что есть и другие фирмы, в которых есть подобный же подход.
Вот только Ваш частный случай уже мало релевантен в компаниях, которые разрабатывают продукт для себя (или которые предоставляют сервис), так как их успех очень чувствителен к уровню разработчиков, которых нельзя вот так просто игнорировать.
Насколько я понимаю, у Вас в компании такого нет (судя по Вашим словам), а потому метод "я начальник - ты дурак" прекрасно работает.
Если взять реалии той же Британии (как частный случай), то выпускнику университета запросто будут платить £120.000 в год, плюс увеличьте эту сумму вдвое (чтобы учесть налоги и прочие косвенные затраты). Из-за высокой стоимости специалистов, компаниям становится очень дорого менять сотрудников. Как следствие из этого, армейский метод просто приводит к тому, что фирме не получается нанять людей, а далее она освобождает рынок.
Если Вы ошиблись и наняли не того человека, которого хотели (потому что Вы не сделали свою культуру более явной), то Вы потеряете около полугода, так как громадное число контрактов требуют уведомление об увольнении за три месяца, так что сначала Вы будете ждать не того человека, потом, поняв, что сотрудника требуется менять, Вы потеряете несколько месяцев на собеседования и еще три месяца на ожидание.
Подобная же проблема сейчас и в России (разве что в мягком виде): очень легко нанять стажеров, а потому к ним можно относиться и по-хамски, и с помощью армейского метода, тогда как квалифицированных специалистов нанимать долго и дорого.
А потому, вывод, если фирме нужны серьезные специалисты, то крайне рекомендуется следовать советам из статьи. Если же достаточно недорогих студентов, то действительно, управленцу не будет никакого смысла как-то там заморачиваться.
Потому что я точно знаю, что там разработчики не участвуют :)
Повторюсь - это в вашем частном случае.
Вы не видите картины, которую видит начальник, и поэтому не знаете, почему он принимает те, или иные решения
И Вы пока не смогли этого вообще доказать.
ОК, опишите этапы разработки в продуктовой компании :)
Вы же понимаете, что это зависит от компании и от её культуры? Для мелкого проекта и небольшой фирмы будут "ТЗ --> реализация --> доработка", для крупной фирмы и внутреннего проекта будет иной подход. В целом, в большинстве случаев, парадигма будет или в стиле водопада, или в стиле гибкой разработки, или в некоем гибриде, но так останется только на бумаге для инвесторов, так как реалии будут разными.
Но в чем смысл вопроса, если корректно получится показать только частный случай?
Я точно знаю, что вижу на порядок больше, чем рядовой разраб, и точно меньше, чем к примеру delivery director.
Но Вы пока не можете доказать или показать это, собственно, это только Ваши слова. На данном этапе Вы пока не можете даже обосновать, почему у Вас возникли сложности с регламентом поведения людей на переговорах, так что пока рано говорить о более серьезных вопросах.
но повторюсь разработчиков там нет.
Если разработчиков там нет, то это просто полностью отменяет Ваш аргумент под статьей, которая рассматривает разработку.
В чем смысл тогда был давать его?
Все просто.
Нет, не просто. На данном этапе:
Вы признались, что разработчики не принимают участия в тех процессах, на которые Вы жалуетесь, что приводит к следствию, что Ваш изначальный комментарий не относится к разработке в частности, а потому он не релевантнен со статьей.
Вы несколько раз повторили, что Вы никто не спрашивает вообще мнения разработчиков (откуда, правда, оно появилось, если их там нет).
Вы делаете вид, что занимаете высокий пост и много знаете о чем-то, но Вы даже не смогли составить регламент для переговоров.
Вы сначала жаловались на проблемы, а потом начали их отрицать. Вы сначала жаловались на разработчиков, а потом сказали, что они не принимают участия в вашей деятельности. Вы сначала говорите, что люди действуют некорректно, но сами Вы попытались перейти на хамство.
А потому, абсолютно непонятно, как Вы решали проблемы, которые Вы изложили, и почему метод автора Вы считаете некорректным (и какой тогда более корректный?).
Дело в том, что если эти этапы не видны разработчику, то "суслик это этого никуда не пропал".
Почему Вы так считаете? Пока что это Ваше предположение, которое будет, возможно, правдивым, когда в проекте только стажеры.
И что более важно, начальник то, в отличии от разработчика в курсе и принимает участие и это влияет на то, что он делает.
Я не понял этой фразы. Из неё следует, что разработчик не влияет на то, что он делает, ну то есть у Вас будто бы ChatGPT вместо специалиста.
Можете рассмотреть другой, но там этапов будет не меньше, я вас могу уверить :)
Нет, Вы ошибаетесь еще раз. Это Ваш частный случай для разработки на заказ (то есть Вы сразу игнорируете условный фриланс и аутсорс), а это частный случай разработки в целом, тогда как основная масса продуктов выпускается именно своими разработчиками для компании.
Не обижайтесь, но я думаю, те кто видят и телегу, и лошадь, и дорогу иметь большее право судить об этом, чем те, кто видят пол-лошади
Я правильно понимаю, что Вы считаете, что Вы единственный, которые всё это видит? Это уже близко к хамству, если честно.
Я вам указал этапы, как вы сами можете видеть, что разработчик не может иметь эксперного мнения в большинстве из них
Нет. Вы указали очень редкий случай разработки, а также Вы указали те этапы, которые Вы видите, которые Вы понимаете, и указали их так, как Вам удобно, не более чем. А далее, на основе крайне субъективного и недоказанного мнения, Вы сделали вывод о том, что сотрудник А знает меньше, чем сотрудник Б (так как Вы причисляете себя к сотруднику Б).
Лично я пока вижу совсем другое. Ниже будет моё субъективное мнение как руководителя, но я покажу ход рассуждений, которым я пользуюсь.
Вы занимаетесь определенной задачей (как я понимаю, вы продаете проект заказчику). Как часть этой задачи, Вы организовываете совещания. Вы не являетесь формальным экспертом в проекте, а потому довольно часто Вам приходится приглашать специалистов, чтобы они дали свою оценку.
Специалисты не общаются с клиентами так часто, как Вы. Как следствие, они могут действовать неэффективно с вашей субъективной точки зрения. Более того, Вы в принципе считаете, что разработчики не влияют на процесс, не понимают картину в целом и так далее.
На основе этого, вы вводите армейский стиль управления "я начальник - ты дурак", что неявно подтверждается вашими выводами выше.
Вместо этого, если бы Вы следовали рекомендациям @botyaslonim, Вам пришлось бы сделать вот такую вещь:
Определить, что конкретно Вам необходимо от специалистов на созвонах. Определить внутренние правила и регламенты.
На основе этого частного случая Вы могли бы выбрать более общую политику компании, которая была бы в стиле "мы действуем как единый коллектив, индивидуальные мнения (особенно аргументированные) запрещены при общении с заказчиком, приоритет компании на продажах, а не в стремлении к идеалу".
Ну а далее Вы просто-напросто могли бы требовать от сотрудников или согласия с политикой компании, или смены работы. И у Вас вообще не было бы никаких споров и жалоб, просто те люди, которые не согласны с такой политикой, выбирали бы другую фирму. Вам это стоит сделать всего лишь один раз, а далее этот вопрос бы ушёл бы практически полностью.
Почему Вы так не сделали? Что мешает Вам сделать регламент и политику, которая бы распространялась на коллектив?
Отвечу на этот момент. Это очень частый случай и вот почему :)
Нет, Вы не правы в контексте этой статьи (и сайта), так как очень малая доля именно сотрудников в IT имеют к этому отношение. И это очень важно: мы говорим не про мир в целом, мы не берем в расчет другие отрасли, мы именно говорим об IT и о разработке. Вот даже цитата из статьи:
Во-вторых, оценка многих руководителей на рынке труда стала трагично расходиться с их реальными достижениями. В IT в этом отчасти виновата стартап-культура, та самая культура, благодаря которой мы в IT добились огромного развития и выпуска невероятного количества самых разных продуктов.
Мы не рассматриваем все профессии мире в целом, мы именно говорим об этой теме. Более того, даже если условный бухгалтер работает в АйТи компании, это не делает его резко частью АйТи, по аналогию, если программист работает в банке, это не делает человек экономистом/банкиром.
Более того, давайте рассмотрим вот этот пункт:
Проект, к примеру по написанию ПО на заказ делится на приблизительные этапы:
Это не просто пример, это частный случай определенной разработки на заказ (от которой, в целом, отказываются: основная масса разработчиков работают или в компании напрямую, или через аутсорс, когда общение идет именно между специалистами двух фирм, но даже аутсорс очень плохо работает для хоть сколько-нибудь серьезных проектов).
Как следствие, вот эта фраза становится тоже интересной:
Поэтому ... скажем так, мнение людей, которые занимают позиция разработчика очень "ценно" :)
так как Вы говорите, что, в Вашем очень частном случае людей абсолютно не интересует мнение разработчика. И да, действительно, такое тоже бывает, вот только, в большинстве своем, квалифицированные специалисты не будут работать там, где не получается применять свою квалификацию, так как там просто платят мало (а кто будет платить за ненужную квалификацию?).
Далее Вы опять ошибаетесь:
И это важный момент. разработка в ИТ - эта лишь малая часть.
Вы перепутали и ставите телегу впереди лошади. Разработка в АйТи - это основное. В зависимости от того, что могут сделать специалисты, Вы будете делать тендер, от этого будет зависеть цена и прочие вещи, если же отсутствуют определенные нерыночные/коррупционные отношения.
Собственно, получается, что эта статья не покрывает Ваш частный случай, не более чем.
Нет, этот аргумент не прокатит, как как Ваша позиция строится именно на том обобщении. Более того, вот эта фраза не является корректным обоснованием:
И я вам скажу, позиций/должностей, которые имеют такую ситуацию до фига
, так как речь идет не о числе позиций/должностей, а о том, насколько частые в разработке/АйТи Ваш случай. Например, какая доля разработчиков Яндекс, ТАТА или Голдман Сакс вообще присутствуют на таких встречах? Ответ - очень малая доля пересекается с внешним заказчиком в таком режиме, как у Вас.
А потому, Ваш аргумент схож с "вот я работаю юристом и хожу в суды постоянно, а разработчики не понимают процессуальных тонкостей", ибо это редкое событие. А следовательно, корректным ответом будет "раз для других людей это редкость, то разумнее провести инструктаж, а если эта ситуация повторяется, то можно сделать документ/обучалку для сотрудников".
И вот это самый главный вывод, так как если мы подходим к формализации хотя бы части процессов, то мы и начинаем вводить культуру в коллективе. То есть это будет не продавец-самодур, который требует жесткого подчинения, а именно часть культуры компании, где будет определены роли в публичных продажах.
Как следствие, Ваша жалоба уйдет целиком, да еще и не только для Вас конкретно, но и для всей фирмы сразу.
Суть в том, что вы путаете внутренние встречи, где в целом такого нет, но и полноценными встречами их сложно назвать, с внешними
О том и речь. За мои 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.
На самом деле, основной совет должен быть "код должен легко поддерживать изменения в рамках ответственности проекта".
Условно говоря, если в проекте постоянно добавляются интеграции с другими сервисами, но всегда есть одна и только одна база данных, то можно смело рассчитывать на неизменность базы, но заодно следует готовиться к новым внешним сервисам.
Заодно правило выше будет толкать к написанию правильных текстов, к более читаемым и строгим типам, к наличию необходимой документации и корректного ревью кода.
Парниковый эффект меняет климат - где-то становится теплее, где-то холоднее. Условное таяние ледников запросто приведет к остановке гольфстрима, так что в Гренландии, Исландии, Норвегии и Швеции будет еще холодее.
Заодно запросто климат может поменяться на более засушливый (в некоторых районах), что создаст проблемы с земледелием. Ну или на более влажный, тогда будет больше рекордных наводнений и пр. Понятно, что, если есть возможность магическим образом перенести города чуть-чуть вбок, то проблем бы с теми же наводнениями не было, но, по факту, придется или строить дорогие дамбы, или сносить уже построенные здания (а города очень часто недалеко от рек, ибо в них очень много плюсов).
Также считается, что нарушение течения может стать результатом глобального потепления, поскольку на динамику течения оказывает значительное влияние солёность океанской воды, уменьшающаяся из-за таяния льдов. Возможно также влияние уменьшающейся разности температур между полюсом и экватором при усилении парникового эффекта. Таким образом, «глобальное потепление» грозит Европе катастрофическим похолоданием.
Время от времени хаотическое движение воздушных масс в атмосфере, а также взаимосвязанные с ними тепловые процессы на земле и в воздухе приводят к формированию исключительно крупных облачных объединений, содержащих огромное количество воды, которые накрывают довольно большие территории. В конечном итоге это приводит к обильным и продолжительным ливням. Если естественные водостоки в виде рек и почвы не успевают отводить выпадающую влагу, происходят наводнения. Мощные снегопады образуются практически по такой же схеме
В моем случае - https://github.com/Citi/gradle-helm-plugin . Создатель проекта перестал его поддерживать, а потому самая последняя версия ссылалась на уязвимые библиотеки.
Я думаю, что постепенно будет как в западных странах: сообщать будут gross, а люди сами будут считать налог (он же будет разный - чем выше ставка, тем выгоднее следить за вычетами).
Ну а фирма знает, сколько заплатит за год, а потому может посчитать эффективную ставку (например, будет 15.63%), так что каждый месяц будут отчислять именно эту долю от дохода (а не 13%). Если пришла премия, то пересчитают на лету. Если у человека есть дополнительные вычеты или доходы, то в конце года это сам человек покажет в декларации.
Увы, это не так, если говорить про крупные фирмы. Любой проект начинается с теории, можно ли вообще такое сделать, а здесь необходим специалист.
Как Вы будете определять бюджет без понимания того, что требуется сделать, а также опознавания того, что можно сделать?
Возможно, Вы не видите себя со стороны. Вы говорите, что Вы принимаете участие в этапах, которые Вы перечислил, не более чем.
И это частный случай для вашей компании, опять-таки. Далее Вы опять приводите примеры частных случаев того, как заведено у Вас. И да, вполне возможно, что есть и другие фирмы, в которых есть подобный же подход.
Вот только Ваш частный случай уже мало релевантен в компаниях, которые разрабатывают продукт для себя (или которые предоставляют сервис), так как их успех очень чувствителен к уровню разработчиков, которых нельзя вот так просто игнорировать.
Насколько я понимаю, у Вас в компании такого нет (судя по Вашим словам), а потому метод "я начальник - ты дурак" прекрасно работает.
Если взять реалии той же Британии (как частный случай), то выпускнику университета запросто будут платить £120.000 в год, плюс увеличьте эту сумму вдвое (чтобы учесть налоги и прочие косвенные затраты). Из-за высокой стоимости специалистов, компаниям становится очень дорого менять сотрудников. Как следствие из этого, армейский метод просто приводит к тому, что фирме не получается нанять людей, а далее она освобождает рынок.
Если Вы ошиблись и наняли не того человека, которого хотели (потому что Вы не сделали свою культуру более явной), то Вы потеряете около полугода, так как громадное число контрактов требуют уведомление об увольнении за три месяца, так что сначала Вы будете ждать не того человека, потом, поняв, что сотрудника требуется менять, Вы потеряете несколько месяцев на собеседования и еще три месяца на ожидание.
Подобная же проблема сейчас и в России (разве что в мягком виде): очень легко нанять стажеров, а потому к ним можно относиться и по-хамски, и с помощью армейского метода, тогда как квалифицированных специалистов нанимать долго и дорого.
А потому, вывод, если фирме нужны серьезные специалисты, то крайне рекомендуется следовать советам из статьи. Если же достаточно недорогих студентов, то действительно, управленцу не будет никакого смысла как-то там заморачиваться.
Повторюсь - это в вашем частном случае.
И Вы пока не смогли этого вообще доказать.
Вы же понимаете, что это зависит от компании и от её культуры? Для мелкого проекта и небольшой фирмы будут "ТЗ --> реализация --> доработка", для крупной фирмы и внутреннего проекта будет иной подход. В целом, в большинстве случаев, парадигма будет или в стиле водопада, или в стиле гибкой разработки, или в некоем гибриде, но так останется только на бумаге для инвесторов, так как реалии будут разными.
Но в чем смысл вопроса, если корректно получится показать только частный случай?
Но Вы пока не можете доказать или показать это, собственно, это только Ваши слова. На данном этапе Вы пока не можете даже обосновать, почему у Вас возникли сложности с регламентом поведения людей на переговорах, так что пока рано говорить о более серьезных вопросах.
Если разработчиков там нет, то это просто полностью отменяет Ваш аргумент под статьей, которая рассматривает разработку.
В чем смысл тогда был давать его?
Нет, не просто. На данном этапе:
Вы признались, что разработчики не принимают участия в тех процессах, на которые Вы жалуетесь, что приводит к следствию, что Ваш изначальный комментарий не относится к разработке в частности, а потому он не релевантнен со статьей.
Вы несколько раз повторили, что Вы никто не спрашивает вообще мнения разработчиков (откуда, правда, оно появилось, если их там нет).
Вы делаете вид, что занимаете высокий пост и много знаете о чем-то, но Вы даже не смогли составить регламент для переговоров.
Вы сначала жаловались на проблемы, а потом начали их отрицать. Вы сначала жаловались на разработчиков, а потом сказали, что они не принимают участия в вашей деятельности. Вы сначала говорите, что люди действуют некорректно, но сами Вы попытались перейти на хамство.
А потому, абсолютно непонятно, как Вы решали проблемы, которые Вы изложили, и почему метод автора Вы считаете некорректным (и какой тогда более корректный?).
Почему Вы так считаете? Пока что это Ваше предположение, которое будет, возможно, правдивым, когда в проекте только стажеры.
Я не понял этой фразы. Из неё следует, что разработчик не влияет на то, что он делает, ну то есть у Вас будто бы ChatGPT вместо специалиста.
Нет, Вы ошибаетесь еще раз. Это Ваш частный случай для разработки на заказ (то есть Вы сразу игнорируете условный фриланс и аутсорс), а это частный случай разработки в целом, тогда как основная масса продуктов выпускается именно своими разработчиками для компании.
Я правильно понимаю, что Вы считаете, что Вы единственный, которые всё это видит? Это уже близко к хамству, если честно.
Нет. Вы указали очень редкий случай разработки, а также Вы указали те этапы, которые Вы видите, которые Вы понимаете, и указали их так, как Вам удобно, не более чем. А далее, на основе крайне субъективного и недоказанного мнения, Вы сделали вывод о том, что сотрудник А знает меньше, чем сотрудник Б (так как Вы причисляете себя к сотруднику Б).
Лично я пока вижу совсем другое. Ниже будет моё субъективное мнение как руководителя, но я покажу ход рассуждений, которым я пользуюсь.
Вы занимаетесь определенной задачей (как я понимаю, вы продаете проект заказчику). Как часть этой задачи, Вы организовываете совещания. Вы не являетесь формальным экспертом в проекте, а потому довольно часто Вам приходится приглашать специалистов, чтобы они дали свою оценку.
Специалисты не общаются с клиентами так часто, как Вы. Как следствие, они могут действовать неэффективно с вашей субъективной точки зрения. Более того, Вы в принципе считаете, что разработчики не влияют на процесс, не понимают картину в целом и так далее.
На основе этого, вы вводите армейский стиль управления "я начальник - ты дурак", что неявно подтверждается вашими выводами выше.
Вместо этого, если бы Вы следовали рекомендациям @botyaslonim, Вам пришлось бы сделать вот такую вещь:
Определить, что конкретно Вам необходимо от специалистов на созвонах. Определить внутренние правила и регламенты.
На основе этого частного случая Вы могли бы выбрать более общую политику компании, которая была бы в стиле "мы действуем как единый коллектив, индивидуальные мнения (особенно аргументированные) запрещены при общении с заказчиком, приоритет компании на продажах, а не в стремлении к идеалу".
Ну а далее Вы просто-напросто могли бы требовать от сотрудников или согласия с политикой компании, или смены работы. И у Вас вообще не было бы никаких споров и жалоб, просто те люди, которые не согласны с такой политикой, выбирали бы другую фирму. Вам это стоит сделать всего лишь один раз, а далее этот вопрос бы ушёл бы практически полностью.
Почему Вы так не сделали? Что мешает Вам сделать регламент и политику, которая бы распространялась на коллектив?
Нет, Вы не правы в контексте этой статьи (и сайта), так как очень малая доля именно сотрудников в IT имеют к этому отношение. И это очень важно: мы говорим не про мир в целом, мы не берем в расчет другие отрасли, мы именно говорим об IT и о разработке. Вот даже цитата из статьи:
Мы не рассматриваем все профессии мире в целом, мы именно говорим об этой теме. Более того, даже если условный бухгалтер работает в АйТи компании, это не делает его резко частью АйТи, по аналогию, если программист работает в банке, это не делает человек экономистом/банкиром.
Более того, давайте рассмотрим вот этот пункт:
Это не просто пример, это частный случай определенной разработки на заказ (от которой, в целом, отказываются: основная масса разработчиков работают или в компании напрямую, или через аутсорс, когда общение идет именно между специалистами двух фирм, но даже аутсорс очень плохо работает для хоть сколько-нибудь серьезных проектов).
Как следствие, вот эта фраза становится тоже интересной:
так как Вы говорите, что, в Вашем очень частном случае людей абсолютно не интересует мнение разработчика. И да, действительно, такое тоже бывает, вот только, в большинстве своем, квалифицированные специалисты не будут работать там, где не получается применять свою квалификацию, так как там просто платят мало (а кто будет платить за ненужную квалификацию?).
Далее Вы опять ошибаетесь:
Вы перепутали и ставите телегу впереди лошади. Разработка в АйТи - это основное. В зависимости от того, что могут сделать специалисты, Вы будете делать тендер, от этого будет зависеть цена и прочие вещи, если же отсутствуют определенные нерыночные/коррупционные отношения.
Собственно, получается, что эта статья не покрывает Ваш частный случай, не более чем.
Нет, этот аргумент не прокатит, как как Ваша позиция строится именно на том обобщении. Более того, вот эта фраза не является корректным обоснованием:
, так как речь идет не о числе позиций/должностей, а о том, насколько частые в разработке/АйТи Ваш случай. Например, какая доля разработчиков Яндекс, ТАТА или Голдман Сакс вообще присутствуют на таких встречах? Ответ - очень малая доля пересекается с внешним заказчиком в таком режиме, как у Вас.
А потому, Ваш аргумент схож с "вот я работаю юристом и хожу в суды постоянно, а разработчики не понимают процессуальных тонкостей", ибо это редкое событие. А следовательно, корректным ответом будет "раз для других людей это редкость, то разумнее провести инструктаж, а если эта ситуация повторяется, то можно сделать документ/обучалку для сотрудников".
И вот это самый главный вывод, так как если мы подходим к формализации хотя бы части процессов, то мы и начинаем вводить культуру в коллективе. То есть это будет не продавец-самодур, который требует жесткого подчинения, а именно часть культуры компании, где будет определены роли в публичных продажах.
Как следствие, Ваша жалоба уйдет целиком, да еще и не только для Вас конкретно, но и для всей фирмы сразу.
О том и речь. За мои 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 у меня получилось написать такую статью, чтобы её одобрило НЛО в песочнице.