Pull to refresh

Comments 225

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

The Best Code is No Code At All

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

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

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

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

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

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

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

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

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

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

Gdulinsky this ^

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

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


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


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

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

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


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

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

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

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

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

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

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


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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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


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


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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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


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

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


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

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


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

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


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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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


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

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

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


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

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


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

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

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

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

UFO just landed and posted this here
Потому-что мы говорим не о тз, а о баге. А баги заводит тестировщик.
UFO just landed and posted this here
Не вижу противоречий если тестировщик создает задачу с багом, а БА выставляет приоритеты.
А как по другому? Тестировщику в файлик писать, а БА в задачу переносить?

Так же и после ТП и БА задача передается сначала тестировщику, который воспроизводит баг на тестовой среде, дописывает доп информацию, записывает видео и потом уже разработчику, и в «моем» как вы выразились мире, это экономит вещи разработчикам и они потом по 2 дня не исследуют как воспроизвести такой баг повторно.
UFO just landed and posted this here
Я опять же не вижу противоречий между ставить задачу и определять приоритет.
В чем будет проблема если тестировщик заведет задачу, а аналитик назначит приоритет и разработчика на эту задачу?

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


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

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

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

UFO just landed and posted this here

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

UFO just landed and posted this here

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

UFO just landed and posted this here
В вашем случае тестировщик тоже создаёт задачи, просто делает это в другом месте, а потом передаёт аналитику, а тот в свою очередь компонирует их в другие задачи или копипастит без компоновки и назначает приоритеты, так что я по прежнему не понимаю претензий. Чем таким магическим задача в беклоге без приоритета и исполнителя отличается от текста в документе?

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

Дальше не буду отвечать, надоело
UFO just landed and posted this here
Обещал не отвечать, но не сдержался, теперь последний раз, честно.

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

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

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

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


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

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

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

А вот тут вообще какой-то набор слов:
UFO just landed and posted this here
Он может и не знать, что результат, который он считает ошибочным — может быть на самом деле верным

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

В общем, все как в анекдоте — на пузе гайку открутил, а сзади что-то отвалилось.
UFO just landed and posted this here
Я работал в одной американской компании, о которой вы гарантированно слышали, и в которой не было тестировщиков принципиально (по крайней мере, в нашем отделе), типа, мы сами себе QA.
Я тож в такой работал. Зато там в проекте программистов было в 3 раза больше чем реально необходимо
Сильный программист детектед

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

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

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

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

Шучу!
Хороший код, жаль не делает то, что хочется.
UFO just landed and posted this here
Уж сколько статей писано — пишите код понятный человеку, используйте информативные имена (не однобуквенные).

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


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

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


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

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

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

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

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


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

EnLarge: (numb: Int) -> { inCrease: Int | inCrease > numb }
UFO just landed and posted this here
О! Однобуквенный беспредел :-)
Инкапсуляция придумана скрывать «как делать», а не скрывать что она вернёт.
Компьютер Ваш код понимает — нам хочется его понять, минимизируя когнитивные усилия.
Однобуквенной вакханалией вы усложняете понимание Вашего кода.
UFO just landed and posted this here
Вы же и запутались в своём однобуквенном коде
Куда именно мне контрол-кликнуть, чтобы понять, как это починить максимально общо?

Для устранения ошибок опытным путём нашли разные способы. Один из них я Вам предложил.
И не от многих букв, а от имён, упрощающих понимание.
UFO just landed and posted this here
Вижу однобуквенных стало гораздо меньше.
Даже есть некоторая иллюзия понимания кода.
Это же Haskell?
Код Вас устраивает?
UFO just landed and posted this here
От голода есть таблетки и от ложного кода есть таблетки.
Да, большинству фрукты полезны, но некоторым вредны.

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


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

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

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

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

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


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

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

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

Угу.


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


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


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

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

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

UFO just landed and posted this here

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

UFO just landed and posted this here

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

UFO just landed and posted this here

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

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

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

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

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

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

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

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

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

Рассуждать про абстрактную измеримость или нет ценности абстрактных 2 строк кода это не лучшее занятие.
UFO just landed and posted this here
Все-таки хорошо, когда твой начальник програмист — у нас таких вопросов не возникает )
С начальником программистом бывает другая проблема. Часто у такого начальника все делается просто. И дальше идет фраза типа «да я такое делал на delphi/jquery/C++, там делать два часа». И хорошо, если потом он будет слушать объяснение чем ситуация из его героического прошлого отличается от текущей.
у меня начальник был в прошлом верстальщиком и никак не мог понять, как мы на iOS так медленно верстаем, когда он в 2004 году (когда последний раз верстал) делал по 2 интернет-магазина в день
UFO just landed and posted this here
а никак, и из этой ситуации и из подобной позже — только увольнение и поиск новой работы. При всем уважении к автору статьи, я считаю что моя жизнь слишком коротка чтобы спускать её на ветряные мельницы.

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


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

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

