Информация

Дата основания
Местоположение
Россия
Сайт
vdsina.ru
Численность
11–30 человек
Дата регистрации

Блог на Хабре

Обновить
Комментарии 66
В статье не описано отношение других коллег к Л. Если он был так плох, то общее отношение к нему команды сделало бы свое дело. А если им был недоволен только автор, то, возможно, дело в авторе.
Если менеджеры не увольняют «Л» — то, похоже, не так все плохо, как описывает автор. Возможно, у Л есть другие плюсы, которые перевешивают минус по программированию.
вполне возможно что другим разработчикам пофиг на Л так как они с ним не пересекаютс либо даже их всего две-трое на проекте, а менеджер в коде не понимает
В статье не описано отношение других коллег к Л. Если он был так плох, то общее отношение к нему команды сделало бы свое дело. А если им был недоволен только автор, то, возможно, дело в авторе.


В статье видна желчь автора.
Л. раздражает его по мелочам.

Так ли плох Л. или не так ли плох — этого не прослеживается в статье.

А вот отношение автора к Л. — да, это видно.

Мне встречались такие Л., с ними работает только один способ.
«Постигать дзен на берегу реки, наблюдая за течением, в ожидании...»

Ну просто стандартная вещь: фронт не смог договориться с бэком, а менеджер не смог разрулить. Можно точно такую же статью написать от имени бэкендера, как фронт перекладывать свои задачи на бэк. Здесь решает только арбитр.

Я бы сказал что согласно RFC антигерой статьи убрал 204 код правильно.


The 204 response allows a server to indicate that the action has been successfully applied to the target resource, while implying that the user agent does not need to traverse away from its current "document view" (if any).


И что-то с 206 меня тоже смущает

Как я понимаю, он не остался бы антигероем до конца, если бы обсудил эти изменения.

Был аналогичный опыт с другим «Л». Только, когда «Л» перевели на другой проект и там не выдержал фронтендер — уволился, передо мной извинились. Я понимаю автора, это очень выматывает каждый день работать с человеком который не хочет слушать и искать компромиссы.

И фронтендеры тут оказываются под ударом, т.к. руководство и клиенты никогда не увидят бекенда. А хороший дом на кривом фундаменте не построить. В какой-то момент замечаешь, что больше 50% времени борешься с проблемами которых можно было бы избежать при нормальном api или которых даже не пришлось бы решать, т.к. должна решаться на уровне бекенда и запросов к БД.
Как я понимаю, он не остался бы антигероем до конца, если бы обсудил эти изменения.

Мы не знаем какие отношения сложились между "антигероем" и "героем". Возможно с его точки зрения все было как раз наоборот. Герой точно так же мог достать своего коллегу некомпетентностью (статус коды не дают мне покоя). И ответы на отвали тоже могли появиться на этой почве.

Я исхожу из описанного кейса, и додумывать не буду. Будут другие вводные, может быть поменяю мнение.

Что-то мне подсказывает, нормальный исход заключался бы в том, что оба поговорили бы и один рассказал что нужно для фронта, второй бы написал правильные статусы на бекенде для разных ситуаций.

Я работал и с хорошими бекендерами и с аналогом «Л». И симптомы похожи.

При работе с хорошим бекендером у меня ни разу не закралась мысль, что будет проще самому написать нужную реализацию, всегда все можно было объяснить и договорится о лучшем дизайне api как с точки зрения стандартов проектирования так и работы с ним на фронте.
Что-то мне подсказывает, нормальный исход заключался бы в том, что оба поговорили бы и один рассказал что нужно для фронта, второй бы написал правильные статусы на бекенде для разных ситуаций.

В нормальной команде — да, конечно. Но тут конфликт и есть подозрение что виноват может быть более чем один человек. И для таких выводов есть предпосылки в самом же кейсе.


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

