Comments 66
В статье не описано отношение других коллег к Л. Если он был так плох, то общее отношение к нему команды сделало бы свое дело. А если им был недоволен только автор, то, возможно, дело в авторе.
В статье видна желчь автора.
Л. раздражает его по мелочам.
Так ли плох Л. или не так ли плох — этого не прослеживается в статье.
А вот отношение автора к Л. — да, это видно.
«Постигать дзен на берегу реки, наблюдая за течением, в ожидании...»
Ну просто стандартная вещь: фронт не смог договориться с бэком, а менеджер не смог разрулить. Можно точно такую же статью написать от имени бэкендера, как фронт перекладывать свои задачи на бэк. Здесь решает только арбитр.
Был аналогичный опыт с другим «Л». Только, когда «Л» перевели на другой проект и там не выдержал фронтендер — уволился, передо мной извинились. Я понимаю автора, это очень выматывает каждый день работать с человеком который не хочет слушать и искать компромиссы.
И фронтендеры тут оказываются под ударом, т.к. руководство и клиенты никогда не увидят бекенда. А хороший дом на кривом фундаменте не построить. В какой-то момент замечаешь, что больше 50% времени борешься с проблемами которых можно было бы избежать при нормальном api или которых даже не пришлось бы решать, т.к. должна решаться на уровне бекенда и запросов к БД.
Что-то мне подсказывает, нормальный исход заключался бы в том, что оба поговорили бы и один рассказал что нужно для фронта, второй бы написал правильные статусы на бекенде для разных ситуаций.
Я работал и с хорошими бекендерами и с аналогом «Л». И симптомы похожи.
При работе с хорошим бекендером у меня ни разу не закралась мысль, что будет проще самому написать нужную реализацию, всегда все можно было объяснить и договорится о лучшем дизайне api как с точки зрения стандартов проектирования так и работы с ним на фронте.
Я оттуда уже ушел из-за таких вот фокусов и не только, по целому ряду причин.
Ну, ок, написал сначала на заглушках, как сам понимал, отдал ему, он посмотрел (надеюсь), отвечает что мол все ок. Я делаю все уже не на заглушках, а нормальную реализацию, после мне прилетает куча претензий о том что апи не правильный, фронту надо было так и вот эдак, и плюс к этому жалобы «наверх» о том что бек опять все испортил и не дает фронту нормально работать.
Я оттуда уже ушел из-за таких вот фокусов и не только, по целому ряду причин.
Если он письменно подтвердил, что подходит — с этой жалобой он сам себе злой буратино.
Так как любому вменяемому менеджеру проекта (или какой там был над вами начальник) видно, что человек просто косячит и пытается свои косяки свалить на другого. Очень хорошо видно.
и не приходится каждый мелкий рабочий момент сопровождать ворохом подписанных бумажек
Больше бумаги — чище сфинктер, разве жизнь этому не учит? Особенно в крупных корпорациях.
В эти игры я тоже умею играть. Умею, но не хочу, потому из одной «крупной корпорации» в свое время и ушел.
Иногда без бумажек не обойтись, но всему должна быть мера, когда для простой задачки на пару дней работы надо ворох бумаги подписать — значит с организацией работы тут явно что-то не так.
Второй запрос для частичных ответов не нужен, если в ответе указать, что нашлось а что нет.
Формат запроса/ответа надо было описать в требованиях к API. А семантику в стандарте написания API этой команды\компании. Вместо хейта коллеги, надо было разбираться с процессами.
Почему неправильный API запрос должен отдавать код 500 Internal Error? При не правильном запросе должно выдаваться 400 Bad Request (неправильный, некорректный запрос).
Где вы там увидели неправильный запрос?
Он это выставил для "Ошибка сервера".
Какой-то кривой у вас вебсервер, не используйте его.
Вы либо не компетентны в этом вопросе либо принципиально не хотите понимать суть моих ответов. Объясняю… Если принудительно указать код ответа 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 — запросы/ответы. Если вам нужен отдельный лог ошибок вашего сервера, то это настраивается отдельно от апача. Коды ответов сервера тут вообще ни при чём.
Интересно также и почему это человек, занимающийся фронтэндом должен ревьюить код бэкэндера? Ну он может это делать конечно, но в режиме "высказать мнение", которое бэкэндер в полном праве может проигнорировать. Это же не баг. А мнение человека, который смотрит на этот код с точки зрения фронта. С чего вдруг ему должно быть лучше видно? Там должны быть другие бэкэндеры для ревью. А они могут иметь свою точку зрения.
Фронтендер не должен ревьюить бекэндера, но может при большом желании, почему нет?
А вот что они должны были сделать — так это договориться "на берегу" по поводу контракта между беком и фронтом. Какие ответы в каких случаях, какие коды, что в теле и т.д.
Как они уже будут этот контракт реализовывать — детали конкретных реализаций, но сам контракт должен быть зафиксирован и не изменяться без согласования со всеми сторонами. А в реальной разработке изменения с большой вероятностью нужно будет ещё и версионировать чтобы прозрачно провести перевод пользователей со старых клиентов на новый.
По опыту могу сказать что менеджерам интересны только цифры. Т.е. более эффективной стратегией возможно было бы показать сколько часов требуется на переработки и сколько багов было внесено из-за некомпетентности разработчика.
< sarcazm >
"«навыки работы с людьми» важнее «навыков кодинга»,".
Не JavaScript учить надо, а педагогику и психологию. У Л. может внутренние психологические проблемы и больная морская свинка дома. И ему нужна забота и внимание. А не качество проекта. Да еще и жалобы до менеджмента доходят.
< /sarcazm >
В таких ситуациях, если ты не СТО, я думаю, лучшее решение — обновить резюме на разных сайтах. Иначе будет вечное страдание, и жалобы в Интернете. В ситуации виноваты вообще все. И Л., который такой сумрачный гений. И автор, который жалуется в статье и менеджменту, а решений не предлагает, и менеджмент, который не интересуется, как там показатели эффективности разработки на большом промежутке времени.
Пилил я как-то фронт (мобилку) для одной программы лояльности… Доки никакой нет, естесс-но(!), но есть сайт, который вполне себе можно задебажить. Хм… но в логах все запросы возвращают 400. В результате: все эндпойнты на все запросы отвечают 400 (Bad request), но если заглянуть в сообщение ошибки внутри лежит себе int код состояния (которых, оказывается, десяток разных придуман) и мессадж на вполне себе человеческом языке.
Открыли тикет, конечно, по этому поводу бэкендерам, но фичу сделали (делов-то кастомный ResponseConverter) — весь функционал работает.
PS тикет на бэке делать не стали :(
PSS ИМХО статья про то, как перфекционист с пофигистом встретились.
Поэтому если вы видите работника с 15 местами работы по году — это далеко не всегда означает что он крутой специалист.
Не совсем понял: надо пожалеть или похвалить автора статьи?
Но переходить на личности нехорошо, имхо («с очень ужасным разработчиком»). Максимум что вы можете видеть это качество его конкретного итогового кода и работы, и да, причины могут быть разными.
В 21 веке бояться найти другую работу — просто нонсенс.
Очень спорная статья.
Единственные претензии с какой-то факрурой — коды HTTP ответов. И по поводу этих кодов всегда куча холиваров.
С другой стороны отдавать 500 при отсутствии результата странно само по себе, так что хз.
Создаётся впечатление, что автор хочет вселенской справедливости. А ее, как известно, нет. По-человечески сочувствую автору, что приходится работать на контрах с коллегой, но из текста понятно только то, что это действительно переросло в личный конфликт.
ИМХО, здесь 2 пути, уйти самому, или взять на себя роль рыцаря в белом и доказать, что антигерой именно таков, как его описали, проще говоря, подставить в нужный момент (перед этим запаситесь нужным рефери, который укажет именно на недостатки кода противника) и так несколько раз.
Отличный бы получился рассказ, если бы было ещё 2 мнения, Л. и менеджера. Может быть именно менеджер ждёт реальную доказательную базу под увольнение)
2. Хотели как лучше, а получилось как всегда.
Расшифровываю. Есть уже апи бакенда. Плохое или хорошее не важно.
Главное оно как-то знакомо всем участникам разработки. Возможно стандартизировано.
В остальных местах ответ от него достаточно сравнивать с 200, чтобы узнать об успехе.
Теперь в «одном» методе вы просите ввести 3 кода успеха.
Млин N-1 разработчик теперь должны помнить, что если им потребуется этот метод, то код
надо писать «по другому».
Имхо одного этого достаточно. Есть стандарт. следуем ему.
10 стандартных методов лучше 10 идеальных, но требующий индивидуального подхода.
Чего это вы стесняетесь индуса называть индусом? У меня тоже был чудесный релевантный опыт. Ревьюил я как-то код нашего индуса и увидал там примерно следующее:
class EventHandler {
updateState() {
// ...
}
nope() {}
handle( isRemote: boolean ) {
isRemote ? this.updateState() : this.nope()
}
}Я объяснил, что подобный код не имеет смысла и его можно переписать куда проще, не добавляя лишних методов в класс, на что он мне ответил в духе "мне так нравится". Когда же я ему ответил, что не готов аппрувить говнокод, ко мне прибежал начальник с претензией, что этот индус на меня жалуется. Объясняя, что да, программист он такой себе, но нам нужно быть деликатнее, ведь нам нужно вытянуть хоть какую-то пользу из этого работника, ибо нанять нормальных программистов в России мы не можем из-за политики компании.
Однако, фактически на ревью его кода мы командой потратили больше времени, чем если бы сами сразу написали нормальный код.
И, справедливости ради, я пофиксил ваш список кодов:
Возвращённое Код HTTP
количество
10 200 (полный успех)
1-9 206 (неправильно)
0 204 (неправильно)
Ошибка сервера 500 (исключение)И дело тут не в "разных подходах", а в том, что ваш креатив противоречит спецификации HTTP.
Вообще кажется, что Л. следовал API гайдлайнам, принятым у них на проекте для бэкенда, поэтому и переписал говнокод автора, заодно выбросив неправильно использованные HTTP коды. Автор статьи просто докопался до Л., потому что испытывал личную неприязнь к Л. на почве расизма, и вообще выглядит полным дурачком, а не взрослым адекватным разработчиком. В этой истории автор выглядит антигероем, если честно.
В команде разработки завёлся разработчик, который халтурит, и ты ничего не можешь с этим поделать. Если у вас никогда не было такого опыта, я вам завидую.
Вас насильно держат на работе что-ли? Ну не сошлись с кем-то — уволились и все. Тоже мне проблема.
В команде разработки завёлся разработчик, который халтурит, и ты ничего не можешь с этим поделать. Если у вас никогда не было такого опыта, я вам завидую.
Вас насильно держат на работе что-ли? Ну не сошлись с кем-то — уволились и все. Тоже мне проблема.
Увольняться только потому что кто то другой халтурит?
Кто то другой.
Серьезно, увольняться нужно из-за этого?
Это же не 3 метровый амбал бьет вас по голове табуреткой каждый день, а вы сделать ничего не можете. Он просто халтурит.
Строго говоря, это вообще не ваша проблема, а проблема фирмы, она меньше получает прибыли.
Увольняться только потому что кто то другой халтурит?
Если человека это так беспокоит, что он создал отдельную тему — то почему бы и нет? Или вы считаете, что нужно терпеть? Тут, как говорится, каждый сам выбирает, как ему жить.
Увольняться только потому что кто то другой халтурит?
Если человека это так беспокоит, что он создал отдельную тему — то почему бы и нет? Или вы считаете, что нужно терпеть? Тут, как говорится, каждый сам выбирает, как ему жить.
Я считаю что что то не так с автором статьи.
Он мелкие придирки изложил подробно и развернуто.
В другом месте у него будет то же самое.
Проблема в его собственной голове. Не в других.
«Я пишу новый метод API», например.
Каково работать вместе с очень ужасным разработчиком