Или понять что дороже, 1) ждать когда разраб сам догодается что от него нужно 2) организовать коммуникацию с бизнес-пользователями.
Чаще всего дороже именно второй вариант, т.к. клиент не видит каких либо действий (вопросы с большими паузами за действия никто не воспринимает, почему-то) и просто отказывается от сервиса/софта. Первый вариант дороже только тогда, когда проблема незначительная, либо если пользователь сам заинтересован в ее фиксе (работает со старыми клиентами), но только в том случае, если пользователь лояльно настроен.
Это как клиент не видет никаких действий во втором варианте?
Вы обратились к первой линии за уточнением. Первая линия обратилась к клиенту. Клиент видит как минимум, что его проблемой занимаются.

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

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

То, о чем вы говорите, работает только со старыми подсевшими клиентами, которые плотно сели на иглу вашей инфраструктуры и хотят исправления бага… если не вмешивается их отдел ИБ и не начинает ставить палки в колеса. Если все нормально, то за 2-7 дней из клиента можно вытянуть описание как порвторить баг, а если какие либо проблемы, то эта волынка может тянуться и месяц и полгода. Я не шучу, с такими сроками я как раз по работе периодически сталкиваюсь. До кучи еще саппорт будет каждую неделю тебя спрашивать, а не зменилось ли там чего-нибудь… ну и что, что новых данных не появилось, у клиента руководство же интересуется.

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

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

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

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

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

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

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

Вот мы и пришли к 2 строчкам кода за 2 дня, ЧТД. Ибо за 2 дня далеко не от всех можно получить описание что случилось.
По вашему случаю я вижу, что у вас есть какой-то сырой функционал, который не совсем подходит клиентам. И нет недостатка сил разработки, то есть вы бы сделали, если бы точно знали как. Это показывает в чём у вас узкое место.

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

Это работает только в случае аутсорса. В случае торговли готовым софтом/сервисом, ситуация обратная: бог его знает что у этого клиента сломалось, у остальных пары сотен все работает нормально.
Пока что я вижу, что вы берёте на себя чужую ответственность.

Что вы, всего лишь устраиваю гонку, кто быстрее найдет проблему: саппорт или я.
“The definition of genius is taking the complex and making it simple.”
― Albert Einstein

Ну, сказать честно, нельзя сказать, что у Эйнштейна получилось сделать теории, которые легко понять, особенно если речь идёт об общей теории относительности. С другой стороны, ни у кого больше пока что не получилось это сделать лучше, так что может быть я зря придираюсь :).

А в чем прикол работать с задачами, в которых вместо четко поставленного требования (поправить баг, запилить фичу) какие-то мутные описания не пойми чего? В каждом разработчике живет Шерлок Холмс, но он точно не предназначен для разгадки тайны в постановке задачи.

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

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

И я знаю, что вы предложите — отправить тестировщика в командировку, чтобы он воспроизвёл проблему. Если пользователи приносят не миллионы долларов так не будет делать никто. А если будет, то уже можно спокойно позвать подавальщика платочков для правой руки, и протереть её перед тем как поставить на задаче штампик «Won't do».
Ну если Вы согласны выполнять сверху чужую работу за ту же ЗП — флаг Вам в руки. Тем не менее, даже в описанном Вами случае постановщик должен понимать, что от того как подробно он опишет проблему будет зависеть то как быстро ее решат. По более менее нормально описаной задаче часто можно понять место, где возникла ошибка даже без отправки тестера в Таджикистан (внезапно да?).

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

Разработка массового продукта очень отличается от «систем автоматизации» для банков и других штучных заказчиков. У продукта может быть не 100 пользователей в галстуках и наруч… костюмах, а хотя бы 10 миллионов. И никто из них ничего не должен и не хочет отвечать, а если ваш продукт что-то плохо делает… есть ещё несколько у конкурентов.

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

Компания несёт убытки, а вы упёрлись рогом, и уверены что она должна предоставить вам любую информацию по запросу. А может быть стоит самому мозг напрячь? Не надеясь на аналитиков, тестировщиков и саппорт? Работа программиста — думать, а уже во вторую очередь — писать код.
Ну то есть если какой-то пользователь заорет, что-то типо «У меня ничего не работает» и вы тут же всё бросите и начнете проводить полную регрессию всего приложения, чтобы понять что же конкретно не работает? Помоему лучше идти по пути наименьшего сопротивления, задав уточняющие вопросы, чем в общем-то и должна заниматься поддержка. Поддержка — это не ретранслятор криков пользователей. Особенно забавно это будет выглядеть, если в итоге окажется, что пользователь идиот и делает что-то не так, а система отрабатывает штатно, согласно его неадекватному поведению. Но вы уже просрали бабки компании за счет потраченного своего рабочего времени в пустую.