У меня был не очень приятный опыт с «другой стороны окопа». Писал бек для одного проекта и работал с фронтом. Делали апи для одной задачи, я подошел к фронту с целью обсудить этот апи и понять в каком виде данные ему будут нужны и вообще как он видит процесс работы с апи со стороны фронта. На что получил ответ, практически буквально: да мне пох… ю, пиши как хочешь. Ну, ок, написал сначала на заглушках, как сам понимал, отдал ему, он посмотрел (надеюсь), отвечает что мол все ок. Я делаю все уже не на заглушках, а нормальную реализацию, после мне прилетает куча претензий о том что апи не правильный, фронту надо было так и вот эдак, и плюс к этому жалобы «наверх» о том что бек опять все испортил и не дает фронту нормально работать.

Я оттуда уже ушел из-за таких вот фокусов и не только, по целому ряду причин.
Ну, ок, написал сначала на заглушках, как сам понимал, отдал ему, он посмотрел (надеюсь), отвечает что мол все ок. Я делаю все уже не на заглушках, а нормальную реализацию, после мне прилетает куча претензий о том что апи не правильный, фронту надо было так и вот эдак, и плюс к этому жалобы «наверх» о том что бек опять все испортил и не дает фронту нормально работать.

Я оттуда уже ушел из-за таких вот фокусов и не только, по целому ряду причин.


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


Больше бумаги — чище сфинктер, разве жизнь этому не учит? Особенно в крупных корпорациях.
Там была не крупная корпорация.
В эти игры я тоже умею играть. Умею, но не хочу, потому из одной «крупной корпорации» в свое время и ушел.
Иногда без бумажек не обойтись, но всему должна быть мера, когда для простой задачки на пару дней работы надо ворох бумаги подписать — значит с организацией работы тут явно что-то не так.
Да, автор смахивает на "идеалиста". Кому нужны это 4 кода ответа, когда логика их обработки будет ветвиться от наличия ошибки.
Второй запрос для частичных ответов не нужен, если в ответе указать, что нашлось а что нет.

Формат запроса/ответа надо было описать в требованиях к API. А семантику в стандарте написания API этой команды\компании. Вместо хейта коллеги, надо было разбираться с процессами.
Вообще, подобная ситуация (если все описанное правда) может возникнуть только в одном случае: отсутствует компетентный тимлид или техдир, способный адекватно оценить реализацию при возникновении разногласий.

В ином случае роляют внерабочие отношения и тут вообще возможна любая дичь :)
выдавать 500 тоже не верно, правильней 400.
Почему неправильный API запрос должен отдавать код 500 Internal Error? При не правильном запросе должно выдаваться 400 Bad Request (неправильный, некорректный запрос).

Где вы там увидели неправильный запрос?

Потому что автор изначально выставил ответ 500, по его мнению это видимо «ответ на неправильный запрос» что не верно. 400 Bad Request будет правильней.

Он это выставил для "Ошибка сервера".

500 Internal Error — записывается в отдельный лог «errors» web сервера, не в лог «access». В итоге у автора получиться так что сервер вернул его выставленное принудительно состояние HTTP-500 Internal error, а в логах errors его не будет. Отдавать код состояния 500 должен сам web сервер если действительно произошла ошибка с соответствующим вываливанием сообщения об ошибке в лог.

Какой-то кривой у вас вебсервер, не используйте его.

Apache? Я думаю что Роберт Маккул с вами не согласиться.
Вы либо не компетентны в этом вопросе либо принципиально не хотите понимать суть моих ответов. Объясняю… Если принудительно указать код ответа 5xx Server Error даже если в самом web сервере не произошло ошибок то данное действие попадет в лог access, а не в лог errors. Тип ошибок 5xx Server Error должны относиться только к работе самого Web сервера и не должны контролироваться вашим скриптом/кодом.

5xx Server Error = описывает состояние самого Web сервера, и только ему решать что из 5xx выдать клиенту.

