Каково работать вместе с очень ужасным разработчиком

Автор оригинала: Chris Fox
  • Перевод


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

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

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

Внешние факторы


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

Он обладал механистическими привычками. Его реакция на любую смену темы была всегда одинаковой. Настала его очередь говорить? «Давайте я покажу свой экран». Появилось сообщение об ошибке? Получайте полноэкранный скриншот в BMP с огромным прямоугольником, внутри которого самого сообщения почти не видно. Нужно объяснить ключевое слово? Ещё один скриншот. Спасибо, Л., мы ведь не знали, как пишется «foreign key».

Я уже начал бояться созвонов, потому что его пронзительный громкий голос вызывал у меня головную боль. Все остальные члены команды освоили английский в достаточной для понимания степени, а Л. смещал ударения в словах («Chrome conSOLE») и это напомнило мне, почему так много компаний, выведших техподдержку на аутсорс в его стране, теперь переносили её в Филиппины.

Примечание: многие люди в комментариях начали называть меня ксенофобом за упоминание «акцента» Л. Наверно, немногие из вас встречались с реальной ксенофобией, потому что это явно не она.

Произношение Л. было таким же, как его работа: едва приемлемым, но не более того. Он был очень громким и его голос напоминал работу камнедробилки. Я был единственным англоязычным в группе разработки; всем остальным удавалось сохранять умеренную громкость речи и произносить слова так, чтобы их понимание не было пыткой.

Это никак не связано с акцентом. Я привык к иностранным акцентам. Это просто ещё одно проявление его посредственности.

Он не реагировал на то, что ему говорили и вносил изменения в поведение интерфейсов и API, не сообщая об этом никому. Так как у нас не было ревизий кода (code review), которые я упорно стремился внедрить, мы обнаруживали эти беспричинные изменения, только когда что-то ломалось.

Хуже всего было то, что у Л., похоже, каждые несколько минут происходила когнитивная перезагрузка. В той компании ветки Git были настроены совершенно неправильно — две master-ветки для одного репозитория, одна для фронтэнда, другая для бекэнда. Мой код криптографии относился к master-ветке фронтэнда. Мы говорили о ветках с упоминанием их названий примерно десять минут, и было совершенно понятно, что я выполняю мою работу во «frontend-crypto», которую мы упоминали много раз.

Внезапно он спросил меня, совершенно не к месту: «Крис, а в какой ветке ты работаешь?»

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

Плохой код


Обычно я работаю с семейством языков C и в веб-разработке пишу на C#. Мне пришлось выучить JavaScript, Python и Django. В результате теперь я почти исключительно пишу на JavaScript и работаю во фронтэнде. Обычно я бекэнд-разработчик; в том проекте всю работу по бекэнду выполнял Л.

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

Я пишу конечную точку


Мне нужен был новый API, который бы возвращал две или больше строк для получателей, присутствовавших или отсутствовавших в базе данных. Я не знаю Django достаточно хорошо, чтобы сделать это идеально, не понимаю, где заканчивается Python и начинается Django (мне сильно не нравится Django, в нём нет целостности и идиоматичности), но написал всю логику и коды состояний.

Допустим, я прошу этот API поискать ключи шифрования десяти людей. Вот найденное количество и коды состояний HTTP на моём плохом Django:

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

Если ответ содержит меньше строк, чем запрошенное количество, то я возвращал массив их идентификаторов «not-found».

Я обратился к Л., чтобы он исправил мой синтаксис Django, но не переписывал логику, и вот что он сделал:

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

То есть даже если не возвращалась ни единая строка, он называл это полным успехом и он удалил мой массив не найденных строк, поэтому клиенту пришлось бы перечислять возвращаемые данные, сравнивать с запросом и определять, какие из них не были возвращаены. А ошибка сервера возвращала 400, Bad Request, что совершенно неверно.

