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

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

у SQlite был баг? у системы, для которой тестов по объему больше чем собственно кода?

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

Edited at 2015-10-23 13:12 (UTC)

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

Это как в анекдоте про внедорожник.

Который застрянет там, куда другая машина не проедет. :)

Edited at 2015-10-23 13:45 (UTC)

Как я Вас понимаю. Но это Вы не пробовали дебаггировать СВЧ - систему. С криогенными элементами. И супер- ультра- низкошумящими усилителями.

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

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

Наудачу в СВЧ помогает очень редко. Надо применять левоинтуитивные методы.

Горе от ума.

Везет вам. С багами процессора/борда уже сталкивались?

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

А мне в этом сборнике Чапека больше всего нравится первый рассказ: "Случай с доктором Мейзликом". Бывает придумаешь какую-нибудь штуку и потом гадаешь: это простая удача, или это какие-то способности? А если способности, то как эту удачу повторить?

Да, он отличный.

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

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

Edited at 2015-10-23 20:23 (UTC)

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

Надо попросить ув. Авву сделать опрос на тему "у нас скрам" vs. "а у нас нет". :-)

Спасибо, бегу читать!

Мой муж когда-то с одним знакомым работали электронщиками на ЭВМ в России. Не потому что у них было образование такое, а просто взяли их, других видно не было. Машина эта часто ломалась.
Друг моего мужа лазал по схемам искал, где причина сбоя. А мой муж вынимал последовательно все микросхемы (тогда уже были первые чипы) и вставлял их назад - и после этого все начинало работать. Усилия его друга тоже приводили к позитивному результату, он находил причину и устранял ее. Но у ПП это получалось быстрее.

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