Pull to refresh
6
0.1
Павел Гольцев @pesh1983

User

Send message

Я имел ввиду задачи, которые закрывают люди, которых вы набираете, а не вы сами.

Да на самом деле неважно, какие конкретно задачи. Любую задачу можно сделать так, что вроде как задача и готова, исполнитель ее закрыл, а по факту сделана некачественно. И это выясняется в процессе эксплуатации, и не факт что сразу.

Я очень рад за вас, если ваши исполнители все делают качественно и в срок и никогда не косячят. Но это не значит, что везде такие же задачи, как у вас и такие же бравые ребята. И контроль качества в любом деле лишним не бывает, а иногда и жизненно необходим.

продуктивность достаточно просто считается - количество задач, которое моя команда може сделать за какое-то время

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

А откуда у вас такая статистика?)) Общемировой тренд как раз таки другой - увеличение возраста родителей до появления первого ребенка. Причиной тому желание построить карьеру, пока молодой, увеличение продолжительности жизни, больше возможностей для женщины не зависеть от мужчины и семьи и ещё много других мелких. Поэтому люди могут заводить первого ребенка и в 30 и позже. А в таком возрасте специалист уже может дорасти и до уровня сеньера. Ну и не все останавливаются на 1 ребенке, у меня например 2 и третий на подходе. А я уже который год работаю на руководящей позиции. У многих моих знакомых от двух детей, и их больше, чем тех, у кого один.

Наличие маленьких детей редко коррелирует с уровнем профессионализма) Может быть конечно сеньер чуть лучше работает с постоянно отвлекающими и орущими детьми, но вряд ли разница сильно заметна. В обоих случаях получается хуже, чем без отвлекающих факторов.

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

Докер унифицирует среду выполнения и процесс сборки и запуска в ней. Это значительно исключает ситуацию бага и разработчика, у которого "все работает локально, ничего не знаю", а там оказывается версии библиотеки в ОС у разраба и на сервере разные. Так что зря вы на докер катите. Это одна из хороших практик и необходимость, нежели переусложнение. Вдобавок докер изолирует все зависимости от системы, и у вас исключается ситуация, когда один проект требует одну версию интерпретатора/компилятора и версии библиотек в системе, а другой -другие, а третий - третьи. И как вы все это будете устанавливать и обслуживать на одной машине без изоляции - большой вопрос и отдельная очень "интересная" тема.

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

Этого вполне можно добиться, если конфигурация проекта локально отличается от конфигурации на сервере. Например, фиче-флаги выставлены по-другому. С этим надо быть аккуратнее))

Это вы меня извините) На моей практике изменение именно апи слоя не вызывало каких-то серьезных затрат. Значительное время обычно занимала как раз изменение логики работы с апи и подготовки данных запроса и ответа. Поэтому название статьи интерпретировал не так, как вы задумыаали.

Я вам про Ивана, вы мне про ... Мы не обсуждаем, что и куда утекло. У вас в статье написано

Некоторые из них прибегают к автогенерации кода на основе схем Swagger, другие переписывают код вручную. Однако эти подходы требуют значительных ресурсов и времени, а также часто приводят к избыточному коду, который растет в объеме вместе с количеством задействованных в коде методов API. В данной статье я хочу поделиться методом, который позволяет избежать этих сложностей.

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

Тогда резюмируя все вышесказанное при существенном изменении API придется менять не только слой апи и вот эти вот интерфейсы, но и логику получения данных независимо от того, где она находится. Вот поэтому я и не понял, как ваш подход избавляет от этого.

Вы забыли, что надо ещё поменять логику запроса этих данных. Ранее одного запроса было достаточно, теперь надо делать два. Причем может случиться так, что нагрузка запроса тоже поменялась. Тут простым изменением интерфейса тайпскрипта не обойтись. Придется менять логику получения данных и их обработку. Если все это инкапсулировать в отдельный класс/объект/модуль, то это модуль в любом случае придется постоянно переписывать при таких изменениях.

Статью я прочитал, но видимо не понял всех плюсов решения. Давайте разберём реальный кейс. Допустим, у нас была логика: запрашиваем URL url1/common1, возвращается структура

{
  "key1":"val1",
  "key2":"val2"
}

API поменялось, теперь надо запрашивать 2 URL'а: url/entity2 и url/entity3, возвращается соответственно

{
  "key1": {
    "key3": "val1"
  }
}

и

{
  "key4": "val2"
}

Какой должен быть интерфейс старого API и как мне нужно его поменять на стороне клиента, чтобы адаптировать под новый API?

Вместо поддержки слоя API вы предлагаете поддерживать слой прокси. Апи может так поменяться, что никакой прокси слой не спасет. Ну и потом, не весь бэк на ноде пишется и не везде на бэке используется тайпскрипт. Все это как мёртвому припарка.

Макось вполне способна ворочаться на 8гб . Учитывая, что это air, а не про, ЦА этой модели не компилирует мегабайты кода и не монтирует гигабайты видео на этом. Если этого не делать,с 8гб и с быстрым свопом рядовой пользователь дискомфорта ощущать не будет. Браузер, просмотр видео, работа с документами, редактирование фотографий, подготовка отчётов, презентаций, проведение конференций - вот под эти задачи вполне хватит. Зачем переплачивать за 16гб? Кому надо, тот добавит в конструкторе на сайте эппла и закажет кастомизированную версию. Мой жене вполне 8гб с головой хватит

Вы не учитываете, что затраты (временные и финансовые), которые необходимо потратить на это, непропорционально велики по сравнению с прибылью, которую компания сможет извлечь из этого. Вдобавок, рост потребности в ресурсах стимулирует рынок железа. Все в выгоде. И как вообще продавать эту вашу оптимизацию - непонятно. Я вот прям представляю, как маркетологи говорят "наша ос стала в 2 раза быстрее по сравнению с предыдущей версией", а рядовому потребителю мягко говоря все равно. Ибо он уже давно купил достаточно мощное железо, чтобы на замечать разницы между условно 1.и 0.5 секундами задержки. А те, кто сидит на старом железе, новую ос не факт что могут поставить, ибо набор команд процессора может уже не поддерживаться, нет secure boot и прочих улучшений, без которых винда ну никак не запустится) Вы мыслите с точки зрения потребителя и только в целях экономии железа, а интересы компании совсем не рассматриваете.

Правильное поведение - это когда тип конвертируется всегда одинаково. Но в примере выше что-то пошло не так) И это далеко не правильное поведение.

Вот поэтому js и "не любят". Потому что там есть вещи, которые выглядят, как надёжные, но работают мягко говоря не надежно, и которые, как оказывается, "никто не использует", но они зачем-то есть. Обо что часто и спотыкаются новички. Ибо эти сакральные знания приходят с опытом.

Чтобы не объедались, компания заботится о весе сотрудников)

Что характерно, одно время ваши сотрудники всё-таки пользовались сканером, потом перешли на мобилки.

1
23 ...

Information

Rating
3,135-th
Location
Москва, Москва и Московская обл., Россия
Date of birth
Registered
Activity