Почитайте, пожалуйста, спецификацию и не мелите ерунды: https://tools.ietf.org/html/rfc7231#section-6.6


Апач в httpd/error.log пишет свои внутренние ошибки. В httpd/access.log — запросы/ответы. Если вам нужен отдельный лог ошибок вашего сервера, то это настраивается отдельно от апача. Коды ответов сервера тут вообще ни при чём.

Фу, как грубо и вульгарно в разговоре двух джентельменов скидывать ссылку на RFC.
У нас нет кодревью, коллеги творят кто во что горазд. Кто виноват? Л! Посмел изменить мои коды состояния!

Интересно также и почему это человек, занимающийся фронтэндом должен ревьюить код бэкэндера? Ну он может это делать конечно, но в режиме "высказать мнение", которое бэкэндер в полном праве может проигнорировать. Это же не баг. А мнение человека, который смотрит на этот код с точки зрения фронта. С чего вдруг ему должно быть лучше видно? Там должны быть другие бэкэндеры для ревью. А они могут иметь свою точку зрения.

Фронтендер не должен ревьюить бекэндера, но может при большом желании, почему нет?


А вот что они должны были сделать — так это договориться "на берегу" по поводу контракта между беком и фронтом. Какие ответы в каких случаях, какие коды, что в теле и т.д.


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

Предложи руководству ввести обязательный код ревью что бы таких ситуаций не было. Если кто то реально говнокодит то ему придется переделывать пока не будет нормально
Так автор оригинала как раз пытался код ревью продавливать, но ему отказывают судя по всему.
Так как у нас не было ревизий кода (code review), которые я упорно стремился внедрить

Цитата из статьи.
«Он выполнял много работы и вся она была низкокачественной. Он не соблюдал отраслевые стандарты и стремился выполнять как можно меньше работы.» — это как?

По опыту могу сказать что менеджерам интересны только цифры. Т.е. более эффективной стратегией возможно было бы показать сколько часов требуется на переработки и сколько багов было внесено из-за некомпетентности разработчика.

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

Как человек, который работал системным администратором, интегратором, девопсом, сетевым администратором (то есть за свою жизнь занимался поддержкой пользователей, сети, серверов, разрабов и бизнеса целиком) могу сказать, что часто отделами можно подписать под «ужасных разработчиков» :)

< sarcazm >
"«навыки работы с людьми» важнее «навыков кодинга»,".
Не JavaScript учить надо, а педагогику и психологию. У Л. может внутренние психологические проблемы и больная морская свинка дома. И ему нужна забота и внимание. А не качество проекта. Да еще и жалобы до менеджмента доходят.
< /sarcazm >
В таких ситуациях, если ты не СТО, я думаю, лучшее решение — обновить резюме на разных сайтах. Иначе будет вечное страдание, и жалобы в Интернете. В ситуации виноваты вообще все. И Л., который такой сумрачный гений. И автор, который жалуется в статье и менеджменту, а решений не предлагает, и менеджмент, который не интересуется, как там показатели эффективности разработки на большом промежутке времени.

