Вы заметили в крутых боевиках, не менее крутые, чем сам боевик герои, не просто мочат все направо и налево , но и просчитывают ситуацию на десять шагов вперед. Именно благодаря этому, ну и быстрой руке (которая как известно лучший друг индейца) они спасаю свою заднюю часть от разнообразных неприятностей.
Шахматисты, они тоже видно в прошлом супергерои, и тоже пытаются считать ситуацию наперед.
Так же наперед пытаются считать ситуацию инвесторы, банкиры.
Одни только программисты не нуждаются в этих всех бреднях. Они гордо выступают в неровный бой с багами, засучив руки и выключив мозг.
Шучу, конечно, не все программисты так делают, собственно, об этом и буду говорить.
Самый правильный метод разгребания багов, особенно , если они не слишком интуитивные, состоит в том, чтобы составить план. План должен состоять из списка идей, что может быть сломано такое, что приведет к такому багу и самый простой способ проверить свою теорию – из-за это происходит ошибка или нет.
Просто постоянно вижу картину, когда молодой (и горячий) разработчик бросается в бой с багом, по пути наталкиваясь на новый и бросаясь разбираться с ним и так обнаруживающий себя через неделю в глубине кода работающий неизвестно над чем. Причем, если его спросить, какой был изначальный баг, то где-то секунд десять в отражении его глаз можно расчесываться, после чего человек с напряжением выдает какую-то вразумительный ответ.
Так что, нужно всегда выстраивать дерево (сначала желательно на бумаге), потом можно и в голове. Дерево должно выглядеть так – идея N1 (что сломано) + как проверить, идея N2 + как проверить и т.п.. Почему я говорю дерево, да потому, что иногда в не слишком удачно написанных проекта, проверка теории не удается без того, чтобы, например, пофиксить другой баг (для которого тоже нужны записывать варианты). И чем глубже приходятся «копнуть» тем больше шансов потом забыть какой-то из кусочков этого дерева.
Кстати, еще забавность, в том, что зачастую некоторые идеи можно проверить и откинуть даже не садясь за комп. Просто потому, что думаешь, а вот если будет сломано это, то, хотя баг такой и будет наблюдаться, но вести оно должно себя по другому. Именно эта возможность, прокрутки ситуаций в голове отличает хорошего программиста с опытом работы на проекте от просто хорошего программиста или просто человека с опытом работы на проекте. Зачастую обнаружение багов и нахождение, откуда они пришли занимает таким методом в десятки раз меньше времени, чем тупое копание.
Ну и вернусь к тому, что я говорил, что метод проверки теории должен быть наибыстрейший. Как по мне, один из самых эффективных метод – комментировать большие куски кода. Это сразу позволяет выявить внутри этого ли модуля находиться баг. Хотя есть и другие не менее эффективные методы.
И еще одно мелкое замечание, что если возможно придумать тест, который опровергнет или подтвердит сразу несколько теорий, то это лучший метод сократить себе время пофикса.
