Ты добавил всего две строчки. Почему на это ушло два дня?

Автор оригинала: Matt Lacey
  • Перевод
На первый взгляд вопрос кажется разумным, но он делает некоторые ужасные предположения:

  • строки кода = усилие
  • строки кода = значение
  • все строки кода равны

Ничто из этого не является истинным.

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

  • Потому что проблема была расплывчатым описанием того, как её воспроизвести. Мне потребовалось несколько часов, чтобы надёжно её воспроизвести. Некоторые разработчики немедленно бы обратились к человеку, сообщившему о проблеме, и потребовали бы больше информации, прежде чем проводить расследование. Я стараюсь получить как можно больше из той информации, которая есть в наличии. Знаю, что некоторым разработчикам не нравится исправлять ошибки, и поэтому они делают всё возможное, чтобы избавиться от них. Утверждение, что информации недостаточно, — отличный способ выглядеть так, будто вы пытаетесь помочь, но ничего не делать. Знаю, что сообщать об ошибках может быть трудно, и я благодарен всем, кто это делает. Я хочу выразить признательность за сообщения об ошибках, пытаясь извлечь как можно больше пользы из предоставленной информации, прежде чем просить подробности.
  • Потому что проблема была связана с функциональностью, с которой я не знаком. Эту конкретную функцию я редко использую и никогда не разбирался в деталях. Это значит, что мне потребовалось больше времени, чтобы понять, как её использовать и разобраться в нюансах, как она взаимодействует с программным обеспечением.
  • Потому что я потратил время, чтобы исследовать реальную причину проблемы, а не просто смотреть на симптомы. Если какой-то код выдаёт ошибку, вы можете просто обернуть его в оператор try-catch и подавить ошибку. Нет ошибки, нет проблем, правильно? Извините, для меня сделать проблему невидимой — это не то же самое, что исправить ее. «Проглатывание» ошибки может легко привести к неожиданным побочным эффектам. Я не хочу иметь с ними дело в будущем.
  • Потому что я исследовал, существуют ли другие способы воспроизведения проблемы, а не только описанные этапы. Определённые шаги для воспроизведения могут показать проблему в одном месте, когда на самом деле она может быть более глубоко укоренившейся. Поиск точной причины проблемы и рассмотрение всех способов её получения даёт ценную информацию. Очень полезно рассмотреть, как на самом деле используется код и где могут быть другие места с возможными (другими?) проблемами, или это может показать несоответствия в коде, которые означают, что ошибка вызвана (или обработана) в одном пути кода, но не в другом.
  • Потому что я потратил время, чтобы проверить, есть ли другие части кода, которые могут быть затронуты этой проблемой. Если появилась одна ошибка, то такая же могла быть допущена и в других местах кодовой базы. Сейчас самое время это проверить.
  • Потому что когда я нашёл причину проблемы, я искал самый простой способ её устранения с минимальным риском побочных эффектов. Я не стремлюсь к скорости. Я хочу исправить ситуацию так, чтобы устранить путаницу или другие проблемы в будущем.
  • Потому что я тщательно протестировал это изменение и убедился, что оно решает проблему для всех различных путей кода, которые были затронуты. Я не хочу полагаться на кого-то другого, чтобы проверить, что я сделал правильно. И не хочу, чтобы ошибка была найдена в будущем, и мне придется вернуться к этому коду, когда я мысленно двинусь дальше. Переключение контекста дорого и неприятно. Наличие специального тестировщика, который должен снова посмотреть на «то же самое» изменение, — то, чего я хочу избежать, когда это возможно.

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

Что может быть хуже, чем исправить ошибку? Необходимость исправлять одну и ту же ошибку неоднократно.

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

См. также:

Похожие публикации

AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Подробнее
Реклама

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

    +19
    Потому что проблема была расплывчатым описанием того, как её воспроизвести

    Как по мне, так объяснение этого пункта сомнительно. Вместо того, чтобы пойти к авторам бага "не работает сайт", пользуясь извлеченной из этого информацией "ну какой-то сайт где-то точно как-то не работает", провел полное регресс-тестирование всех проектов в компании. Ну-ну.

      +1

      Какую информацию вы ожидаете узнать у юзера? У подавляющего большинства внешние условия одинаковые, так как по разрабатывалось под эти условия.

        +6

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

          +8
          «просто поговорить» — эффективнее игр в детектива


          «просто поговорить» обычно означает написать отписку и отправку в висюки с 'Waiting For Response'.
            +7
            Это уже вопрос бюрократии в конкретном месте.
            Если цель написать отписку — будет написана отписка. Если цель: уточнить детали — будут уточнены детали.
            Игра в детектива всё равно сомнительна.
        +12

        Нормальное обьяснение. Не впадая в крайности типа полного регрес тестирования, очевидно. Я сам делаю именно так. И в огромном количестве случаев — таки оказывается что напрягшись на 5-10 минут — я нахожу о чем речь. И сразу же решаю проблему вместо пинг-понга с автором в течении нескольких дней. С месяц назад я вот так слегка поленился подумать и затянул задачку на 2 недели просто чтоб потом найти что я не проверил один из вариантов. И то, автор заметил этот момент когда я написал километровую простыню с описанием всех своих действий.
        Так что — "если до вас не дошло письмо — перечитайте его еще раз". Иначе — это просто лень, отмазка, нежелание углубляться в проблему и искать ее решение.

          –4
          Слишком общее утверждение.
          Иногда написанного в тржкере достаточно, иногда — нет.
          Пинг-понга легко избежать, если просто договорится об обсуждение в реалтайме, когда автор бага будет свободен и сразу на обсуждении уточнить всё что может понадобится.
            +1
            Из моей практики — написанного в трекере хватает в большинстве случаев. Так же как и написанного клиентом. А уж это, с точки зрения программиста, часто совершенно не структурированный поток сознания или паника в виде «сайт не работает!!!1111» хотя там всего лишь цвет надписи отличается на пол тона от того что в дизайне.

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

            Конечно — не всегда этого хватает. Я вот выше описал недавний случай когда и говорили с автором, и в трекере писали, и скриншотики посылали друг другу. А все равно еле разобрались. Да и то. В ретроспективе стало понятно что я всего лишь не подумал об одной из функциональностей и не перепроверил ее.
              +1
              В компании где работаю сейчас используется простой принцип:
              Если нет необходимости QA пишет всю суть бага в заголовке, а в описании пусто.
              Логика простая:
              -Незачем тратить время на написание деталей, т.к. скорее всего программист поймет о чем речь и без описания.
              -Если программист не поймет без описания — спросит.

              Как видите пункта про «программист проведет исследование и сам разберется» здесь нет вообще.
                0
                Опишет ли ваш QA на что еще надо обратить внимание или там будет только набор шагов для воспроизведения и описание как должно быть? Как часто вы возвращаетесь за уточнениями (к вам возвращаются)? Сколь часто возвращаясь с вопросом — оказывалось что вам достаточно было в дополнение к прочтению оглавления и описания — таки пойти и жмякнуть кнопочку о которой речь в задании (утрирую, конечно… Хотя нет, не утрирую. Видел таких кадров. Да и сам иногда подтупливал)? Что если вы повторяете, вроде, все те же шаги, а оно не воспроизводится? Что происходит если у вас не воспроизводится, а у вашего QA — воспроизводится (пожалуй, это можно выделить как главный вопрос)?
                  0
                  Опишет ли ваш QA на что еще надо обратить внимание или там будет только набор шагов для воспроизведения и описание как должно быть?

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

                  Как часто вы возвращаетесь за уточнениями (к вам возвращаются)?

                  Редко. Именно поэтому и устоялся такой подход. Если бы возвращались часто — эффективнее было бы сразу писать уточнения.

                  Сколь часто возвращаясь с вопросом — оказывалось что вам достаточно было в дополнение к прочтению оглавления и описания — таки пойти и жмякнуть кнопочку о которой речь в задании

                  Ситуация из разряда «затупил, не увидел очевидного». Бывает, но редко.

                  Что если вы повторяете, вроде, все те же шаги, а оно не воспроизводится? Что происходит если у вас не воспроизводится, а у вашего QA — воспроизводится

                  Много логов, удаленная отладка.
                    0
                    То есть. У вас куча простых задач, не вызывающих ни у кого вопросов. Но эти задачи нам и не интересны, ведь по ним никто не придет спрашивать почему такое простое вы делали так долго. И пояснять вам не придется ничего.
                    Когда же задача становится не простой (у QA воспроизводится, вас — нет) — вы так само начинаете исследовать. Логи, отладка, вот это вот все. Таким образом — вы все равно делаете то же что ТС и я — исследуете проблему. Просто перед этим вы еще потратитет время свое и QA на уточнения и, возможно, подвесите задачку на пару дней (ожидая пока автор освободится). Так почему просто не начать исследовать сразу? И я не предлагаю делать регресс тестирование всех живых и мертвых версий или ни в коем случае не связываться с автором.
                      +1
                      Потому что начать «сразу исследовать» означает проигноривать знание, которое и так уже есть.
                      Исследование — большая часть работы программиста.
                      Речь идет о том, что игнорировать знание которое уже есть у QA — идиотизм.
                        +1
                        Часто ли эти знания реально есть? Мне просто интересно. Бо с моей практики — проще мозгами пошевелить чем выяснить у того кто нашел баг то что мне как-то может помочь.

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

                        У меня зачастую прямое общение с клиентом. А от них ожидать нужных мне подробностей — та еще идея.
                  0
                  Тут есть риск, что баг отложат на пару недель как «не самый критический», и QA сам забудет что это было.
              +6
              Есть такая штука… Когда человек глубоко погружен в контекст какой-то проблемы, то ему кажется то, что и все окружающие так-же понимают т оо чем он говорит. Отсюда и получаются часто описания ошибок от тестировщиков, глядя на которые вот просто тупо не понимаешь о чем там речь идет вообще. При этом автору кажется что он максимально подробно и понятно все расписал и что там вообще может быть неясного?
              Вот отсюда и появляются эти долгие часы на исправления, ведь помимо того что надо написать эти строки — нужно еще и в контекст вникнуть и описание проблемы понять.
                0
                Ну, это да. Сам на такое не раз наступал выдавая задания.

                Так же есть и противоположность. Задание связано с тем что было всего неделю назад, на проекте человек уже давненько и даже 10 строчками выше в чате есть вот прям как раз о том что ему не понятно. Да и голосом дополнительно обсудили. И нет. Золотая рыбка. Прочитать, тут же забыть и делать то что написано в последней строчке, не учитывая контекст, предыдущие уточнения и дополнения, логику и вообще.
                  +2
                  Как же я ненавижу «выше все обсудили». Выше порой десяток простыней, включая форварды писем с длинной перепиской, не целиком относящейся к теме.
                  Есть в обсуждении что-то полезное — сразу возьми и скопипасть в задачу. А еще лучше до обсуждения выпиши вопросы в тексте задачи (связанной задачи) и по мере обсуждения заполняй ответы.
                  (Актуально при передаче задачи/части задачи новому исполнителю. Иначе все то же самое, но сам себе злая буратина)
                    0
                    Как уже писали в соседнем топике, нужен «протокол», ну или «action points». Именно он и является результатом обсуждения, а не само оно по себе. И да, если его нет, то делают «по последней строчке», особенно те кто не обсуждал, а получил задание на реализацию, что тоже часто бывает.
                      0
                      Ну, лично я писал о том когда я вот буквально инструктирую, вот прям сейчас. Это не растянутый во времени процесс и не письмо с сотней форвардов. А вот здесь и сейчас пояснения данные в задаче.

                      Что касается того о чем вы говорите, то меня оно тоже подбешивает. Но исключительно потому что время кушает (ну, еще потому что приходится мозгами шевелить чтоб разобраться во всей той писанине). Но в то же время — считаю это необходимым злом. Просто потому что дает возможность глубже понять проблему, ее контекст. Плюс к этому — меньше шансов на испорченный телефон.
                +3
                Баг может зарепортить случайный пользователь, который просто проходил мимо вашего сайта и больше никогда на него вернётся. Предоставлять детальное описание проблемы он вам не обязан. И на одного такого пользователя, сообщившего о проблеме, приходится черт знает сколько пользователей, которые просто молча ушли.
                  0
                  Для этого существуют логи (можно выставить в DEBUG особенно если ошибка часто повторяется) и traceback если ошибка его вываливает.
                  +27
                  Ты работал целый день и всё, что ты сделал — удалил 18 строк???
                    +34
                    Не то что Вася, за день написал 1487 строк (и это в одном файле), даже вечером на 3 часа задержался, берите пример. Васе премию за усердную работу, а тебе пока предупреждение.
                      –9
                      Количество строк кода, написанных в конкретный день, и правда не показательно. Но смотреть на картину в долгосрочной перспективе — однозначно полезное упражнение. Если разработчик пишет по две строки кода в день в среднем в течение месяца — скорее всего он работает не эффективно. Как ни крути, основная задача разработчика — писать код. А всех противников такой метрики как ни послушаешь — сплошь гении, которые над каждой строкой работают как над вековым шедевром.
                        +14

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

                          +1
                          Когда дебажишь что-нибудь интересное, может быть что и за неделю двух строчек кода в итоге не напишешь, но нельзя сказать что время было потрачено не эффективно.
                          Особенно если хоть немного с железом связано
                            +8
                            Мне кажется, задача разработчика решать задачи с помощью кода… Ну, то есть, можно и километры кода писать, но если код не решает задач, то кому он нужен? Поиск решения — мыслительная работа, а код всего лишь реализация найденного решения.
                              +7
                              основная задача разработчика — писать код
                              Основная задача разработчика — решать проблему заказчика. И чем меньше кода при этом будет написано, тем лучше, в идеале хорошо бы обойтись вообще без кода, условно говоря задействовав готовый инструмент и не изобретать велосипед.

                              The Best Code is No Code At All
                                –1

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

                                  0
                                  Я правильно понимаю, что руководствуясь этим прекрасным правилом у вас получается решать поставленные задачи, создавая в среднем по две строки кода в день?

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

                                    Так лично вы сколько кода за последний год написали? Меньше 500 строк? Что разрабатывали при этом?

                                      0
                                      Откуда я знаю. Зайдите на гитхаб, посмотрите additions/deletions
                                      Явно больше 500 написал, но еще больше удалил.
                                      Разрабатывал разное, но больше фиксил существующее, или дорабатывал, a больше всего из этого времени я посто думал, и к клавиатуре вообще нe притрагивался.

                                      Парируйте, если можете.
                                        0

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

                                          +2
                                          По-моему у вас разговор глухого со слепым.
                                          1. Задача разработчика ПО, несомненно, не заключается в порождении кода.
                                          2. Более того — чем больше кода вы напишите, при прочих равных — тем хуже. Там и ошибки и куча других проблем.
                                          3. Тем не менее многие задачи без написания кода — не решаются. Вас потому и наняли, собственно, когда это неприятная особенность выяснилась.

                                          Так что да — код-таки приходится писать и, зачастую, куда больше 2 строк в день… просто потому что по другому — задачи не решаются…

                                          Но когда вы можете не писать код — не пишите. И если можете написать 2 строки вместо 200 — лучше написать 2 строки.
                                            0
                                            Но когда вы можете не писать код — не пишите. И если можете написать 2 строки вместо 200 — лучше написать 2 строки.

                                            Gdulinsky this ^
                                              +1

                                              Глупо спорить, что лучше решить задачу при помощи двух строк, а не двухста. Но на практике задач, которые решаются двумя строками кода — меньшинство. И на длинной дистанции это актуально для 99% разработчиков. И к человеку, который стабильно пишет по две строки кода в день — точно стоит присмотреться и понять, что происходит. Но так поступил бы я, потому что мне не все равно, что происходит на моих проектах. Я так понимаю, если бы кто-то из моих оппонентов в этой ветке у себя в команде столкнулся с разработчиком с таким значением метрики — просто порадовались бы за человека, даже не поинтересовавшись, почему так. Не может же быть, чтобы человек плохо работал. Там точно проработка архитектуры постоянная и жесткий дебаг.

                                                +1

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


                                                Если разраб делает по две строчки в день и закрывает ими (именно закрывает, а не фигачит отписку и отправляет в висяки) 20 задач — ну что ж, или задачи такие, или разраб такой.


                                                А вот к тому, у кого на один тикет масштаба "подвинуть кнопку на 10 пикселей вправо" рождается 20 новых классов по 850 значащих строк в каждом, стоит в самом деле присмотреться повнимательнее.

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

                                                  Что меряете, то и получаете.


                                                  Будет 100500 "декомпонованных" задач вида "добавить поле на форму" вместо одной "сделать форму".

                                                    0

                                                    А это уже одно из главных правил менеджмента: измеряемый сотрудник ни в коем случае не должен знать, какой метрикой его оценивают, иначе вся его деятельность направляется на максимизацию этой метрики ©

                                                      0
                                                      Мне больше нравится противоположное правило — сотрудник должен знать, какой метрикой его оценивают, чтобы мог направить всю деятельность на оптимизацию требуемого результата. Например, бегуну-олимпийцу полезно знать, что его оценивают временем на стометровке.
                                                        0

                                                        Ну да — это если метрика напрямую зависит от требуемого результата, а не как тут :-)

                                                          0
                                                          Отсюда вывод — надо искать метруку, которая напрямую связана с требуемым результатом, а ту которая не связана не стоит использовать даже если спрятать от сотрудников.
                                                          Но да, это может быть чуть сложнее :)
                                                      0
                                                      С чего вы взяли что детальная декомпозиция это плохо? Зачастую это совсем не так. И лучше, если там будет тысячи тасков, если это на самом деле позволит оптимизировать процесс.

                                                      От излишней декомпозиции можно защититься измеряя количество более верхнеуровеных тасков.
                                                        +2
                                                        С чего вы взяли что детальная декомпозиция это плохо?

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


                                                        И лучше, если там будет тысячи тасков, если это на самом деле позволит оптимизировать процесс.

                                                        Ну так не позволит же.


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

                                                        На каком уровне меряете, на том и будут заводить. Люди — они изворотливы: штрафуете за баги — заводят change request или задачи, поощряте за фичи — бьют фичи на (неспособные жить по отдельности!) части и делают фичи из тасков, и так далее.

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

                                                Так и утверждаю, все зависит от задач.
                                                  0

                                                  Просто пока ваша и моя практика говорят об обратном. А в теории может быть все что угодно, конечно.

                                                  0

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

                                                    +1

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

                                        +5
                                        Вы случаем не ПМ в сельской компании?
                                        Не могу представить что кто-то мало мальски имеющий отношение к реальной разработке будет такое утверждать.
                                          –3

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

                                            0
                                            Количество строк кода — да метрика, но к сожалению ничего не показывающая.
                                            И плевать legacy или чистый код.
                                            Чисто архитектурно задачи можно решать разным количеством кода, и вариант с большим количеством кода может быть лучше, может быть хуже, может быть таким же как вариант с меньшим количеством кода. Вопрос архитектуры, вопрос принятых допущений, и просто подходов.

                                            Если в вашей компании оценивают продуктивность по количествку строк кода — бегите оттуда. Если оценщик в вашей компании вы… У вас кривое представление о процессах происходящих в вашей компании.
                                              0

                                              Вариант с большим количеством строк кода может быть лучше, может быть хуже, но таким же, ИМХО быть не может. Просто потому, что кодовая база будет меньше.

                                                0
                                                Пусть код большего размера(минус условные 0.1 балла), но немного лучше(+0.1 балла).
                                                Получаем одинаковое качество кода в наших условных баллах.
                                                Если большой код может быть лучше маленького, мы в любом случае получаем теоретическую возможность того что большой код может быть равен маленькому.
                                                +1

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

                                                  0
                                                  Нет, ну если у вас несколько команд решают одни и теже задачи изо дня в день, то конечно. Но решать одни и теже задачи по условной верстке визиток — это и есть уровень сельского стартапа.
                                                    0
                                                    Ок, на том и порешим
                                                    0
                                                    Это да, команда которая, решая сходную задачу, пишет в 3 раза больше кода хороший кандидат на увольнение.
                                                      +1

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

                                                        0
                                                        Ок, на том и порешим
                                                  +1
                                                  В Вашей компании оценивают работу по количеству строк кода?
                                                  Copy + Paste для увеличения повторяемости кода — отличное решение для Вас! )
                                                  Существует множество эффективных методов увеличения количества строк.
                                                  Я знаком с человеком, который работал в конторе, где именно такие методики применялись для оценки работы инженеров и надо ли говорить о том, что за код они в итоге выпускали? )
                                                    0

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

                                                    0

                                                    Мы тут на в этом году один сервис переписывали, с 50к строк кода переписли на 5, покрыв 150% функционала и сократив время внедрения новых фичей в несколько раз, потому что архитектура новая куда гибче и проще.


                                                    Вопрос: по вашей метрике мы говнокодеры которые испортили продукт?

                                                      0

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


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


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

                                                        0

                                                        У меня бывали плохие разработчики (и целые команды) когда я был линейным разработчиком. Сейчас я работаю техлидом и просто не иду в те компании где команда мне кажется некомпетентной: я обычно выбираю небольшие компании до 100 человек, там обычно 1-2 команд разработчиков до 10 человек, с ними пообщавшись можно сделать все необходимые выводы

                                                  +2

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

                                                    0
                                                    Я скорей всего пишу и в самом деле больше двух строчек в день, но очень часто в результате моих pull-request'ов количество строчек только уменьшается — потому что написав 2, я удаляю 20. Так что боюсь ваша любимая метрика себя не оправдает.
                                                      +1

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

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

                                                    Есть embeded-разаботчики, и малое число строк кода (точнее малый объем занимаемой памяти и ресурсов) — может быть показателем хорошего решения задачи. Тоже самое можно сказать про некоторые SDK и библиотеки, где чем меньше строк — тем меньше (и вполне возможно производительнее) может выйти итоговое решение (мало кому нравится подключать npm-пакет размером в 3Мб...)

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

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

                                                      А почему не количество коммитов, или например количество удаленных строк кода, ну или в конце концов, количество закрытых тикетов? А что если я скопипастил здоровенный json файл на миллион строк в проект — это значит я молодец, раз столько «кода» прибавилось?

                                                      Имхо, если кто-то оценивает что-то по количеству нового кода — это идиотизм.
                                                        +1

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


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

                                                          0
                                                          В среднем пишу больше, но бывают периоды, когда попадается и такое:
                                                          1. Ревью, ревью и ревью.
                                                          2. Документация (чтение, написание)
                                                          3. Обсуждения (что, как и кому делать)
                                                          4. Оптимизация, да во время процесса может быть написано и удалено несколько тысяч строк кода, сделана куча бенчмарков, а потом может оказаться добавление одной строчки или указание что сделать
                                                          5. Вдумчивое чтение логов (стрельнула бага у клиента, понять причину, решить как её обойти в будущем, и стоит ли вообще обходить, может бага из-за того что он сам что-то не то сделал)
                                                          6. Настройка инфраструктуры/базы/билдов/деплоя
                                                            +1

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

                                                        0
                                                        Интересно, а как вы бы оценивали хирургов? В суммарной длине разрезов за месяц?
                                                          +1

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

                                                            +1
                                                            Линейки что-ли запретили? Как минимум внешние разрезы легко измерить.
                                                              +1
                                                              Очень просто — считать, сколько нити потратили.
                                                                0

                                                                Тогда будут швы зашивать более плотно расположенными стежками.

                                                                +1

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

                                                                  0
                                                                  Я просто про метрику говорил. Не про оценку эффективности. Количество строк кода среднее в день зависит от огромного числа факторов. Гораздо большего, между прочим, чем общая длина швов у хирурга.
                                                              0

                                                              Шутки шутками, а чем выше уровень разработчика, тем больше кода он удаляет из проекта (YDNIA). Т.е. если проект уже не в начальной фазе разработки, то прекрасным результатом работы будет то, что по факту выполнения задач удалённых строк окажется существенно больше, чем добавленных (при условии, что строки тестов в учёт не идут).

                                                                0
                                                                программист как правило, больше времени читает код — свой и чужой, нежели пишет.
                                                            –16
                                                            Потому что проблема была расплывчатым описанием того, как её воспроизвести. Мне потребовалось несколько часов, чтобы надёжно её воспроизвести. Некоторые разработчики немедленно бы обратились к человеку, сообщившему о проблеме, и потребовали бы больше информации, прежде чем проводить расследование


                                                            Вместо того что-бы попросить тестировщика рабочий час которого дешевле раза в 2 к тому же который уже нашел багу — мы сидим и занимаемся не своей работой, нормально так.

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


                                                            Опять 25, подозреваешь что есть 10 других способов повторить баг? Говоришь об этом тестировщику и он дополняет задачу.

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


                                                            Уже давно по ctrl+click в любой IDE показывает такие места мгновенно.
                                                            И тесты тоже никто не отменял.

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


                                                            Опять боязнь тестировщика, зачем его нанимали в компанию?

                                                            Люди любят заниматься чужой работой, только вот работодатель не любит когда программист на ставке в 40$ занимается работой цена которой 8$
                                                              +18

                                                              Хорошо, когда есть тестировщик.

                                                                +2
                                                                — Тестировщики не нужны
                                                                — Хорошо, когда они есть
                                                                — Хорошо
                                                                  0
                                                                  Не пойму, почему дискуссия ушла в обсуждение того, есть ли тестировщик?
                                                                  Изначально говорится, что нужно обратиться «к человеку, сообщившему о проблеме». А это не обязательно тестировщик.
                                                                  Имхо, это элемент вежливости со стороны автора запроса — написать подробно (в разумных пределах, принятых конкретно в этой организации), как получилась проблема. Как показывает опыт, часто разработчик даже и не додумается до такого способа :)
                                                                  +32

                                                                  А потом разработчики начинают отдавать фиксы даже не запуская проект после изменений. Зачем? Есть же тестировщик.
                                                                  Ну и что, что он отдаст обратно через минуту после запуска. Мое время дороже.

                                                                    –1
                                                                    везде можно зайти в крайности, но зачем об этом думать? Главное комментарий написать
                                                                      +7

                                                                      Пишу о том, с чем встречался.

                                                                        +1
                                                                        А я пишу о том, что вижу в статье.
                                                                        Человек закрывал задачу 2 дня, потому-что стеснялся попросить помощи и сделать все сам, а потом написал статью о том, как он героически эту проблему решил.

                                                                        Только бизнесу не нужно что-бы сотрудники сидели и сами решали проблемы, можно попросить помощи и за 2 дня решить 5 таких проблем, но уже вместе с тестировщиком, вместо того, что-бы тестировщик простаивал, а разработчик выполнял работу за двоих.

                                                                        Ваш случай конечно тоже возможен, тут главное поймать золотую середину.
                                                                          +17
                                                                          Входных данных не достаточно. Если человек убил 2 дня на то, чтобы найти решение, то возможно при вашем подходе баг бы пинали друг другу несколько отделов в течение полугода, так и не пофиксив, потому, что у всех остальных точно также недостаточно времени на по-хорошему погрузиться в контекст.
                                                                            –7
                                                                            Это надо в каком-то фейсбуке работать что-бы такое происходило.
                                                                            На моей работе это более просто происходит:
                                                                            1. Смотрю задачу
                                                                            2. Вижу что данных недостаточно
                                                                            3. пишу в комментариях @тестировщикнейм тут нехватает входных данных, распиши более подробно и запиши видео.
                                                                            4. Иду заниматься другой задачей
                                                                            5. Через 30минут-4часа задача дополняется всеми нужными данными.

                                                                            А если надо срочно — тогда просто списываемся/созваниваемся в чатике, на что уходит 5 минут.
                                                                              +8
                                                                              Это надо в каком-то фейсбуке работать что-бы такое происходило.

                                                                              Да нет, в обычной компании с бюрократией. Я своими глазами видел, как на запрос дополнительной информации не отвечали неделями.

                                                                                –1
                                                                                Я своими глазами видел, как на запрос дополнительной информации не отвечали неделями.


                                                                                Тогда мне остается только посочувствовать вам.
                                                                                  0

                                                                                  Ладно люди с другими моими сообщениями могут быть не согласны, но что тут вам не понравилось? Или стадный инстинкт в действии?

                                                                                    0
                                                                                    Прочитал ветку. Не соглашусь с несогласными. Человек высказал мнение о том, что каждый должен заниматься своим делом и ситуация с ответом/его отсутствием от тестировщика вызывает вопросы к компетентности в первую очередь тестировщика и качеству менеджмента. Разбираться в баге нужно, искать схожие проблемные места в кодовой базе тоже, но это не говорит о том, что не нужно требовать от тестировщика дополнительной информации по багу, который он описал недостаточно или в общих чертах. Уже поднималась тема контекста, тестер может быть уверен что все понятно и полно описано, потому что он этим вопросом последние Х часов занят, а разрабу, которому задача упадет — непонятно, потому что у него помимо этого бага дофига задач
                                                                                      0
                                                                                      Человек высказал мнение о том, что каждый должен заниматься своим делом и ситуация с ответом/его отсутствием от тестировщика вызывает вопросы к компетентности в первую очередь тестировщика и качеству менеджмента.

                                                                                      … и вы тоже считаете, что тестировщик вообще есть.

                                                                                        0
                                                                                        Я считаю он необходим. Также как бизнес-аналитик, тим-лид и остальные участники нормально выстроенного процесса разработки ПО. Если мы не о пет-проектах или стартапах в лице одного разраба говорим, конечно. Статья написана от лица разработчика. И даже если сам баг-репорт прилетел от конечного пользователя, я считаю что он должен был пройти через определенные бизнес-процессы, прежде чем упасть разработчику в виде задачи, а не в виде «сайт не работает» или «на айос съехала всплывашка»
                                                                                          +1

                                                                                          Я вот недавно репортил баг в один OS-продукт. Его поддерживает один человек.


                                                                                          Где там место для бизнес-аналитика, тестировщика, тим-лида и так далее?

                                                                                            0
                                                                                            Их там нет, но это не релевантно к статье, где сам заголовок говорит о тайминге, а в содержании упомянут тестировщик
                                                                                              0
                                                                                              заголовок говорит о тайминге

                                                                                              А вы никогда не видели вопросов к мейнтейнеру open source "почему так долго, там одна строчка изменений"?


                                                                                              в содержании упомянут тестировщик

                                                                                              Угу, в контексте "я предпочел бы избежать просить выделенного тестировщика смотреть на "то же самое" изменение". Это не значит, что тестировщик есть.


                                                                                              Впрочем, на самом деле, не суть. Если мы говорим о правильно выстроенных процессах разработки, то в них вопрос из заголовка бессмысленен. Так что и говорить особо не о чем.

                                                                                                +1
                                                                                                А вы никогда не видели вопросов к мейнтейнеру open source «почему так долго, там одна строчка изменений»?

                                                                                                Не часто, но видел. Считаю подобное в контексте OS неприличным. Если вижу баг и возможность его быстрого исправления, отправлю PR, а не создам тикет с упреками мейнтейнера в нерасторопности.
                                                                                                  0
                                                                                                  Не часто, но видел. Считаю подобное в контексте OS неприличным.

                                                                                                  Ну вот а я считаю такой вопрос неприличным от менеджера к разработчику.

                                                                                0
                                                                                Подождите, прошу прощение, но, если вы читаете задание, видите в нем недостаточно информативное ТЗ, то на какой хрен писать тестировщику? Почему программист должен вообще этим заниматься? Почему программист должен передавать что-то / уточнять у тестировщика, если зада не полная? Где Типлид / ПМ / Аналитик (нужное подчеркните, в зависимости от подхода работы компании)?
                                                                                  –1
                                                                                  Потому-что мы говорим не о тз, а о баге. А баги заводит тестировщик.
                                                                                    0
                                                                                    Еще большая ошибка, что баги заводит тестировщик. Вы с какого мира, вообще?
                                                                                    Есть проект, у него продукт, у продукта фича. Зарелизили фичу, фича крутится лавеха мутится. Спустя пол года жалоба в тех. поддержку, создается задача от ТП, передается в БА (бизнес анализ), корректируется аналитиком — это нормальный рабочий процесс. Так же, даже если идет речь о исправлении багов при разработке фичи — это все должно идти через аналитика, который выставляет приоритет тому или иному багу для исправления. Сколько вас там работает у вас на работе? 2-3-5 человек? Если да — тогда понятно, почему вы так пишите. У вас тестировщик — тот же БА, что на самом деле весьма уныло.
                                                                                      +1
                                                                                      Не вижу противоречий если тестировщик создает задачу с багом, а БА выставляет приоритеты.
                                                                                      А как по другому? Тестировщику в файлик писать, а БА в задачу переносить?

                                                                                      Так же и после ТП и БА задача передается сначала тестировщику, который воспроизводит баг на тестовой среде, дописывает доп информацию, записывает видео и потом уже разработчику, и в «моем» как вы выразились мире, это экономит вещи разработчикам и они потом по 2 дня не исследуют как воспроизвести такой баг повторно.
                                                                                        +3
                                                                                        В «вашем мире» все занимаю чужими обязанностями, а это в свою очередь очень напрягает и направляет к перегоранию (+ многие отказались бы от подобного, к примеру я).

                                                                                        Противоречия есть, еще и какие!
                                                                                        1. Аналитик работает с потупающими задачами, имеет возможность создавать новые задачи. Выставляет приоритет среди задач. Знает чем занимается программист и когда какую задачу ему подсунуть.

                                                                                        2. Тестировщик работает в рамках своей задачи, которую ему создали и поручили аналитики! Найденные баги — это результат его работы, который он описывает в своей задаче (в которой он работает).

                                                                                        3. Аналитик на то и аналитик, что бы анализировать проделанную работу как тестировщика, так и программиста. Он получает сведения от тестировщика, что найдены такие-то абстрактные баги. На основании этого создает задачи программисту, который в свою очередь занимается решением проблемы.

                                                                                        4. После решения проблемы, программист отписывается в задаче, что проблема решена и к примеру прикладывает свой MR или название ветки (или еще как-то в зависимости от устоев компании и рабочего цикла команды).

                                                                                        5. Аналитик так же дает приоритет по задачам и тестировщику, аналогично программисту. Создает задачу на тестировщика, что нужно протестить исправление программиста.

                                                                                        6. Тестировщик проверяет и отписывается о результате. НО! Если в процессе тестирования были выявлены баги, опять же, в зависимости от бизнес процесса, тестировщик может как в задачу к программисту баги указать, так и в своей. И в зависимости от действия, дальше задачей занимается либо аналитик (передавая новые уточнения программисту, а зависимости от его занятости и приоритетности задач) ставит новую задачу программисту на доработки по связанной старой задаче либо следит и устанавливает приоритеты на существующей задаче с доработками.

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

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

                                                                                        Программист знает свой код из модуля определенного продукта, не знает как работают другие модули и продукты.
                                                                                        Тестировщик тестирует код определенных модулей и продуктов. Больше программиста знает как в целом работает весь бизнес процесс.
                                                                                        Аналитик знает что где и как работает (образно) и знает что где более приоритетно и соответственно закрывает «чёрные» дыры в первую очередь.
                                                                                          0
                                                                                          Я опять же не вижу противоречий между ставить задачу и определять приоритет.
                                                                                          В чем будет проблема если тестировщик заведет задачу, а аналитик назначит приоритет и разработчика на эту задачу?

                                                                                          Тестировщик тестирует код определенных модулей и продуктов. Больше программиста знает как в целом работает весь бизнес процесс.


                                                                                          Вот именно, поэтому и есть смысл просить тестировщика подробности у бага у тестировщика, а не искать самому.

                                                                                          В «вашем мире» все занимаю чужими обязанностями, а это в свою очередь очень напрягает и направляет к перегоранию (+ многие отказались бы от подобного, к примеру я).

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

                                                                                            0
                                                                                            Я опять же не вижу противоречий между ставить задачу и определять приоритет.
                                                                                            В чем будет проблема если тестировщик заведет задачу, а аналитик назначит приоритет и разработчика на эту задачу?

                                                                                            Аналитик видя проблему может скомпоновать / скорректировать вместе эти несколько проблем, так как знает ситуацию более обширно, нежели тестировщик (который, в свою очередь, не обладает той же компетентностью как аналитик).
                                                                                              0

                                                                                              Так пусть компонирует, кто ему мешает? Джира умеет объединять задачи

                                                                                                0
                                                                                                Вы придерживаетесь принципов SOLID?
                                                                                                А почему программист не занимается задачами аналитика?
                                                                                                А почему ЗП тестировщика раза в 2-4 меньше ЗП программиста / аналитика?
                                                                                                А зачем нанимают аналитика / тиков и вообще зачем отдел БА нужен?

                                                                                                Мне кажется, вы не понимаете ничего в принципе разделения ответственности.
                                                                                                  0

                                                                                                  А к чему эти вопросы? Я разве говорил что аналитик не нужен?

                                                                                                    0
                                                                                                    Нет, вы говорите, что тестировщик может делать работу аналитика, что является на самом деле еще худшим решением.

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

                                                                                                      По поводу вопросов — это вообще смешно, приплели и SOLID и тестировщиков и программистов и аналитиков к месту хранения багов.

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


                                                                                                        Да с чего вы вообще сделали вывод, что тестировщик создает задачу? Он описывает результат работы определенный кейсов условий в рамках какой-то условной фичи, не более не менее.

                                                                                                        Он может и не знать, что результат, который он считает ошибочным — может быть на самом деле верным, так как он не знает как работает все целиком. Поэтому, аналитик, видя отчет от тестировщика уже и решает, заводить задачу или нет, если да — совмещать с некоторыми другими проблемами или нет, выставляет приоритет.

                                                                                                        А привел солид и прочее к тому, что, если вы не понимаете на примере DDD кто чем должен заниматься, не верю, что вы понимаете на уровне ООП что и как и за что должно заниматься и как это реализовывать.

                                                                                                        Но согласен, сытый голодного не поймет, так же, как слепой не прочитает указания глухого. Дальнейший спор бессмыслен, лишь читатели смогут для себя сделать выводы, и смогу выбрать сторону, кто прав или ошибся.
                                                                                                          0
                                                                                                          Обещал не отвечать, но не сдержался, теперь последний раз, честно.

                                                                                                          Он может и не знать, что результат, который он считает ошибочным — может быть на самом деле верным, так как он не знает как работает все целиком.

                                                                                                          Возможно в какой-то уж очень узко направленной сфере.

                                                                                                          Но давайте будем честны, 90% багов в большинстве случаев — это «Не загружается картинка», «Поплыла Верстка», «Не пришло уведомление» и так далее, в том же фейсбуке я не вижу таких узконаправленных вещей в которых тестировщик не сможет определить баг это или нет, так что он вполне может создавать задачи с багами.

                                                                                                          А привел солид и прочее к тому, что, если вы не понимаете на примере DDD кто чем должен заниматься, не верю, что вы понимаете на уровне ООП что и как и за что должно заниматься и как это реализовывать.


                                                                                                          А вы видимо аналитик, который решил, раз на меня заводит баги тестировщик — значит я не знаю SOLID или DDD и вообще быдло-кодер.

                                                                                                          И как вообще можно лепить все в кучу? SOLID без DDD невозможен? Или знания DDD не осилит тот, на кого может задачу тестировщик завести?

                                                                                                          что и как и за что должно заниматься и как это реализовывать.

                                                                                                          А вот тут вообще какой-то набор слов:
                                                                                                            –5
                                                                                                            Возможно в какой-то уж очень узко направленной сфере.

                                                                                                            Таких ситуаций может быть до 60%. Если банковская сфера (кредитование) является узко направленной, то, наверное, галера штамповки сайтов — так же тонка, как ваши знания…

                                                                                                            Но давайте будем честны, 90% багов в большинстве случаев — это «Не загружается картинка», «Поплыла Верстка», «Не пришло уведомление» и так далее, в том же фейсбуке я не вижу таких узконаправленных вещей в которых тестировщик не сможет определить баг это или нет, так что он вполне может создавать задачи с багами.

                                                                                                            Я все понял, вы — джуниор! Теперь все стало на свои места. Думать, что 90% багов — это картинки и верстка… вы наверное на водпрессе магазины штампуете?

                                                                                                            А вы видимо аналитик, который решил, раз на меня заводит баги тестировщик — значит я не знаю SOLID или DDD и вообще быдло-кодер.

                                                                                                            И как вообще можно лепить все в кучу? SOLID без DDD невозможен? Или знания DDD не осилит тот, на кого может задачу тестировщик завести?

                                                                                                            Я Senior Back-end разработчик, а вы Junior, это следует из того, что вы написали, что солид строиться на ддд)))
                                                                                                            SOLID — это принципы построения нормального кода, DDD в свою очередь — это набор правил (схемы) построения архитектуры, на которой вы потом сможете без знания предметной области продукта вести разработку. И строится DDD на основании принципов SOLID.

                                                                                                            А вот тут вообще какой-то набор слов:

                                                                                                            Согласен, написано сложно, возможно с ошибками, но, прошу простить (чукча программист, чукча не писатель), читайте целиком всю мысль, а не отдельно выбранные фрагменты.
                                                                                                            +1
                                                                                                            Он может и не знать, что результат, который он считает ошибочным — может быть на самом деле верным

                                                                                                            Это как вообще? У Вас программисты лепят фичи без спецификации, от ветра головы своея?


                                                                                                            1. При возникновении требования аналитик формализует его в виде спецификации.
                                                                                                            2. Программист в соответствии с этой спецификацией лепит фичу.
                                                                                                            3. Тестировщик проверяет, что творение программиста этой спецификации соответствует. Если видит несоответствие — заводит багу. Аналитик (да, Вы правы, именно он видит общую картину) для этой баги выставляет приоритет и определяет срочность (эта/следующая итерация, бэклог и т.д.)

                                                                                                            Аналитик не может без тестировщика завести багу, ну никак. Тестировщик без аналитика — может. Так зачем задействовать двоих там, где можно обойтись одним?

                                                                                          +1

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

                                                                                  +11
                                                                                  А я пишу о том, что вижу в статье.

                                                                                  Это вот ключевой момент. Не "написано в статье", а "вижу в статье". Там, на минуточку, даже не сказано, что это бизнес. И уж тем более не сказано, что человек стеснялся что-то сделать.

                                                                                    –3
                                                                                    А вам лишь бы исказить смысл.
                                                                                    Если человека спрашивают, на что там два дня потрачено — значит это бизнес.
                                                                                    Не важно, фейсбук или галера, все равно деньги там важны.

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

                                                                                    Простите, а что делал товарищ менеджер? Если ему эти 2 дня не горели, то какие вопросы?
                                                                                      +2
                                                                                      Так давайте будем кнопку неделю перекрашивать, менеджер ведь в спину не дышит — значит все ок.
                                                                              +6
                                                                              Чувствуется бюрократическая закалка, я бы под руководством такого зануды не стал бы работать. С доводами не соглашусь как минимум потому, что разработчик в отличии от тестировщика имеет куда больше шансов найти баг, особенно который воспроизводится нестабильно. Я очень сильно сомневаюсь что ваши тестировщики за 8 баксов умеют в отладчик, имеют доступ к разным стораджам и т.д. и вообще понимают, что происходит за сценой.
                                                                                +3
                                                                                А я и не менеджер, я разработчик и у нас в команде тестировщики описывают баги так, что-бы потом не приходилось делать все то, что описал автор статьи.

                                                                                А если баг воспроизводится нестабильно — тогда тестировщики даже закономерности такого поведения пытаются найти и описывают это, что опять же экономит кучу времени.
                                                                                0
                                                                                Сразу видно, что человек не работал на настоящих проектах, по крайней мере больше года.
                                                                                  +1
                                                                                  Опять боязнь тестировщика, зачем его нанимали в компанию?

                                                                                  Я поражен вашей уверенностью.

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

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

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

                                                                                  Понятно, что такие баги встречаются не каждый день, но все же встречаются. Не то, чтобы я подписался под каждым пунктом автора, но и так категорично к ним бы не относился.
                                                                                    –2
                                                                                    Я поражен тем, что вы не читали остальные части моего текста, про тесты и ide не зря же написано.

                                                                                    Но и будем честны, решение проблемы в 2 строчки может затянуться и на неделю работы, с этим никто не спорит, и основная проблема таких моментов —
                                                                                    это
                                                                                    «я хз что тут написано и как с этим разобраться, буду выдергивать разные куски этого лапшекода пока не пойму как оно работает»
                                                                                    но автор написал кучу выдуманных проблем, которыми он даже не должен заниматься.
                                                                                      +4
                                                                                      Я прочитал остальные части текста, однако не счел правильным их комментировать. По моему мнению, все вещи, которые вы описали выше блока, который я процитировал имеют место быть только в шаблоне компании, в которой каждый сотрудник находится в черном ящике и область его деятельности — получить задачу от предыдущего звена цепочки обработать и выплюнуть статус-код. Это прекрасный пример как должна функционировать крупная компания и то, что вы привыкли к этому хорошо, но к сожалению, не весь бизнес работает так, как вы думаете. Если бы мне хотелось, я бы раскрыл эту тему, но проще просто процитировать первый комментарий:
                                                                                      Хорошо, когда есть тестировщик.

                                                                                      Что касается вашего замечания по поводу тестов и ide, тут получается все еще более небрежно, в плане аргументации. IDE даст вам возможность проследить где битый код вызывается, однако данные, которые этот битый код обрабатывает могут пройти еще миллионы итераций кода, положиться в базу или отправиться на обработку в какой-то сторонний сервис или пройти через какую-нибудь BPM и грохнуть чей-нибудь процесс…

                                                                                      Что касается тестов… Задайте вопрос, что делать если тестов не будет? Как в таком случае поступает бизнес? Тратит 40$/ч на написание тестов под древнюю систему?
                                                                                        –1
                                                                                        Что касается тестов… Задайте вопрос, что делать если тестов не будет? Как в таком случае поступает бизнес? Тратит 40$/ч на написание тестов под древнюю систему?


                                                                                        Тогда разработчик фиксит баг, смотрит что проблема решена и если сомневается, что это исправление не повлияло на другие части приложения — просит тестировщика перепроверить другие части приложения к которым есть подозрение (если это занимает больше 5-10 минут конечно же, в противном случае это можно сделать и самому)
                                                                                          +3
                                                                                          просит тестировщика перепроверить другие части приложения

                                                                                          А вот мы и пришли к тому, что вы согласились с автором.
                                                                                          — Как найти эти части приложения?
                                                                                          — Провести анализ, что, собственно, и было описано в пункте, который вы так рьяно хотели спихнуть на тестировщика)
                                                                                            –2
                                                                                            Но этот анализ не занимает 2 дня, эти все вещи при «использовании тестировщика» и ide занимают от силы минут 20, остальное время — это ковыряние в коде, но если бы автор так и написал тогда и не было бы нужды в подобной статье.
                                                                                              +3
                                                                                              эти все вещи при «использовании тестировщика» и ide занимают от силы минут 20

                                                                                              Это у вас просто система простая, извините.

                                                                                          +4
                                                                                          Всего два дня на две строчки? А что так мало? У меня был вполне реальный случай, когда изменение, в котором было пара строчек, вызвало а) баг в другой системе, ничем не связанной с изменяемой, через полтора месяца после релиза б) обсуждение между аналитиками двух систем (третьей и четвертой) на пару месяцев, как это исправить. Завершение истории я уже не застал, но совершенно не исключаю, что в итоге было еще одно изменение, возможно тоже на пару строчек, и даже еще через пару месяцев. А возможно и нет.

                                                                                          И да, задача проходила полный цикл анализа, была внятная постановка в JIRA, решение, и по итогам разборок было признано, что она была решена в полном соответствии с постановкой. Однакож некоторые нюансы аналитики не учли, потому что не знали о них.

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

                                                                                          В том числе — сроков решения задач на изменение двух строчек кода, потому что эффект изменения проявляется в совершенно другой системе (привет, IDE).
                                                                                            +2
                                                                                            В моём случае рекордом было изменение даже не на 2 строки, а на 2 символа, ловили его человек пять (по очереди и одновременно) в течении двух лет.

                                                                                            Поймали случайно, в процессе адаптации чужих тестов.

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

                                                                                            Что приводило к тому, что неверно заполнялась табличка сжатия, которую кто-то хитро сжал (да, я знаю, звучит иронично).

                                                                                            Срабатывало это всё, конечно, совсем в другом месте и вообще не в той программе — просто маленькие запросы проходили, а большие — нет (потому что получали неправильную контрольную сумму).
                                                                                              0
                                                                                              >Поймали случайно, в процессе адаптации чужих тестов.
                                                                                              Ну так прикиньте, тут же тоже поймали случайно, потому что
                                                                                              а) это была вообще другая система, о которой просто не думали вообще в процессе постановки задачи. Она вдруг стала получать некие сообщения, которые ей вовсе не предназначались, и о которых тоже никто не думал
                                                                                              б) эти сообщения падали в очередь ошибок, а не доходили до обработки.

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

                                                                                              В общем, все как в анекдоте — на пузе гайку открутил, а сзади что-то отвалилось.
                                                                                      +4
                                                                                      тестировщик
                                                                                      тестировщику
                                                                                      тестировщика

                                                                                      Я работал в одной американской компании, о которой вы гарантированно слышали, и в которой не было тестировщиков принципиально (по крайней мере, в нашем отделе), типа, мы сами себе QA.


                                                                                      Уже давно по ctrl+click в любой IDE показывает такие места мгновенно.

                                                                                      Когда-то давно, в прошлой жизни я много времени тратил на одно десктопное приложение на кутях. И в одной из новых версий кутей в класс QSortFilterProxyModel добавили метод setRecursiveFilteringEnabled() и изменили поведение этого класса так, что если этот метод не вызвать, то сортироваться и фильтроваться при некоторых условиях на логику фильтрации всё будет неправильно. Контрол-кликнуть куда именно мне нужно, чтобы найти все такие места?


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


                                                                                      f : (x : { v : Int | v >= 0 }) -> { v : Int | v > x }
                                                                                      g : (x : Int) -> { v : Int | v > x }
                                                                                      
                                                                                      fun : (x : { v : Int | v > 0 }) -> { v : Int | v >= x }
                                                                                      fun x = g (f x)

                                                                                      Здесь пока солвер не сможет рассуждать о поведении f x в соответствующем контексте. Куда именно мне контрол-кликнуть, чтобы понять, как это починить максимально общо?

                                                                                        0
                                                                                        Я работал в одной американской компании, о которой вы гарантированно слышали, и в которой не было тестировщиков принципиально (по крайней мере, в нашем отделе), типа, мы сами себе QA.
                                                                                        Я тож в такой работал. Зато там в проекте программистов было в 3 раза больше чем реально необходимо
                                                                                          +1
                                                                                          Сильный программист детектед

                                                                                          Уж сколько статей писано — пишите код понятный человеку, используйте информативные имена (не однобуквенные).
                                                                                          Чтобы начинающий программист взглянул и понял.

                                                                                          Такие случаи (болезнь компьютерного мышления) «чинятся» так:
                                                                                          Задача описывается хорошим литературным языком.
                                                                                          Пишется код первого общего теста (соблюдая TDD).
                                                                                          После обдумывания любого метода, перед написанием кода метода (соблюдая SRP), пишется юнит-тест.
                                                                                          Основной код должен иметь вид иерархии объектов/методов.

                                                                                          Держа себя в полезных рамках, отсекая мнимые степени свободы языка, инкапсулируя компьютерное мышление — уменьшаем вероятность непредвиденного поведения кода.

                                                                                          Улучшение осложняется успешным опытом программирования — если у программиста есть в портфолио рабочие проекты со спагетти-кодом — вероятность отказа от собственного стиля разработки уменьшается.

                                                                                          Шучу!
                                                                                          Хороший код, жаль не делает то, что хочется.
                                                                                            –2

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


                                                                                            Пишется код первого общего теста (соблюдая TDD).
                                                                                            После обдумывания любого метода, перед написанием кода метода (соблюдая SRP), пишется юнит-тест.

                                                                                            Это же разработка через юнит-тестирование, а мне их преимущество ну вот совсем неочевидно.


                                                                                            Основной код должен иметь вид иерархии объектов/методов.

                                                                                            А если объектов вообще нет?

                                                                                              0
                                                                                              Уж сколько статей писано — пишите код понятный человеку, используйте информативные имена (не однобуквенные).

                                                                                              А какие имена на ваш взгляд лучше тут использовать? Я вот не могу придумать какого-то хорошего имени которое бы что-то прояснило.


                                                                                              g : (someInputInt : Int) -> { someOutputIntGreaterThanInputInt : Int | someOutputIntGreaterThanInputInt > someInputInt }

                                                                                              Стало ли лучше? Если нет, то какие имена тогда стоит использовать?


                                                                                                0
                                                                                                0xd34df00d: если объектов вообще нет?

                                                                                                PsyHaSTe: не могу придумать какого-то хорошего имени

                                                                                                Чтобы два раза не вставать.
                                                                                                Коллега.КодРевью = Коллега.Понимание( _
                                                                                                Коллега.Парсер_Увиденного( _
                                                                                                Коллега.Глаза( _
                                                                                                Код( _
                                                                                                Программист.Кодирование( _
                                                                                                Программист.Обдумывание( _
                                                                                                Программист.ЗадачеПриёмник))))))

                                                                                                Вот современный код, а код из однобуквенных переменных из эпохи спагетти :-)
                                                                                                Спагетти = путь к выгоранию. Сам чуть не угорел.
                                                                                                  +2

                                                                                                  Плохая аналогия подобна котёнку с дверцей.


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

                                                                                                    0
                                                                                                    EnLarge: (numb: Int) -> { inCrease: Int | inCrease > numb }
                                                                                                      0

                                                                                                      А теперь вот конкретный контекст. Обратите внимание, что у f и g там даже тел нет, и совершенно неважно, что они делают.

                                                                                                        0
                                                                                                        О! Однобуквенный беспредел :-)
                                                                                                        Инкапсуляция придумана скрывать «как делать», а не скрывать что она вернёт.
                                                                                                        Компьютер Ваш код понимает — нам хочется его понять, минимизируя когнитивные усилия.
                                                                                                        Однобуквенной вакханалией вы усложняете понимание Вашего кода.
                                                                                                          0

                                                                                                          Я до сих пор не могу понять, как понимание кода улучшится от многих буков, если цель этого кода — проверить, что проверялка типов считает эти две функции совместимыми (или несовместимыми). Их семантика при этом неважна совершенно.

                                                                                                            0
                                                                                                            Вы же и запутались в своём однобуквенном коде
                                                                                                            Куда именно мне контрол-кликнуть, чтобы понять, как это починить максимально общо?

                                                                                                            Для устранения ошибок опытным путём нашли разные способы. Один из них я Вам предложил.
                                                                                                            И не от многих букв, а от имён, упрощающих понимание.
                                                                                                              0

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


                                                                                                              convertFunApp :: MonadConvert m => Term -> Term -> m AST
                                                                                                              convertFunApp fun arg = go fun [arg]
                                                                                                                where
                                                                                                                  go (TName _ varName) args = do
                                                                                                                    z3fun <- getFun varName
                                                                                                                    argASTs <- mapM convertTerm args
                                                                                                                    mkApp (getZ3Fun z3fun) argASTs
                                                                                                                  go (TApp _ fun' arg') args = go fun' (arg' : args)
                                                                                                                  go _ _ = error [i|Unsupported fun term type|]
                                                                                                                0
                                                                                                                Вижу однобуквенных стало гораздо меньше.
                                                                                                                Даже есть некоторая иллюзия понимания кода.
                                                                                                                Это же Haskell?
                                                                                                                Код Вас устраивает?
                                                                                                                  0

                                                                                                                  Их в том обрабатывающем коде и было гораздо меньше.


                                                                                                                  Да, Haskell. Нет, не устраивает (он всё ещё делает не совсем то и не совсем так, как мне хотелось бы, но это уже совсем другой вопрос).

                                                                                                                    –2
                                                                                                                    От голода есть таблетки и от ложного кода есть таблетки.
                                                                                                        0

                                                                                                        Как по мне стало только хуже ¯\_(°-°)_/¯

                                                                                                          –2
                                                                                                          Да, большинству фрукты полезны, но некоторым вредны.
                                                                                                            0

                                                                                                            Нет, объективно x : Int ничем не хуже numb : Int, я и так вижу из типов что это — число, мне не нужна венгерская нотация в именах. Далее, нейминг заборчиком — зачем? Что хотелось этим сказать. numb — почему не number тогда? Набрали 4 буквы, а на последних двух решили сэкономить? Какой-то очень странный трейдоф.


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

                                                                                                              0
                                                                                                              numb появился не вместо x, а вместо someOutputIntGreaterThanInputInt.

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

                                                                                                                +1
                                                                                                                numb появился не вместо x, а вместо someOutputIntGreaterThanInputInt.

                                                                                                                Ок, в чем смысл? Мне вон вместо someOutputIntGreaterThanInputInt больше нравится x


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

                                                                                                                Я вот не вижу чтобы numb : Int был контекстноудобным и как-то понижал когнитивную сложность.

                                                                                                                  +1

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

                                                                                                            0

                                                                                                            Угу.


                                                                                                            уВеличить: (онемевший: целое) -> { вСкладке: целое | вСкладке > онемевший }


                                                                                                            Выбрали, да. Стало хуже.


                                                                                                            А "код из однобуквенных переменных" — это, внезапно, из математики.

                                                                                                              –2
                                                                                                              В математике однобуквы уместны.
                                                                                                              А у нас тут две крайности не хотят прийти к балансу — однобуквенные против когнитивностранных имён.
                                                                                                                +1
                                                                                                                В математике однобуквы уместны.

                                                                                                                Ну вот и в примере выше они уместны.

                                                                                                                0
                                                                                                                А "код из однобуквенных переменных" — это, внезапно, из математики.

                                                                                                                Напомнило кусок статьи, которую я вчера пытался осилить и не осилил.


                                                                                                                вот

                                                                                                      0

                                                                                                      Я что-то не совсем понимаю, как сигнатура f тайпчекается. Если у x тип (число + доказательство некоторого утверждения относительно этого числа), то почему его можно использовать в сравнении с v?

                                                                                                        0

                                                                                                        Это магия refinement types — вы пишете эти refinement'ы, а потом о них не думаете и оперируете значениями как жителями базового типа.

                                                                                                          0

                                                                                                          То есть я правильно понимаю, что v после стрелочки и до неё — это разные значения с одинаковыми именами и у них не пересекаются пространства имён?

                                                                                                            0

                                                                                                            А, да. v — это локальное для фигурных скобочек имя, так что можно в уме каждую v внутри каждого блока переименовать в v<nextNumber> или типа того. Что, собственно, в какой-то момент и происходит со всеми этими freshRefVars.


                                                                                                            Но при этом вы можете использовать v с доказательством одного утверждения ρ₁ там, где ожидается v с доказательством другого утверждения ρ₂, если ρ₁ ⇒ ρ₂ — тавтология. То есть, если функция ожидает аргумент типа { v : Int | v >= 0 }, то ей можно передать аргумент типа { v : Int | v > 0 } (потому что v > 0 ⇒ v >= 0) или даже { v : Int | v = 0 }.


                                                                                                            Интересно, что это полноценное сабтайпинг-отношение с ковариантностью и контравариантностью, то есть, если у вас есть функция с типом


                                                                                                            { v : Int | v >= 0 } -> { v : Int | v >= 0 } -> { v : Int | v > 0 }

                                                                                                            то вы её можете передать туда, где ожидается функция с типом


                                                                                                            { v : Int | v > 0 } -> { v : Int | v > 0 } -> { v : Int | v >= 0 }
                                                                                                      0

                                                                                                      Ребята столько времени потратили на ожесточенные споры, что не заметили главного. Правы все, просто каждый описывает свою ситуацию на рабочем месте.У оратора с Гаррисоном-Трампом на аватарке видимо на работе худо-бедно все нормально организованно и каждый занимается своим делом + возможно учёт времени построже, потому и ругает автора за то, что

                                                                                                        0
                                                                                                        Один из немногих адекватных комментариев, Гаррисон-Трамп доволен, спасибо)
                                                                                                      +5
                                                                                                      def test_universe(computer_science):
                                                                                                         assert computer_science.np == computer_science.p

                                                                                                      (Я забыл закоммитить фикстуру computer_science, но это не сложно, правда же?)

                                                                                                        +6
                                                                                                        Ага, а скорость разработки проекта равна физической скорости набора всех его исходников.
                                                                                                          +2

                                                                                                          Настолько жизненно, что хочется плакать..

                                                                                                            +1
                                                                                                            Это конечно интересно, обсуждать абстрактные строчки кода, да еще и по однобокому описанию ситуации, только вот ситуация в реальном мире может быть кардинально разной, вот навскидку три варианта:

                                                                                                            1. Реально сложный проект с какой-нибудь математикой или нетривиальными алгоритмами (кодеки, рейтрейсинг, библиотеки машинного зрения или ML и т.п.)

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

                                                                                                            3. Разработчика назначили на поддержку проекта и он просто потратил много времени на то, чтобы понять что где происходит в чужом коде.

                                                                                                            Рассуждать про абстрактную измеримость или нет ценности абстрактных 2 строк кода это не лучшее занятие.
                                                                                                            • НЛО прилетело и опубликовало эту надпись здесь
                                                                                                                0
                                                                                                                Все-таки хорошо, когда твой начальник програмист — у нас таких вопросов не возникает )
                                                                                                                  +4
                                                                                                                  С начальником программистом бывает другая проблема. Часто у такого начальника все делается просто. И дальше идет фраза типа «да я такое делал на delphi/jquery/C++, там делать два часа». И хорошо, если потом он будет слушать объяснение чем ситуация из его героического прошлого отличается от текущей.
                                                                                                                    0
                                                                                                                    у меня начальник был в прошлом верстальщиком и никак не мог понять, как мы на iOS так медленно верстаем, когда он в 2004 году (когда последний раз верстал) делал по 2 интернет-магазина в день
                                                                                                                      0
                                                                                                                      Можно поинтересоваться, как вы вышли из ситуации?
                                                                                                                        0
                                                                                                                        а никак, и из этой ситуации и из подобной позже — только увольнение и поиск новой работы. При всем уважении к автору статьи, я считаю что моя жизнь слишком коротка чтобы спускать её на ветряные мельницы.

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


                                                                                                                  Связаться с создателем задачи и пообщаться по поводу воспроизведения ошибки — это обычная практика. И это не повод чтобы ничего не делать, а наоборот.

                                                                                                                  Я хочу понять, вы никогда по своим задачам не связываетесь с их создателем, чтобы уточнить их?
                                                                                                                    0
                                                                                                                    Ох, как об этом мечтаешь, когда прилетает баг от пользователя через саппорт, особенно когда у этого пользователя отдел ИБ состоит из одних параноиков. Тут либо копаешь по косвенным признакам в описании, перетряхивая всю цепочку обработки, либо по 1-6 месяцев договариваешься о получении исходных данных, играя в испорченный телефон через свой саппорт и их ИБ. Даже в самом идеальном случае быстрее бывает найти потенциальные проблемные участки логики, чем получить внятное пошаговое описание чего случилось и как они это получили.