Этот человек должен был оказаться специалистом по бекэнду. Я ожидал, что он знает эти коды; я не знаю их все, но знаю с десяток наиболее распространённых. И даже имея на руках всю логику и требуемые коды состояний, он всё это выбросил и сделал «по-своему».

Ради справедливости надо сказать, что существует множество подходов к тому, как обрабатывать промежуточные уровни успешного выполнения действий API. Я почти никогда не видел никаких кодов состояний 2XX, кроме 200; 200 и 500 — это единственные коды, которые возвращает большинство разработчиков. Большинство разработчиков знает только три или четыре кода состояний. Л. знал два и один из них был неправильным.

Можно было бы благородно допустить что у Л. есть собственный подход, отличающийся от моего; на мой взгляд, если кодов больше, чем четыре, значит, на то есть причина, и поэтому я их использую. Однако уже проработав с ним несколько месяцев, я был уверен, что он просто скопипастил во все строки одну и ту же, вероятно, взятую с StackOverflow. Он сохранил мою логику фильтрации для всех заданных мной случаев (0, 1–9, 10), но вставил для всех них одинаковую строку.

Как бы то ни было, API — это транзакция, и если он изменил его поведение, то обязан был сообщить остальным о своих изменениях, потому что мы ожидали более подробных кодов состояний. Но он не только этого не сделал, но и никогда не отвечал мне, когда я его об этом спрашивал. Это непохоже на командную работу. Именно так мы всегда с ним и работали. Поскольку у проекта не было QA, то вероятнее всего, первыми дыры в логике увидят клиенты.

Реакция руководства


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

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

И этому человеку платили.

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

Я даже не старался больше поговорить с Л. Какой смысл? Он продолжал выполнять свой минимально допустимый уровень халтуры и в рамках его рабочей этики это было совершенно нормально. В предыдущих обсуждениях структуры проекта он не внёс ничего. Я мог бы заняться его менторством, но за несколько месяцев работы с ним уже понял, что он бы игнорировал меня и продолжал работать привычным ему способом: халтурным, кустарным и бессвязным.

Менеджеры, не знающие кода


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

Вероятно, они восприняли мой отчёт как «трения» между мной и Л.; я нормально общался со всеми и у меня получалось скрывать своё недовольство Л., его постоянным загадочным забыванием контекста и ужасным кодом. Однако на этом моя часть работы была практически завершена и ситуация никак на меня не повлияла.

Вот что происходит, когда считаешь разработку ПО общественной деятельностью. Это совершенно точно не похоже на проектирование.

Но если бы я был руководителем, Л. уже бы искал другую работу.

Этика работы в разработке ПО — это спектр, в котором существует два полюса:

  1. Делать всё максимально идеально, и к чёрту все дедлайны
  2. Выполнять минимально возможный объём и сделать своим единственным приоритетом выполнение списка задач. Устранять слабые места написанием юнит-тестов (которых мы не писали).

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



На правах рекламы


У вас могут быть не лучшие коллеги, но за надёжные серверы вам не нужно волноваться. Наша компания предлагает серверы с Linux или Windows. Не экономим на железе — только современное оборудование и одни из лучших дата-центров в России и ЕС. Поспешите проверить!

VDSina.ru
Серверы в Москве и Амстердаме

Комментарии 66

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


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

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

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

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

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

            +10

            Я бы сказал что согласно 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 меня тоже смущает

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

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

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

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

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

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

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

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

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


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

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

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

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


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


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

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

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

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

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

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

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

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

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

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

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


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

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

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

                        +1

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


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


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

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

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

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

                            0

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

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

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

                                +4

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

                                  0

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

                                    +1

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

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

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

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

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


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

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

                                                  +1

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

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

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

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

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

                                                      0

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


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

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


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

                                                        0

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


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

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

                                                          0

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

                                                        +1

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


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

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

                                                          0

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

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

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


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


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

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

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

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

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


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


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

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

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

                                                              Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                              Самое читаемое