Не надо изобретать велосипед и пытаться выяснить то, что другие люди могут вам рассказать, достаточно просто спросить.
Ну то есть если какой-то пользователь заорет, что-то типо «У меня ничего не работает» и вы тут же всё бросите и начнете проводить полную регрессию всего приложения, чтобы понять что же конкретно не работает

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

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

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

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

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


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

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

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

у меня была история когда SQL Server не мог прочитать значение по XPATH из XML столбца если это значение начиналось с пробелов. Причем результат чтения ещё зависел от результирующего типа колонки: для nvarchat(1000) было совсем не то же что для nvarchar(MAX) даже для строки в 100 символов

Индусский метод программирования — чем больше строчек, тем больше платят
Случай из моей практики, сайт стал дико и безбожно тормозить после переезда с железного сервера в клауд. Вот прям некоторые страницы начали грузиться от 15 секунд до 1 минуты!!!

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

В итоге я удалил из кода РОВНО одну строчку (потом ненужные вещи тоже, но это уже потом), и проект стал летать.

Вместо 15-60 секунд ответ от сервера стал занимать 600мс!

Вопросов не возникало
что за строчка то такая была? sleep()?
Нет, это было наследие прошлого, т.е. легаси код.

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

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

Смешнее было то, что кто-то еще до меня это уже исправил, и вместо сотен или тысяч запросов на странице было несколько, где через MySQL запрос просто получают AVG для бизнеса. НО, эти товарищи забыли удалить СТАРЫЙ код. В итоге работало и то и то. Я удалил старый код.
Такие вопросы не возникают, если начальство знает о сложности баги/таска. А если это таск где реально нужно 2 строчки добавить и любой другой это сделает за 5мин-1час то вопрос уместен.
Если какой-то код выдаёт ошибку, вы можете просто отловить оператор и подавить ошибку.

Скажите, кто из вас отлавливает операторы?


Полез в оригинал, и там вот:


If some code is throwing an error, you could just wrap it in a try..catch statement and suppress the error.

Гугл, кстати хорошо справился:


Если какой-то код выдает ошибку, вы можете просто обернуть ее в оператор try..catch и устранить ошибку.

Странно всё же, что statement переводится как оператор. В англоязычной литературе это легко видно: statement это throw/return/catch..., а operator это ±*/...

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

одно дело когда происходит просто странный перевод, и другой когда происходит слияние терминов, как например: Flow/Thread/Stream.

Я как то раз три недели искал ошибку. Причем не я один ее искал. В итоге оказалось, что это специфика внутренней логики работы не нашей библиотеки. Которую проще было обойти со стороны фронтенда, а мы — бэк. Таким образом, за три недели я не написал вообще ни одной строчки, не считая килотонн логов.
UFO just landed and posted this here

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

Есть такой старый анекдот не помню уже когда впервые его услышал и точно не воспроизведу но смысл там такой — мастеру поручили починить двигатель, он 1 раз ударил молотком и двигатель заработал. За свою работу мастер попросил 1000 долларов, когда его спросили за что так много, он ответил 1 за удар 999 за знание куда ударить.
UFO just landed and posted this here
Потому что я исследовал, существуют ли другие способы воспроизведения проблемы, а не только описанные этапы

Если разработчик занимается R&D, а пишет только код это деньги на ветер. Следующему за ним придется повторять весь путь заново? Я бы предпочел, чтобы на выходе появился отчет о проделанном исследовании с анализом причин ошибки, обнаруженных зависимостях, подводных камнях, и обоснованием выбранного решения. Это поможет коллегам быстрее погружаться в данную функциональность. Кроме того, стоит добавить юнит тесты, если нет обоснованных причин этого не делать.

Я как—то дал оценку времени разработки модуля: «дней 7 код писать и дня 3 баги вычищать»; в ответ получил предложение всё сделать за 4 дня — сразу написать без багов: время на написание багов не потребуется и на их исправление. Реальная история

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

Директор — универсальный торговец. Отношения были хорошими. В комнате было ещё пару человек. Сначала мы зависли, потом рассмеялись до слёз, потом объяснили, как это работает))

Интересно, а что Вы говорили в ответ на эту фразу?

Я бы ответил: «Ну тогда 21 день»
UFO just landed and posted this here
Sign up to leave a comment.

Articles