Пилил я как-то фронт (мобилку) для одной программы лояльности… Доки никакой нет, естесс-но(!), но есть сайт, который вполне себе можно задебажить. Хм… но в логах все запросы возвращают 400. В результате: все эндпойнты на все запросы отвечают 400 (Bad request), но если заглянуть в сообщение ошибки внутри лежит себе int код состояния (которых, оказывается, десяток разных придуман) и мессадж на вполне себе человеческом языке.
Открыли тикет, конечно, по этому поводу бэкендерам, но фичу сделали (делов-то кастомный ResponseConverter) — весь функционал работает.
PS тикет на бэке делать не стали :(
PSS ИМХО статья про то, как перфекционист с пофигистом встретились.

Завернуть все в 400 это прекрасно. А почему выбор пал именно на 400 не подскажете?

Точно не отвечу: мне сказали что разработчик ЭТОГО не работает уже. Но теоретически — слабенький способ защититься от DDOS ботов подбора пар номер/СМСкод (лоялка — это какие-никакие деньги).

Не хватает в статье как раз менеджерских моментов, сколько получал «Л», его таск борд, и желательно общий уровень компетенций. Кроме нежелания общаться с автором которое возможно имело предпосылки и выдуманного для себя автором образа этого «Л» в статье в основе лишь жалобы.
У нас на работе был похожий «Л» — начальству он на собеседовании понравился строгим и солидным выражением лица. Проблема в том, что он оказался не разработчиком АСУ, а наладчиком, и текущую работу выполнять не мог от слова совсем. При этом, вместо того чтобы все свободное время изучать новую специальность — он все выходные проводил на рыбалке (рыбак он был отменный надо признать, показывал нам фотки — там были такие здоровенные рыбины!). И начальство его не увольняло, т.к. это означало бы расписаться в своей ошибке (а начальство не может ошибаться). Испытательный срок он уверенно прошел, его работу мы постоянно переделывали, втолковать ему что либо было бесполезно — он молча выслушивал наши претензии и с тем же строгим выражением лица продолжал творить лютую дичь. И так проработал 10(!) месяцев, потом жестко накосячил с важным проектом и только тогда уволили с выплатой 3-х окладов
По моему опыту: в крупной корпорации срок от найма совершенно некомпетентного работника до его увольнения составляет как раз примерно год, плюс-минус три месяца. Эта махина просто не может двигаться быстрее.
Поэтому если вы видите работника с 15 местами работы по году — это далеко не всегда означает что он крутой специалист.

Не совсем понял: надо пожалеть или похвалить автора статьи?

Как подробно о необходимости CodeReview и каких-никаких стандартов кодирования/да и проведения митингов в команде.

Но переходить на личности нехорошо, имхо («с очень ужасным разработчиком»). Максимум что вы можете видеть это качество его конкретного итогового кода и работы, и да, причины могут быть разными.
А какая должна быть правильная реакция менеджмента? Ну т.е. сидит такой менеджер, думает о каких-то своих менеджерских проблемах, а тут приходит разработчик и начинает жаловаться на другого. При этом этот другой заметен в коллективе, т.е. по тихому решить не получится. Ну т.е. если выбирать, то менеджер предпочел чтобы автор бы уволился сам, тогда и проблема решилась бы. Ну или если обострять, то тогда лучше наверное уволить автора, если у него не ключевая роль в проекте и какая-нибудь замена формально есть
Если автор — мазохист, тогда ладно.
В 21 веке бояться найти другую работу — просто нонсенс.
В 21 веке бояться найти другую работу — просто нонсенс.


2008 год в NYC никогда не видели? Когда сокращали этажами. Lucky you are, что сказать.
«Если у вас никогда не было такого опыта, я вам завидую» значит, что этот халтурщик — вы сами :D

Очень спорная статья.
Единственные претензии с какой-то факрурой — коды HTTP ответов. И по поводу этих кодов всегда куча холиваров.
С другой стороны отдавать 500 при отсутствии результата странно само по себе, так что хз.

Создаётся впечатление, что автор хочет вселенской справедливости. А ее, как известно, нет. По-человечески сочувствую автору, что приходится работать на контрах с коллегой, но из текста понятно только то, что это действительно переросло в личный конфликт.
ИМХО, здесь 2 пути, уйти самому, или взять на себя роль рыцаря в белом и доказать, что антигерой именно таков, как его описали, проще говоря, подставить в нужный момент (перед этим запаситесь нужным рефери, который укажет именно на недостатки кода противника) и так несколько раз.
Отличный бы получился рассказ, если бы было ещё 2 мнения, Л. и менеджера. Может быть именно менеджер ждёт реальную доказательную базу под увольнение)

1.В чужой монастырь со своим уставом не ходят.
2. Хотели как лучше, а получилось как всегда.

