Comments 225
Потому что проблема была расплывчатым описанием того, как её воспроизвести
Как по мне, так объяснение этого пункта сомнительно. Вместо того, чтобы пойти к авторам бага "не работает сайт", пользуясь извлеченной из этого информацией "ну какой-то сайт где-то точно как-то не работает", провел полное регресс-тестирование всех проектов в компании. Ну-ну.
Какую информацию вы ожидаете узнать у юзера? У подавляющего большинства внешние условия одинаковые, так как по разрабатывалось под эти условия.
В приведенном гипертрофированном примере — хотя бы доменное имя сайта. А вообще, хотя бы "что делал" — "что не так". Конечно бывают случаи, когда и по описанию "не работает сайт" сразу понятно, что и где лежит, но в общем случае "просто поговорить" — эффективнее игр в детектива.
Нормальное обьяснение. Не впадая в крайности типа полного регрес тестирования, очевидно. Я сам делаю именно так. И в огромном количестве случаев — таки оказывается что напрягшись на 5-10 минут — я нахожу о чем речь. И сразу же решаю проблему вместо пинг-понга с автором в течении нескольких дней. С месяц назад я вот так слегка поленился подумать и затянул задачку на 2 недели просто чтоб потом найти что я не проверил один из вариантов. И то, автор заметил этот момент когда я написал километровую простыню с описанием всех своих действий.
Так что — "если до вас не дошло письмо — перечитайте его еще раз". Иначе — это просто лень, отмазка, нежелание углубляться в проблему и искать ее решение.
Иногда написанного в тржкере достаточно, иногда — нет.
Пинг-понга легко избежать, если просто договорится об обсуждение в реалтайме, когда автор бага будет свободен и сразу на обсуждении уточнить всё что может понадобится.
А вот чтоб хватало — всего лишь надо самому немного напрячься да тыкнуть пару кнопок, припомнить контекст, подумать что именно могло бы привести к поведению описанному клиентом. Или просто покрутить в голове это самое описание чтоб понять
о чем именно говорит человек с той стороны. Просто я сам себя ловил на этом. Когда переписываешься, уточняешь, а потом «блин, да вот же оно — с самого начала написано было, разве что болдом не выделено!»
Конечно — не всегда этого хватает. Я вот выше описал недавний случай когда и говорили с автором, и в трекере писали, и скриншотики посылали друг другу. А все равно еле разобрались. Да и то. В ретроспективе стало понятно что я всего лишь не подумал об одной из функциональностей и не перепроверил ее.
Если нет необходимости QA пишет всю суть бага в заголовке, а в описании пусто.
Логика простая:
-Незачем тратить время на написание деталей, т.к. скорее всего программист поймет о чем речь и без описания.
-Если программист не поймет без описания — спросит.
Как видите пункта про «программист проведет исследование и сам разберется» здесь нет вообще.
Опишет ли ваш QA на что еще надо обратить внимание или там будет только набор шагов для воспроизведения и описание как должно быть?
Я же написал: норма — это просто краткое описание умещающееся в заголовок. Никакого набора шагов там быть не может.
Набор шагов описывают, если способ воспроизведения не очевиден и баг вылезает только в конкретных ситуациях.
Как часто вы возвращаетесь за уточнениями (к вам возвращаются)?
Редко. Именно поэтому и устоялся такой подход. Если бы возвращались часто — эффективнее было бы сразу писать уточнения.
Сколь часто возвращаясь с вопросом — оказывалось что вам достаточно было в дополнение к прочтению оглавления и описания — таки пойти и жмякнуть кнопочку о которой речь в задании
Ситуация из разряда «затупил, не увидел очевидного». Бывает, но редко.
Что если вы повторяете, вроде, все те же шаги, а оно не воспроизводится? Что происходит если у вас не воспроизводится, а у вашего QA — воспроизводится
Много логов, удаленная отладка.
Когда же задача становится не простой (у QA воспроизводится, вас — нет) — вы так само начинаете исследовать. Логи, отладка, вот это вот все. Таким образом — вы все равно делаете то же что ТС и я — исследуете проблему. Просто перед этим вы еще потратитет время свое и QA на уточнения и, возможно, подвесите задачку на пару дней (ожидая пока автор освободится). Так почему просто не начать исследовать сразу? И я не предлагаю делать регресс тестирование всех живых и мертвых версий или ни в коем случае не связываться с автором.
Исследование — большая часть работы программиста.
Речь идет о том, что игнорировать знание которое уже есть у QA — идиотизм.
Да и, похоже, у вас опыт несколько искривлен из-за наличия этого самого QA. А возможно вам вообще суперски повезло и QA достаточно технически подкован чтоб разговаривать с программистом на одном языке. В таких условиях, наверное, имеет смысл взять за привычку сначала попытаться выведать доп. инфу и автора. Правда, только пока это не затягивает решение самой задачи превращая работу в бюрократические отписки.
У меня зачастую прямое общение с клиентом. А от них ожидать нужных мне подробностей — та еще идея.
Вот отсюда и появляются эти долгие часы на исправления, ведь помимо того что надо написать эти строки — нужно еще и в контекст вникнуть и описание проблемы понять.
Так же есть и противоположность. Задание связано с тем что было всего неделю назад, на проекте человек уже давненько и даже 10 строчками выше в чате есть вот прям как раз о том что ему не понятно. Да и голосом дополнительно обсудили. И нет. Золотая рыбка. Прочитать, тут же забыть и делать то что написано в последней строчке, не учитывая контекст, предыдущие уточнения и дополнения, логику и вообще.
Есть в обсуждении что-то полезное — сразу возьми и скопипасть в задачу. А еще лучше до обсуждения выпиши вопросы в тексте задачи (связанной задачи) и по мере обсуждения заполняй ответы.
(Актуально при передаче задачи/части задачи новому исполнителю. Иначе все то же самое, но сам себе злая буратина)
Что касается того о чем вы говорите, то меня оно тоже подбешивает. Но исключительно потому что время кушает (ну, еще потому что приходится мозгами шевелить чтоб разобраться во всей той писанине). Но в то же время — считаю это необходимым злом. Просто потому что дает возможность глубже понять проблему, ее контекст. Плюс к этому — меньше шансов на испорченный телефон.
Может быть и по-другому. Один разработчик исследует и фиксит баги, а другой прикрывает их костылями.
Особенно если хоть немного с железом связано
основная задача разработчика — писать кодОсновная задача разработчика — решать проблему заказчика. И чем меньше кода при этом будет написано, тем лучше, в идеале хорошо бы обойтись вообще без кода, условно говоря задействовав готовый инструмент и не изобретать велосипед.
The Best Code is No Code At All
Я правильно понимаю, что руководствуясь этим прекрасным правилом у вас получается решать поставленные задачи, создавая в среднем по две строки кода в день? Если да, то поделитесь, пожалуйста, деталями — какие задачи, какие технологии используете. Очень интересно
Я правильно понимаю, что руководствуясь этим прекрасным правилом у вас получается решать поставленные задачи, создавая в среднем по две строки кода в день?
А то, вы же не уточнили что значит «решать поставленные задачи». Если пишешь большую новую фичу — то ожидаемо видеть больше кода. А если копаешься в архитектуре и правишь баги — там кода может вообще не быть (например в итоге оказалось что надо просто в базе значение поправить)
Так лично вы сколько кода за последний год написали? Меньше 500 строк? Что разрабатывали при этом?
Явно больше 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 или чистый код.
Чисто архитектурно задачи можно решать разным количеством кода, и вариант с большим количеством кода может быть лучше, может быть хуже, может быть таким же как вариант с меньшим количеством кода. Вопрос архитектуры, вопрос принятых допущений, и просто подходов.
Если в вашей компании оценивают продуктивность по количествку строк кода — бегите оттуда. Если оценщик в вашей компании вы… У вас кривое представление о процессах происходящих в вашей компании.
Вариант с большим количеством строк кода может быть лучше, может быть хуже, но таким же, ИМХО быть не может. Просто потому, что кодовая база будет меньше.
Сказать разработчику, что он плохо работает, потому что написал мало кода — это так не работает думаю ни в одной здравой организации. А вот глядя на две команды, работающие на схожей технологии и над схожими задачами, увидеть, что одни пишут в три раза больше кода чем другие — это точно вопрос в котором нужно разобраться и понять, почему так происходит. Подобные метрики — это индикаторы возможных проблем, которые позволяют своевременно углубиться и понять, есть ли проблема на самом деле.
Например, да. Или решает в три раза больше задач, если глянуть на другие метрики. Или пишет больше тестов и потом меньше тратит времени на регрессионное тестирование. Разные интересные отличия можно найти в подходах команд и основываясь на этом вырабатывать лучшие практики для конкретного продукта, компании или проекта. И если вы работаете не в формате «собрались на два месяца на проект, чтобы потом год не видеться», то такую работу по постоянному улучшению следует делать систематически. И чем больше цифр у вас будет при этом под рукой — тем больше шансов найти возможности для улучшения. Вы как-нибудь поинтересуйтесь, как в современном мире устроено управление, например, топовыми футбольными или баскетбольными командами. Удивитесь, какое количество информации автоматически собирается и оцифровывается по каждому игроку, как с этим работают разные тренеры.
Copy + Paste для увеличения повторяемости кода — отличное решение для Вас! )
Существует множество эффективных методов увеличения количества строк.
Я знаком с человеком, который работал в конторе, где именно такие методики применялись для оценки работы инженеров и надо ли говорить о том, что за код они в итоге выпускали? )
Нет, конечно. Я нигде подобного не писал. В целом — как только вы пытаетесь подогнать эффективность под какую-то метрику, люди очень быстро адаптируются, чтобы соответствовать вашим ожиданиям. Однако это не означает, что метрики не нужно анализировать — можно много полезного понять сравнивая между собой команды, людей, даже сравнивая в динамике одну и ту же метрику по команде.
Мы тут на в этом году один сервис переписывали, с 50к строк кода переписли на 5, покрыв 150% функционала и сократив время внедрения новых фичей в несколько раз, потому что архитектура новая куда гибче и проще.
Вопрос: по вашей метрике мы говнокодеры которые испортили продукт?
Я отвечу на ваш вопрос, хоть он и похож на риторический. Нет, я не оценил бы вас таким образом, если все написанное вами правда. Метрика — это всего лишь цифра, которую нужно на равне с другой информацией в последующем использовать для анализа ситуации.
Но и задам вам встречный вопрос: что из написанного мной заставило вас задать такой вопрос? Правда, очень хочу для себя прояснить, как можно было бы понятнее донести мысль, что «чем больше у вас объективных цифр, тем больше шансов разобраться в любой сложной проблеме», не вызвав такое количество странных вопросов.
Почему вам показалось, что увидев такой прекрасный результат вашей работы, я посчитал бы, что важнее количество строк кода? А ещё поделитесь, у вас по такой же схеме и предыдущий проект прошёл? И доводилось ли вам работать с людьми и командами, которые плохо делают свою работу, которые плохо разрабатывают или просто безответственно относятся к работе? Если приходилось, то очень интересно, почему вы игнорировали при этом, что некоторые разработчики вовсе не пишут код? Почему не считали нужным углубляться и разбираться, как так получается?
У меня бывали плохие разработчики (и целые команды) когда я был линейным разработчиком. Сейчас я работаю техлидом и просто не иду в те компании где команда мне кажется некомпетентной: я обычно выбираю небольшие компании до 100 человек, там обычно 1-2 команд разработчиков до 10 человек, с ними пообщавшись можно сделать все необходимые выводы
Вы привели массу прекрасных примеров крайних ситуаций, почему может оказаться, что конкретный разработчик пишет мало кода. Все может быть. Но любой контроль строится на сравнении реальных показателей не с крайними, а как раз со средними. Я уверен, что каждый из высказавшихся в среднем пишет больше чем две строчки кода в день, если вы разработчики, конечно.
Есть embeded-разаботчики, и малое число строк кода (точнее малый объем занимаемой памяти и ресурсов) — может быть показателем хорошего решения задачи. Тоже самое можно сказать про некоторые SDK и библиотеки, где чем меньше строк — тем меньше (и вполне возможно производительнее) может выйти итоговое решение (мало кому нравится подключать npm-пакет размером в 3Мб...)
Есть разные стадии бизнеса. В тех же стартапах часто куда более весомо быстро залатать костылями, чем сидеть несколько дней и делать «правильный» фикс на все случаи жизни… пока ресурсы и время бизнеса понемногу утекают на такое решение
Ну, т.е., я понимаю вашу мысль, но все же вы сильно узко описали проблему, да и даже для тех случаев где нужно много и обстоятельно кодить — это слегка подменяет реальную задачу. Все же реальная задача везде — это решать бизнес-потребности. А кодинг уже чисто инструмент, и то далеко не всегда
Количество строк кода, написанных в конкретный день
А почему не количество коммитов, или например количество удаленных строк кода, ну или в конце концов, количество закрытых тикетов? А что если я скопипастил здоровенный json файл на миллион строк в проект — это значит я молодец, раз столько «кода» прибавилось?
Имхо, если кто-то оценивает что-то по количеству нового кода — это идиотизм.
Я уже несколько раз написал, что это одна из метрик, которых на самом деле на много больше — и количество комитов, и количество закрытых задач, и количество найденных ошибок, и любые другие объективно рассчитываемые показатели — все это полезная информация, анализируя которую можно улучшать процессы разработки, диагностировать проблемы в этих процессах. Но вы почему-то приписываете мне желание оценить разработчика по количеству строк кода как по единственному показателю.
Ну и, к слову, пока что-то в этом треде не нашлось много авторов, которые писали бы по две строки в день в среднем. А очень бы хотелось узнать, чем такие люди занимаются.
1. Ревью, ревью и ревью.
2. Документация (чтение, написание)
3. Обсуждения (что, как и кому делать)
4. Оптимизация, да во время процесса может быть написано и удалено несколько тысяч строк кода, сделана куча бенчмарков, а потом может оказаться добавление одной строчки или указание что сделать
5. Вдумчивое чтение логов (стрельнула бага у клиента, понять причину, решить как её обойти в будущем, и стоит ли вообще обходить, может бага из-за того что он сам что-то не то сделал)
6. Настройка инфраструктуры/базы/билдов/деплоя
Вряд ли для хирургов это релевантная метрика. Тем более, не понятно как ее можно измерить. Но если бы ее можно было легко получить — не думаю что практикующие хирурги отказались бы от такой информации. И какое-то применение ей бы нашли. Хотя тут у хирургов, конечно, нужно спрашивать. А ещё лучше — у преподавателей, которые их готовят.
Кажется, прояснилась одна из причин, почему мы не можем найти со многими общий язык в этом обсуждении. Судя по фразе «как вы бы оценивали хирургов», вы ставите в один ряд метрики (это просто некие характеристики происходящего процесса) и показатели эффективности. Это все-таки разные вещи. На примере футбольной команды — показателем эффективности является количество выигранных матчей, титулов. При этом метрик существует огромное множество — точность передач, количество нарушений, количество забитых и пропущенных мячей и т.п. Стоит ли говорить о том, что метрики — это всего лишь инструмент, позволяющий, лучше понять, что происходит (в основном тренеру и игрокам). Но счёт на табло остается счетом на табло. В вашем примере с хирургами я и правда не знаю, будет ли полезной информация, которую вы предлагаете мерять. Но уж точно оценивать хирурга нужно по успешным операциям.
Шутки шутками, а чем выше уровень разработчика, тем больше кода он удаляет из проекта (YDNIA). Т.е. если проект уже не в начальной фазе разработки, то прекрасным результатом работы будет то, что по факту выполнения задач удалённых строк окажется существенно больше, чем добавленных (при условии, что строки тестов в учёт не идут).
Потому что проблема была расплывчатым описанием того, как её воспроизвести. Мне потребовалось несколько часов, чтобы надёжно её воспроизвести. Некоторые разработчики немедленно бы обратились к человеку, сообщившему о проблеме, и потребовали бы больше информации, прежде чем проводить расследование
Вместо того что-бы попросить тестировщика рабочий час которого дешевле раза в 2 к тому же который уже нашел багу — мы сидим и занимаемся не своей работой, нормально так.
Потому что я исследовал, существуют ли другие способы решения получения же проблемы, а не только описанные этапы, как её воспроизвести.
Опять 25, подозреваешь что есть 10 других способов повторить баг? Говоришь об этом тестировщику и он дополняет задачу.
Потому что я потратил время, чтобы проверить, есть ли другие части кода, которые могут быть затронуты этой проблемой.
Уже давно по ctrl+click в любой IDE показывает такие места мгновенно.
И тесты тоже никто не отменял.
Потому что я тщательно протестировал это изменение и убедился, что оно решает проблему для всех различных путей кода, которые были затронуты.
Опять боязнь тестировщика, зачем его нанимали в компанию?
Люди любят заниматься чужой работой, только вот работодатель не любит когда программист на ставке в 40$ занимается работой цена которой 8$
Хорошо, когда есть тестировщик.
— Хорошо, когда они есть
— Хорошо
Изначально говорится, что нужно обратиться «к человеку, сообщившему о проблеме». А это не обязательно тестировщик.
Имхо, это элемент вежливости со стороны автора запроса — написать подробно (в разумных пределах, принятых конкретно в этой организации), как получилась проблема. Как показывает опыт, часто разработчик даже и не додумается до такого способа :)
А потом разработчики начинают отдавать фиксы даже не запуская проект после изменений. Зачем? Есть же тестировщик.
Ну и что, что он отдаст обратно через минуту после запуска. Мое время дороже.
Пишу о том, с чем встречался.
Человек закрывал задачу 2 дня, потому-что стеснялся попросить помощи и сделать все сам, а потом написал статью о том, как он героически эту проблему решил.
Только бизнесу не нужно что-бы сотрудники сидели и сами решали проблемы, можно попросить помощи и за 2 дня решить 5 таких проблем, но уже вместе с тестировщиком, вместо того, что-бы тестировщик простаивал, а разработчик выполнял работу за двоих.
Ваш случай конечно тоже возможен, тут главное поймать золотую середину.
На моей работе это более просто происходит:
1. Смотрю задачу
2. Вижу что данных недостаточно
3. пишу в комментариях @тестировщикнейм тут нехватает входных данных, распиши более подробно и запиши видео.
4. Иду заниматься другой задачей
5. Через 30минут-4часа задача дополняется всеми нужными данными.
А если надо срочно — тогда просто списываемся/созваниваемся в чатике, на что уходит 5 минут.
Это надо в каком-то фейсбуке работать что-бы такое происходило.
Да нет, в обычной компании с бюрократией. Я своими глазами видел, как на запрос дополнительной информации не отвечали неделями.
Я своими глазами видел, как на запрос дополнительной информации не отвечали неделями.
Тогда мне остается только посочувствовать вам.
Ладно люди с другими моими сообщениями могут быть не согласны, но что тут вам не понравилось? Или стадный инстинкт в действии?
Человек высказал мнение о том, что каждый должен заниматься своим делом и ситуация с ответом/его отсутствием от тестировщика вызывает вопросы к компетентности в первую очередь тестировщика и качеству менеджмента.
… и вы тоже считаете, что тестировщик вообще есть.
Я вот недавно репортил баг в один OS-продукт. Его поддерживает один человек.
Где там место для бизнес-аналитика, тестировщика, тим-лида и так далее?
заголовок говорит о тайминге
А вы никогда не видели вопросов к мейнтейнеру open source "почему так долго, там одна строчка изменений"?
в содержании упомянут тестировщик
Угу, в контексте "я предпочел бы избежать просить выделенного тестировщика смотреть на "то же самое" изменение". Это не значит, что тестировщик есть.
Впрочем, на самом деле, не суть. Если мы говорим о правильно выстроенных процессах разработки, то в них вопрос из заголовка бессмысленен. Так что и говорить особо не о чем.
А как по другому? Тестировщику в файлик писать, а БА в задачу переносить?
Так же и после ТП и БА задача передается сначала тестировщику, который воспроизводит баг на тестовой среде, дописывает доп информацию, записывает видео и потом уже разработчику, и в «моем» как вы выразились мире, это экономит вещи разработчикам и они потом по 2 дня не исследуют как воспроизвести такой баг повторно.
В чем будет проблема если тестировщик заведет задачу, а аналитик назначит приоритет и разработчика на эту задачу?
Тестировщик тестирует код определенных модулей и продуктов. Больше программиста знает как в целом работает весь бизнес процесс.
Вот именно, поэтому и есть смысл просить тестировщика подробности у бага у тестировщика, а не искать самому.
В «вашем мире» все занимаю чужими обязанностями, а это в свою очередь очень напрягает и направляет к перегоранию (+ многие отказались бы от подобного, к примеру я).
По вашей логике возможно, но я опять же не вижу проблем с тем, что тестировщик создает задачу, а аналитик уже занимается приоритетами, это ничего не меняет.
Так пусть компонирует, кто ему мешает? Джира умеет объединять задачи
А к чему эти вопросы? Я разве говорил что аналитик не нужен?
По поводу вопросов — это вообще смешно, приплели и SOLID и тестировщиков и программистов и аналитиков к месту хранения багов.
Дальше не буду отвечать, надоело
Он может и не знать, что результат, который он считает ошибочным — может быть на самом деле верным, так как он не знает как работает все целиком.
Возможно в какой-то уж очень узко направленной сфере.
Но давайте будем честны, 90% багов в большинстве случаев — это «Не загружается картинка», «Поплыла Верстка», «Не пришло уведомление» и так далее, в том же фейсбуке я не вижу таких узконаправленных вещей в которых тестировщик не сможет определить баг это или нет, так что он вполне может создавать задачи с багами.
А привел солид и прочее к тому, что, если вы не понимаете на примере DDD кто чем должен заниматься, не верю, что вы понимаете на уровне ООП что и как и за что должно заниматься и как это реализовывать.
А вы видимо аналитик, который решил, раз на меня заводит баги тестировщик — значит я не знаю SOLID или DDD и вообще быдло-кодер.
И как вообще можно лепить все в кучу? SOLID без DDD невозможен? Или знания DDD не осилит тот, на кого может задачу тестировщик завести?
что и как и за что должно заниматься и как это реализовывать.
А вот тут вообще какой-то набор слов:
Он может и не знать, что результат, который он считает ошибочным — может быть на самом деле верным
Это как вообще? У Вас программисты лепят фичи без спецификации, от ветра головы своея?
- При возникновении требования аналитик формализует его в виде спецификации.
- Программист в соответствии с этой спецификацией лепит фичу.
- Тестировщик проверяет, что творение программиста этой спецификации соответствует. Если видит несоответствие — заводит багу. Аналитик (да, Вы правы, именно он видит общую картину) для этой баги выставляет приоритет и определяет срочность (эта/следующая итерация, бэклог и т.д.)
Аналитик не может без тестировщика завести багу, ну никак. Тестировщик без аналитика — может. Так зачем задействовать двоих там, где можно обойтись одним?
А если ещё не зарелизили?
Программист запилил фичу, перед попаданием на прод она, естественно, проходит разные этапы проверки, в том числе тестировщиком.
Тестировщик обнаружил баг (несоответствие поведения системы спецификации) — либо он может завести баг сразу сам, либо, по Вашей схеме, должен отвлекать аналитика только для того, чтобы тот под диктовку багу завёл?
А я пишу о том, что вижу в статье.
Это вот ключевой момент. Не "написано в статье", а "вижу в статье". Там, на минуточку, даже не сказано, что это бизнес. И уж тем более не сказано, что человек стеснялся что-то сделать.
Если человека спрашивают, на что там два дня потрачено — значит это бизнес.
Не важно, фейсбук или галера, все равно деньги там важны.
Если человек пишет, что сам хотел разобраться, а не спрашивать с у того, кто этот баг завел — то другой причины кроме как стеснялся — я найти не могу.
У каждого своя задача, у разработчика решать баги, а у тестировщика искать, автор же хочет работать за двоих.
Простите, а что делал товарищ менеджер? Если ему эти 2 дня не горели, то какие вопросы?
А если баг воспроизводится нестабильно — тогда тестировщики даже закономерности такого поведения пытаются найти и описывают это, что опять же экономит кучу времени.
Опять боязнь тестировщика, зачем его нанимали в компанию?
Я поражен вашей уверенностью.
После исправления ошибки в (? чужом) коде вы никогда не сомневались в правильности своего решения и его совместимости с остальными элементами? Не задумывались, по какой причине эта ошибка была совершена? Такая уверенность в собственной непогрешимости, а так же в непогрешимости остального кода, который скорее всего был написан теми же людьми, чьи ошибки и завели этот баг может сыграть плохую шутку.
Кроме этого, никто не гарантирует, что тестировщик, который будет тестировать ваше решение, проверит связанные с этим багом элементы, а не просто по тест-кейсу увидит совпадение с ожидаемым результатом и с радостью отправит свежий код в продакшен. Когда новая ошибка всплывет кто будет больше виноват, тестировщик работающий по тест-кейсу или программист, который в процессе починки одного модуля сломал другой?
Еще встает вопрос гордости. Хорошо, что у вас дружеские отношения с тестировщиками внутри компании, но что если вы работаете в аутсорс-компании, а тестирование происходит уже у заказчика или у посредника? Я уверен, что на каком-нибудь созвоне довольный тестировщик, расскажет как дал по рукам нерадивому погромисту и спас модуль от коллапса. Не скажу, что это большая проблема, но и приятного ничего нет.
Понятно, что такие баги встречаются не каждый день, но все же встречаются. Не то, чтобы я подписался под каждым пунктом автора, но и так категорично к ним бы не относился.
Но и будем честны, решение проблемы в 2 строчки может затянуться и на неделю работы, с этим никто не спорит, и основная проблема таких моментов —
Хорошо, когда есть тестировщик.
Что касается вашего замечания по поводу тестов и ide, тут получается все еще более небрежно, в плане аргументации. IDE даст вам возможность проследить где битый код вызывается, однако данные, которые этот битый код обрабатывает могут пройти еще миллионы итераций кода, положиться в базу или отправиться на обработку в какой-то сторонний сервис или пройти через какую-нибудь BPM и грохнуть чей-нибудь процесс…
Что касается тестов… Задайте вопрос, что делать если тестов не будет? Как в таком случае поступает бизнес? Тратит 40$/ч на написание тестов под древнюю систему?
Что касается тестов… Задайте вопрос, что делать если тестов не будет? Как в таком случае поступает бизнес? Тратит 40$/ч на написание тестов под древнюю систему?
Тогда разработчик фиксит баг, смотрит что проблема решена и если сомневается, что это исправление не повлияло на другие части приложения — просит тестировщика перепроверить другие части приложения к которым есть подозрение (если это занимает больше 5-10 минут конечно же, в противном случае это можно сделать и самому)
просит тестировщика перепроверить другие части приложения
А вот мы и пришли к тому, что вы согласились с автором.
— Как найти эти части приложения?
— Провести анализ, что, собственно, и было описано в пункте, который вы так рьяно хотели спихнуть на тестировщика)
И да, задача проходила полный цикл анализа, была внятная постановка в JIRA, решение, и по итогам разборок было признано, что она была решена в полном соответствии с постановкой. Однакож некоторые нюансы аналитики не учли, потому что не знали о них.
Когда только в твоем в проекте порядка 50 человек, как было тут, далеко не всегда конкретный аналитик может просто предвидеть все последствия своего решения. А уж когда в проекте задействованы пять или шесть разных систем, как было — то и подавно. Если у вас сложная система — то вам никто в общем случае ничего не гарантирует.
В том числе — сроков решения задач на изменение двух строчек кода, потому что эффект изменения проявляется в совершенно другой системе (привет, IDE).
Поймали случайно, в процессе адаптации чужих тестов.
Оказалось что при реализации одной редкой конструкции в байткоде кто-то заметил, что нечётные регистры использоваться не могут и записал в спеке что там должен стоять номер используемой пары регистров (хотя запись шла в один, младший).
Что приводило к тому, что неверно заполнялась табличка сжатия, которую кто-то хитро сжал (да, я знаю, звучит иронично).
Срабатывало это всё, конечно, совсем в другом месте и вообще не в той программе — просто маленькие запросы проходили, а большие — нет (потому что получали неправильную контрольную сумму).
Ну так прикиньте, тут же тоже поймали случайно, потому что
а) это была вообще другая система, о которой просто не думали вообще в процессе постановки задачи. Она вдруг стала получать некие сообщения, которые ей вовсе не предназначались, и о которых тоже никто не думал
б) эти сообщения падали в очередь ошибок, а не доходили до обработки.
Ну то есть, вполне могли бы еще пару годиков это не заметить, пока их обработку случайно не включили бы в той, третьей системе. А вот тогда уже были бы возможно и некие финансовые последствия, и не мелкие.
В общем, все как в анекдоте — на пузе гайку открутил, а сзади что-то отвалилось.
Я работал в одной американской компании, о которой вы гарантированно слышали, и в которой не было тестировщиков принципиально (по крайней мере, в нашем отделе), типа, мы сами себе QA.Я тож в такой работал. Зато там в проекте программистов было в 3 раза больше чем реально необходимо
Уж сколько статей писано — пишите код понятный человеку, используйте информативные имена (не однобуквенные).
Чтобы начинающий программист взглянул и понял.
Такие случаи (болезнь компьютерного мышления) «чинятся» так:
Задача описывается хорошим литературным языком.
Пишется код первого общего теста (соблюдая TDD).
После обдумывания любого метода, перед написанием кода метода (соблюдая SRP), пишется юнит-тест.
Основной код должен иметь вид иерархии объектов/методов.
Держа себя в полезных рамках, отсекая мнимые степени свободы языка, инкапсулируя компьютерное мышление — уменьшаем вероятность непредвиденного поведения кода.
Улучшение осложняется успешным опытом программирования — если у программиста есть в портфолио рабочие проекты со спагетти-кодом — вероятность отказа от собственного стиля разработки уменьшается.
Шучу!
Хороший код, жаль не делает то, что хочется.
Уж сколько статей писано — пишите код понятный человеку, используйте информативные имена (не однобуквенные).
А какие имена на ваш взгляд лучше тут использовать? Я вот не могу придумать какого-то хорошего имени которое бы что-то прояснило.
g : (someInputInt : Int) -> { someOutputIntGreaterThanInputInt : Int | someOutputIntGreaterThanInputInt > someInputInt }Стало ли лучше? Если нет, то какие имена тогда стоит использовать?
0xd34df00d: если объектов вообще нет?
PsyHaSTe: не могу придумать какого-то хорошего имени
Чтобы два раза не вставать.
Коллега.КодРевью = Коллега.Понимание( _
Коллега.Парсер_Увиденного( _
Коллега.Глаза( _
Код( _
Программист.Кодирование( _
Программист.Обдумывание( _
Программист.ЗадачеПриёмник))))))
Вот современный код, а код из однобуквенных переменных из эпохи спагетти :-)
Спагетти = путь к выгоранию. Сам чуть не угорел.
Плохая аналогия подобна котёнку с дверцей.
Давайте конкретнее: вот функция, которая вовзращает произвольное число, больше аргумента. Какие имена выбрать для всех этих переменных?
Инкапсуляция придумана скрывать «как делать», а не скрывать что она вернёт.
Компьютер Ваш код понимает — нам хочется его понять, минимизируя когнитивные усилия.
Однобуквенной вакханалией вы усложняете понимание Вашего кода.
Как по мне стало только хуже ¯\_(°-°)_/¯
Нет, объективно x : Int ничем не хуже numb : Int, я и так вижу из типов что это — число, мне не нужна венгерская нотация в именах. Далее, нейминг заборчиком — зачем? Что хотелось этим сказать. numb — почему не number тогда? Набрали 4 буквы, а на последних двух решили сэкономить? Какой-то очень странный трейдоф.
Так что, не знаю, при чем тут фрукты, овощи и другие продукты, но я вижу только то что кода стало почти в 2 раза больше, а смысла не добавилось ни на гран.
Объясняю метафору про фрукты — у некоторых реально непереносимость фруктов — не повезло им. А в нашем случае у некоторых непереносимость контекстнооудобных имён переменных, методов, объектов — они не замечают накопления когнитивного стресса вызванного когнитивной сложностью — не повезло им.
Стресс сложности накроет их несколько позже, а причину они не увидят (они же не знают о вреде однобуквенных названий).
numb появился не вместо x, а вместо someOutputIntGreaterThanInputInt.
Ок, в чем смысл? Мне вон вместо someOutputIntGreaterThanInputInt больше нравится x
Объясняю метафору про фрукты — у некоторых реально непереносимость фруктов — не повезло им. А в нашем случае у некоторых непереносимость контекстнооудобных имён переменных, методов, объектов — они не замечают накопления когнитивного стресса вызванного когнитивной сложностью — не повезло им.
Я вот не вижу чтобы numb : Int был контекстноудобным и как-то понижал когнитивную сложность.
По-моему, ровно наоборот. У некоторых — непереносимость однобуквенных переменных, и они не замечают накопления стресса от необходимости обрабатывать неунжную информацию.
Угу.
уВеличить: (онемевший: целое) -> { вСкладке: целое | вСкладке > онемевший }
Выбрали, да. Стало хуже.
А "код из однобуквенных переменных" — это, внезапно, из математики.
Я что-то не совсем понимаю, как сигнатура f тайпчекается. Если у x тип (число + доказательство некоторого утверждения относительно этого числа), то почему его можно использовать в сравнении с v?
Ребята столько времени потратили на ожесточенные споры, что не заметили главного. Правы все, просто каждый описывает свою ситуацию на рабочем месте.У оратора с Гаррисоном-Трампом на аватарке видимо на работе худо-бедно все нормально организованно и каждый занимается своим делом + возможно учёт времени построже, потому и ругает автора за то, что
def test_universe(computer_science):
assert computer_science.np == computer_science.p(Я забыл закоммитить фикстуру computer_science, но это не сложно, правда же?)
Настолько жизненно, что хочется плакать..
1. Реально сложный проект с какой-нибудь математикой или нетривиальными алгоритмами (кодеки, рейтрейсинг, библиотеки машинного зрения или ML и т.п.)
2. Разработчик нагородил чудную конструкцию из костылей и подпорок и теперь сам не может в ней разобраться
3. Разработчика назначили на поддержку проекта и он просто потратил много времени на то, чтобы понять что где происходит в чужом коде.
Рассуждать про абстрактную измеримость или нет ценности абстрактных 2 строк кода это не лучшее занятие.
В конце концов, продукт действительно не мой а его, и что он считает нужным — пусть и делает, только без меня, как бы ни жалко было усилий, затраченных на разработку.
Потому что проблема была расплывчатым описанием того, как её воспроизвести. Мне потребовалось несколько часов, чтобы надёжно её воспроизвести. Некоторые разработчики немедленно бы обратились к человеку, сообщившему о проблеме, и потребовали бы больше информации, прежде чем проводить расследование. Я стараюсь получить как можно больше из той информации, которая есть в наличии.
Связаться с создателем задачи и пообщаться по поводу воспроизведения ошибки — это обычная практика. И это не повод чтобы ничего не делать, а наоборот.
Я хочу понять, вы никогда по своим задачам не связываетесь с их создателем, чтобы уточнить их?
Или понять что дороже, 1) ждать когда разраб сам догодается что от него нужно 2) организовать коммуникацию с бизнес-пользователями.
Вы обратились к первой линии за уточнением. Первая линия обратилась к клиенту. Клиент видит как минимум, что его проблемой занимаются.
В первом случае, когда разраб сам что-то пыхтит, никто ничего не видит и потом приходится объяснять куда уходит время.
Равзе нет?
То, о чем вы говорите, работает только со старыми подсевшими клиентами, которые плотно сели на иглу вашей инфраструктуры и хотят исправления бага… если не вмешивается их отдел ИБ и не начинает ставить палки в колеса. Если все нормально, то за 2-7 дней из клиента можно вытянуть описание как порвторить баг, а если какие либо проблемы, то эта волынка может тянуться и месяц и полгода. Я не шучу, с такими сроками я как раз по работе периодически сталкиваюсь. До кучи еще саппорт будет каждую неделю тебя спрашивать, а не зменилось ли там чего-нибудь… ну и что, что новых данных не появилось, у клиента руководство же интересуется.
И в таких случаях реально проще кинуть разраба как котенка без внятного описания, а параллельно пытаться вытянуть из клиента новую инфу или хотя бы протестить на нем изменения. Объяснять правда не приходится куда время ушло, все и так прекрасно понимают, что дерьмо случается и случилось в очередной раз.
Первая линия обратилась к клиенту. Клиент видит как минимум, что его проблемой занимаются.
Вы в идеальном мире живете, не видят и не хотят видеть. Их не интересует что вы занимаететсь, их интересует только исправление. Ибо по вашему варианту обычно заканчивается все фразой в таске: «клиенту наш сервис в данном состоянии не интересен, т.к. не позволяет решать его задачи», и остаетесь вы ровно с тем, с чего начинали: баг без внятного описания проблемы и отсутствие возможности получить это описание. Только до кучи потерян месяц и кодовая база уже изменилась.
Вопрос коммуникации с клиентом — это компетенция техподдержки и отделов по работе с клиентами, но никак не разработчика. Если клиент так ответил то тем более отделу по работе с клиентом стоит всячески выяснить что клиенту не нравится.
По вашему случаю я вижу, что у вас есть какой-то сырой функционал, который не совсем подходит клиентам. И нет недостатка сил разработки, то есть вы бы сделали, если бы точно знали как. Это показывает в чём у вас узкое место.
Вы можете отказаться и не тратить время на сырой функционал.
Либо реализовать его в точности по запросам клиента. Так как «ошибки» — это могут быть не ошибки вовсе, а неточность изначальной задачи и вы выяснили новую фичу.
Пока что я вижу, что вы берёте на себя чужую ответственность.
Вам ничего не мешает попросить саппорт уточнения задачи и продолжать ей заниматься самостоятельно, так как будто вы и не просили. Вы ничего не потеряете от этого, но вам могут помочь.
Вот мы и пришли к 2 строчкам кода за 2 дня, ЧТД. Ибо за 2 дня далеко не от всех можно получить описание что случилось.
По вашему случаю я вижу, что у вас есть какой-то сырой функционал, который не совсем подходит клиентам. И нет недостатка сил разработки, то есть вы бы сделали, если бы точно знали как. Это показывает в чём у вас узкое место.
Когда работает не так как ожидается у одного из сотен, это уже не сырой функционал. Особенно когда оно крутится уже несколько лет. Это вполне обычная история, когда появляется новый клиент.
Вы можете отказаться и не тратить время на сырой функционал.
Либо реализовать его в точности по запросам клиента. Так как «ошибки» — это могут быть не ошибки вовсе, а неточность изначальной задачи и вы выяснили новую фичу.
Это работает только в случае аутсорса. В случае торговли готовым софтом/сервисом, ситуация обратная: бог его знает что у этого клиента сломалось, у остальных пары сотен все работает нормально.
Пока что я вижу, что вы берёте на себя чужую ответственность.
Что вы, всего лишь устраиваю гонку, кто быстрее найдет проблему: саппорт или я.
― Albert Einstein
Если же в задаче изначально требуется какой-то ресерч или экспертное мнение, которое можно сформировать только покопавшись самому, то это другой разговор. Но такие конкретные вещи как баги или фичи должны иметь максимально четкие требования (если же конечно вам сверху к вашей ЗП не доплачивают ЗП аналатика/тестера и т.д.)
И нередко описание проблемы сводится к тому, что «некоторые пользователи жалуются, что наше приложение у них не работает в Таджикистане». Причём пользователей много, и проблему воспроизвести вне Таджикистана не получается.
И я знаю, что вы предложите — отправить тестировщика в командировку, чтобы он воспроизвёл проблему. Если пользователи приносят не миллионы долларов так не будет делать никто. А если будет, то уже можно спокойно позвать подавальщика платочков для правой руки, и протереть её перед тем как поставить на задаче штампик «Won't do».
И нет я не предложу отправить тестера в Таджикистан. Я попрошу больше входных данных о проблеме, чтобы хотя бы понять, что чинить. Как минимум шаги воспроизведения, реальный результат, ожидаемый результат.
Разработка массового продукта очень отличается от «систем автоматизации» для банков и других штучных заказчиков. У продукта может быть не 100 пользователей в галстуках и наруч… костюмах, а хотя бы 10 миллионов. И никто из них ничего не должен и не хочет отвечать, а если ваш продукт что-то плохо делает… есть ещё несколько у конкурентов.
И даже если вам попадётся человек, который искренне захочет помочь, и за счёт своего времени и денег попробует воспроизвести вашу (в общем-то) проблему, и помочь вам улучшить ваш продукт, вовсе не факт, что удастся воспроизвести нечастый случай, когда происходит баг.
Компания несёт убытки, а вы упёрлись рогом, и уверены что она должна предоставить вам любую информацию по запросу. А может быть стоит самому мозг напрячь? Не надеясь на аналитиков, тестировщиков и саппорт? Работа программиста — думать, а уже во вторую очередь — писать код.
Не надо изобретать велосипед и пытаться выяснить то, что другие люди могут вам рассказать, достаточно просто спросить.
Ну то есть если какой-то пользователь заорет, что-то типо «У меня ничего не работает» и вы тут же всё бросите и начнете проводить полную регрессию всего приложения, чтобы понять что же конкретно не работает
Нет, конечно же. Для этого и есть поддержка, которая может собрать статистику, попробовать разобраться в том, чего же пользователь хочет, и, при необходимости (например, заметив высокую частоту обращений, или важность функционала), эскалировать инцидент. Простите, перешёл на новояз — создать задачу о проблеме.
Помоему лучше идти по пути наименьшего сопротивления, задав уточняющие вопросы, чем в общем-то и должна заниматься поддержка. Поддержка — это не ретранслятор криков пользователей.
Вот это-то «идти по пути наименьшего сопротивления» мне и не нравится. В компаниях, где копают от забора и до обеда, это самый естественный ход мыслей для сотрудника. Мне же хочется делать продукт лучше, даже если я сам им не пользуюсь. И мне чётко известно, что не во всех случаях можно получить всю нужную информацию. Да, можно попросить техподдержку о ней, но сидеть и ждать пока информация появится — слишком большая роскошь.
Особенно забавно это будет выглядеть, если в итоге окажется, что пользователь идиот и делает что-то не так, а система отрабатывает штатно, согласно его неадекватному поведению.
Вы реально, как мне кажется, работаете в основном с корпоративным софтом. С пользовательским, особенно с массовым пользовательским софтом это так не работает. Если пользователь «глупый» — это может быть его проблема, но если их таких много — это ваша проблема. И если штатное поведение вашей программы вызывает недоумение и даже письма или звонки в поддержку, вероятно что-то не так с вашим софтом, а не с его пользователями. Да, пользователи часто поступают неадекватно (на чей-то взгляд), это нормально.
Нет, конечно же. Для этого и есть поддержка, которая может собрать статистику, попробовать разобраться в том, чего же пользователь хочет, и, при необходимости (например, заметив высокую частоту обращений, или важность функционала), эскалировать инцидент. Простите, перешёл на новояз — создать задачу о проблеме.
Вот собственно об этом я веду речь. Задачи на разработчика в большинстве случаев (за исключением каких-то авральных рушащих прод ошибок) должны поступать (в идеале) подробно оформленные, для этого и существует прослойка в виде поддержки/бизнес-аналитиков/системных аналитиков, которые систематизируют и в принципе оценивают адекватность сообщений пользователя, расставляют приоритеты и т.п.
По поводу пути наименьшего сопротивления, как мне кажется, идти по вашему сценарию, бросаясь на амброзуру по поводу и без — это путь к скорейшему написанию на хабре очередной статьи про «выгорание».
В чем разница массового софта и корпоративного в данном случае? И там и там есть и должна быть первая линия поддержки. И там и там могут резко возникнуть внештатные ситуации, которые требуют незамедлительного решения. И там и там поддержка должна среагировать на сообщение пользователя об ошибке, постараться собрать максимум инфы с него и передать разработчикам (либо в бэклог, если не срочно).
По-моему логично:
2 дня — 2 строчки
В общем было все плохо. Проект не самый приоритетный в компании, но денег приносил много. Ковырялся долго, несколько дней точно. Может неделю, не помню уже.
В итоге я удалил из кода РОВНО одну строчку (потом ненужные вещи тоже, но это уже потом), и проект стал летать.
Вместо 15-60 секунд ответ от сервера стал занимать 600мс!
Вопросов не возникало
Страница состояла из списка бизнесов, в т.ч. и с указанием среднего рейтинга на основе отзывов пользователей. Так вот это было сделано средствами PHP и MySQL самым глупым способом, а именно — по одному запросу на каждый отзыв, а потом суммирование и деление на стороне сервера.
Понятное дело, что когда ресурсов было много, а отзывов мало — вроде как-то это и работало. Но через несколько лет, плюс переезд в облако — и все пошло по одному месту.
Смешнее было то, что кто-то еще до меня это уже исправил, и вместо сотен или тысяч запросов на странице было несколько, где через MySQL запрос просто получают AVG для бизнеса. НО, эти товарищи забыли удалить СТАРЫЙ код. В итоге работало и то и то. Я удалил старый код.
Если какой-то код выдаёт ошибку, вы можете просто отловить оператор и подавить ошибку.
Скажите, кто из вас отлавливает операторы?
Полез в оригинал, и там вот:
If some code is throwing an error, you could just wrap it in a try..catch statement and suppress the error.
Гугл, кстати хорошо справился:
Если какой-то код выдает ошибку, вы можете просто обернуть ее в оператор try..catch и устранить ошибку.
Две строчки. У меня для изменения одного символа ушла неделя. Да, когда докопался — всё стало просто и логично, но путь был долог.
Потому что я исследовал, существуют ли другие способы воспроизведения проблемы, а не только описанные этапы
Если разработчик занимается R&D, а пишет только код это деньги на ветер. Следующему за ним придется повторять весь путь заново? Я бы предпочел, чтобы на выходе появился отчет о проделанном исследовании с анализом причин ошибки, обнаруженных зависимостях, подводных камнях, и обоснованием выбранного решения. Это поможет коллегам быстрее погружаться в данную функциональность. Кроме того, стоит добавить юнит тесты, если нет обоснованных причин этого не делать.
Я как—то дал оценку времени разработки модуля: «дней 7 код писать и дня 3 баги вычищать»; в ответ получил предложение всё сделать за 4 дня — сразу написать без багов: время на написание багов не потребуется и на их исправление. Реальная история
Директор — универсальный торговец. Отношения были хорошими. В комнате было ещё пару человек. Сначала мы зависли, потом рассмеялись до слёз, потом объяснили, как это работает))
Интересно, а что Вы говорили в ответ на эту фразу?
Я бы ответил: «Ну тогда 21 день»
Ты добавил всего две строчки. Почему на это ушло два дня?