Сдается мне этот способ настолько трудозатратен, что всерьез его рассматривать банально не стоит :)
А как вы узнаете, в какое из множества мест логирование добавить?
В том и дело, что логгирование добавляется при написании кода, а не после возникновения ошибки. То есть я не буду узнавать «в какое из множества мест добавить лог» — я его просто добавлю во множество мест, и получу вполне ясную, хоть и весьма объемную картину происходящего.
Но вообще я говорил о случае, когда ошибка стабильно воспроизводится. То есть можно сказать, что в этом месте ошибки еще нет, а в этом уже есть. Ставим несколько точек в разных местах, между ними запускаем, чтобы работали все потоки. Если есть возможность поставить брекпойнт на изменение данных, то еще лучше, остановится сразу в нужном потоке.
Не поможет в случае, когда данные сломаны в момент T, а в виде ошибки проявляются в момент T+сколько-то итераций. Придется идти вверх по коду, в поисках места, где данные были поломаны, а таких мест может быть много. Стабильность воспроизведения ошибки тут мало что дает.
Извините, эту часть я не понял. Код никуда не девается, ставить надо заранее.
Так куда заранее? Данные пришли, скажем по сети, в виде websocket-сообщения, были преобразованы, разложены в разные структуры данных, которые прошли многопоточный конвеер обработки и преобразования, протиснулись сквозь разные очереди и преобразователи, и на выходе вы обнаруживаете, что там, где ожидается не ноль — у вас ноль. При чем не всегда, а в одном случае на миллион входных сообщений. Имея лог вы возьмете id поломанного сообщения, и сможете отследить весь процесс преобразования в обратную сторону, и найдете место, где возник этот ноль. В этом месте может быть даже ошибки не будет — ошибка будет еще раньше. И вы продолжите идти по логу вверх… Как в таком виде будет выглядеть разбор бряками? Поставил бряк с условием «если ноль», запустился, дождался останова, пошел смотреть, что на входе в метод, пошел выше, поставил бряк с условием… смыть, повторить. Или не так?
Простите, но вы прям уверены, что можете «поставить бряк в соседнем потоке»? А как вы этот поток найдете? Как узнаете какое из множества мест, в которых мутируют данные вам нужно? Это не говоря уже про то, что к моменту ошибки данные УЖЕ изменены, и бряк ставить просто некуда, вы это место уже покинули.
И что вы в этом случае увидите? Предположим вы увидели мусор в данных — вам интересен не сам факт того, что на входе мусор, а почему он там возник. А возник он там из-за того, что соседний поток данные попортил. Если он это записал в лог, то последовательность событий вы худо-бедно восстановите, а вот если у вас только бряк, то увы…
Как «и что»? До тех пор, пока подчиненные на морально-волевых нивелируют влияние этих истерик все в порядке, но вот какой-нибудь специалист совершенно справедливо скажет «да Рамзес оно все конем», и свалит из этого дурдома в поисках более адекватного начальства — и начнется… А что может начаться с таким директором? Разумеется еще одна истерика. Самосбывающееся пророчество, как оно есть. И бизнес медленно покатится вниз.
технологические итерации, когда команда между проектами целую итерацию делает только техдолг и инженерные задачи ( реально работает, но крайне непросто убедить бизнес пойти на это)
У нас не сработало. В частности потому, что если три итерации делается «бизнес» из говна и спичек, при экономии не только на спичках, но и на говне, с аргументацией «надо дать бизнесу ценность СЕЙЧАС, а на тех-итерации поправите и сделаете по уму», то к тех-итерации подходишь со слоем костылей, который вырос еще на одном слое костылей, под которыми тоже не все слава богу. И переделать за одну итерацию то, что говняколось три нет никакой возможности, в лучшем случае причесать слегка, что б самый страшный ужас наружу не лез.
Да, если есть комментарий в коде, значит код не достаточно отвечает на вопрос о том, что в нем происходит, так что идеальный код — это код, который можно понять без единого комментария. Исключение — когда коммент отвечает не на вопрос «что здесь происходит?», а на вопрос «почему происходит именно это?». В бизнес-логике сплошь и рядом приходится писать комменты вида: «Вот этот БРЕД тут происходит потому, что приходится учитывать условия маркетинговой акции, которая завязана на фазу луны и первую букву отчества пользователя».
Каким образом вам удавалось гарантировать итоговую неотличимость, если вы не были уверены в «правильности» и «надежности» внутренностей реализации? Весь мой опыт говорит, что если внутренности говно, то они сломаются гораздо раньше, чем вы дойдете до финиша, при этом в самых неожиданных местах.
Я хотел сказать, что высказывание «выбросить первую версию» относится к несколько иному виду прототипа, чем тот, который описан в статье. В статье, фактически, речь идет о демо-версии, то есть урезанной количественно версии готового продукта, которая качественно не отличима от того результата, к которому мы стремимся. Прототип же, по крайней мере классически, это нечто сляпанное из говна и палок на коленке, с целью проверить вполне конкретные свои предположения, после чего он должен быть выкинут как раз в силу того, что он из палок и говна. Применительно к описанному в статье должно быть как-то так — в процессе создания того самого «готового вылизанного уровня» многократно создавались и уничтожались различные прототипы различных частей системы, которые должны были ответить на вполне конкретные вопросы, которые «отливали в граните» уже потом. Как-то так. Надеюсь получилось донести мысль.
ПотрахушкиПобрехушки на Привале.Сдается мне этот способ настолько трудозатратен, что всерьез его рассматривать банально не стоит :)
В том и дело, что логгирование добавляется при написании кода, а не после возникновения ошибки. То есть я не буду узнавать «в какое из множества мест добавить лог» — я его просто добавлю во множество мест, и получу вполне ясную, хоть и весьма объемную картину происходящего.
Не поможет в случае, когда данные сломаны в момент T, а в виде ошибки проявляются в момент T+сколько-то итераций. Придется идти вверх по коду, в поисках места, где данные были поломаны, а таких мест может быть много. Стабильность воспроизведения ошибки тут мало что дает.
Так куда заранее? Данные пришли, скажем по сети, в виде websocket-сообщения, были преобразованы, разложены в разные структуры данных, которые прошли многопоточный конвеер обработки и преобразования, протиснулись сквозь разные очереди и преобразователи, и на выходе вы обнаруживаете, что там, где ожидается не ноль — у вас ноль. При чем не всегда, а в одном случае на миллион входных сообщений. Имея лог вы возьмете id поломанного сообщения, и сможете отследить весь процесс преобразования в обратную сторону, и найдете место, где возник этот ноль. В этом месте может быть даже ошибки не будет — ошибка будет еще раньше. И вы продолжите идти по логу вверх… Как в таком виде будет выглядеть разбор бряками? Поставил бряк с условием «если ноль», запустился, дождался останова, пошел смотреть, что на входе в метод, пошел выше, поставил бряк с условием… смыть, повторить. Или не так?
У нас не сработало. В частности потому, что если три итерации делается «бизнес» из говна и спичек, при экономии не только на спичках, но и на говне, с аргументацией «надо дать бизнесу ценность СЕЙЧАС, а на тех-итерации поправите и сделаете по уму», то к тех-итерации подходишь со слоем костылей, который вырос еще на одном слое костылей, под которыми тоже не все слава богу. И переделать за одну итерацию то, что говняколось три нет никакой возможности, в лучшем случае причесать слегка, что б самый страшный ужас наружу не лез.