Расшифровываю. Есть уже апи бакенда. Плохое или хорошее не важно.
Главное оно как-то знакомо всем участникам разработки. Возможно стандартизировано.
В остальных местах ответ от него достаточно сравнивать с 200, чтобы узнать об успехе.
Теперь в «одном» методе вы просите ввести 3 кода успеха.
Млин N-1 разработчик теперь должны помнить, что если им потребуется этот метод, то код
надо писать «по другому».

Имхо одного этого достаточно. Есть стандарт. следуем ему.
10 стандартных методов лучше 10 идеальных, но требующий индивидуального подхода.

Чтобы узнать об успехе достаточно сравнить первую цифру с двойкой. Всё.

Чего это вы стесняетесь индуса называть индусом? У меня тоже был чудесный релевантный опыт. Ревьюил я как-то код нашего индуса и увидал там примерно следующее:


class EventHandler {

    updateState() {
        // ...
    }

    nope() {}

    handle( isRemote: boolean ) {
        isRemote ? this.updateState() : this.nope()
    }

}

Я объяснил, что подобный код не имеет смысла и его можно переписать куда проще, не добавляя лишних методов в класс, на что он мне ответил в духе "мне так нравится". Когда же я ему ответил, что не готов аппрувить говнокод, ко мне прибежал начальник с претензией, что этот индус на меня жалуется. Объясняя, что да, программист он такой себе, но нам нужно быть деликатнее, ведь нам нужно вытянуть хоть какую-то пользу из этого работника, ибо нанять нормальных программистов в России мы не можем из-за политики компании.


Однако, фактически на ревью его кода мы командой потратили больше времени, чем если бы сами сразу написали нормальный код.

Хм а зачем тут вызов nope?
Я такой подход видел когда хотят избавиться от проверки на null, например как тут:


function nope() {}

function handler(onDone = nope) {
  ...
  onDone();
}

Но зачем лишний вызов тут?

Я же написал — "ему так нравится". Это вообще непробиваемый аргумент.

И, справедливости ради, я пофиксил ваш список кодов:


Возвращённое        Код HTTP
количество
10               200 (полный успех)
1-9              206 (неправильно)
0                204 (неправильно)
Ошибка сервера   500 (исключение)

И дело тут не в "разных подходах", а в том, что ваш креатив противоречит спецификации HTTP.

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

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

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


Вас насильно держат на работе что-ли? Ну не сошлись с кем-то — уволились и все. Тоже мне проблема.


Увольняться только потому что кто то другой халтурит?
Кто то другой.

Серьезно, увольняться нужно из-за этого?
Это же не 3 метровый амбал бьет вас по голове табуреткой каждый день, а вы сделать ничего не можете. Он просто халтурит.

Строго говоря, это вообще не ваша проблема, а проблема фирмы, она меньше получает прибыли.

Увольняться только потому что кто то другой халтурит?

Если человека это так беспокоит, что он создал отдельную тему — то почему бы и нет? Или вы считаете, что нужно терпеть? Тут, как говорится, каждый сам выбирает, как ему жить.
Увольняться только потому что кто то другой халтурит?


Если человека это так беспокоит, что он создал отдельную тему — то почему бы и нет? Или вы считаете, что нужно терпеть? Тут, как говорится, каждый сам выбирает, как ему жить.


Я считаю что что то не так с автором статьи.
Он мелкие придирки изложил подробно и развернуто.
В другом месте у него будет то же самое.
Проблема в его собственной голове. Не в других.
Извините, но почему вы перевели заголовок «I Write an Endpoint» как «Я пишу конечную точку»?

«Я пишу новый метод API», например.
Это гугл-транслейт переводил. Вопрос надо ему адресовать.

Мне ещё вот это нравится:
This guy was supposed to be their back end expert. = Этот человек должен был оказаться специалистом по бекэнду.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.