Comments 28
Очень перекликается с главой «Руководство по отладке Дьявола» и последующими из «Совершенного кода» Макконела.
А кто это — кодировщик?
Допустим, здесь всё написано верно, и это действительно правильный алгоритм действий при отладке. Но в чём состоит альтернатива? Вот если не следовать этим правилам, то это значит действовать как? Попробовать решить проблему интуитивно с наскока, а после того, как это не удастся, просто тупо сидеть и смотреть в экран в ожидании новых интуитивных прозрений? Неужели кто-то так делает? Не понимаю, от чего предостерегает данная инструкция.
Как мы поняли, то как раз от того, чтобы сидеть и смотреть в экран в ожидании озарения. Его ведь может и не быть.
Многие на самом деле делают. И причем даже опытные программисты ведутся на этом. Проблема в том, что при интуитивном подходе проблема может быть решена за 5 минут, а может быть и не решена за 2 недели. И главное — нельзя оценить сложность и время выполнения задачи. То есть например — выявили баг, и программист говорит — «А я знаю, это лечится за 5 минут». Проходит час, день: «Вылечил?». «Нет, но я примерно знаю где это. Должно вылечиться при следующей компиляции». Неделя: «Вылечил?» — «Нет, закончились идеи». В итоге время потрачено, а воз и ныне там, так как новой информации 0%.
Так несколько раз случалось с моими программистами, пока я им не сказал — Стоп. Решай задачу по-моему — примерно как описано в статье. Они всегда в первое время сопротивляются, так как по их мнению это долгий и неинтересный путь, и проблему можно было бы решить гораздо быстрее интуитивным методом. Но я знаю, что это не всегда так, и главное — знаю, что решение любой проблемы теперь займет хоть и не такое маленькое, но определенное время. Это очень важно для менеджера проекта.
Еще важная деталь — при таком подходе у вас на каждом этапе будет появляться новая информация, которая не будет потеряна на следующем шаге. Мало того, она может быть полезна при выявлении следующего бага, если будет правильно проанализирована и доступна через баг-треккер. При интуитивном подходе ценность полученной информации приближается к 0.
Так несколько раз случалось с моими программистами, пока я им не сказал — Стоп. Решай задачу по-моему — примерно как описано в статье. Они всегда в первое время сопротивляются, так как по их мнению это долгий и неинтересный путь, и проблему можно было бы решить гораздо быстрее интуитивным методом. Но я знаю, что это не всегда так, и главное — знаю, что решение любой проблемы теперь займет хоть и не такое маленькое, но определенное время. Это очень важно для менеджера проекта.
Еще важная деталь — при таком подходе у вас на каждом этапе будет появляться новая информация, которая не будет потеряна на следующем шаге. Мало того, она может быть полезна при выявлении следующего бага, если будет правильно проанализирована и доступна через баг-треккер. При интуитивном подходе ценность полученной информации приближается к 0.
Так автор-то как раз предлагает делать наоборот. Пока посещают интуитивные прозрения о том, как решить проблему по-быстрому, нужно опираться только на них. И лишь тогда, когда источник быстрых решений иссякнет, надо прочитать наконец инструкцию, засучить рукава и начать работу всерьёз. Он не предлагает с самого начала относиться к делу серьёзно.
Нууу… не знаю. В самом начале он говорит так:
Но одной интуиции недостаточно. Я столкнулся со стеной. И никакой инстинкт кодировщика не помогал мне сквозь нее пробиться.
То есть он понял, что до этого делал не совсем правильно. И советует так не делать.
Но одной интуиции недостаточно. Я столкнулся со стеной. И никакой инстинкт кодировщика не помогал мне сквозь нее пробиться.
То есть он понял, что до этого делал не совсем правильно. И советует так не делать.
А в конце он пишет, что если проблема находится над зелёной линией, то нужно пробовать решать её интуитивно. Т.е. он действует как гадалка. Призывает действовать, используя оба подхода. Якобы они оба хороши. Каждый в своих обстоятельствах. И в результате каждый читатель увидит в тексте подтверждение того, что он и так всё делает правильно. Ведь его обстоятельства как раз именно таковы…
Мое мнение (сугубо субъективное): сначала стоит узнать, сколько вообще есть времени на выполнение задачи. Затем включить профессиональную интуицию, попробовать решить задачу (заранее обозначив небольшой промежуток времени на это отведенный, например, 3 часа). Если время истекло, а проблема не решена — переходить к системным методам.
По-моему, это единственная стратегия, действительно ведущая к результату. При этом она более-менее очевидна. Удивительно, что у них там, в Канаде, нужно писать статьи, которые либо описывают очевидное, либо предлагают что-то другое и неправильное. (В результате, я так и не понял, автор предлагает делать так или иначе.) Проблематизируется какой-то тривиальный вопрос, который в действительности ни перед кем не стоит.
Ну я тоже даю шанс — спрашиваю сколько времени нужно и умножаю на 3. Если проблема в течении этого времени не решена — все следующие попытки обрубаются и начинается систематический подход.
Немного капитанская статья, мне кажется. Если действительно хочешь исправить ошибку (или не хочешь, но надо), то обычно так и делаешь — сначала наиболее вероятные места, потом менее вероятные, потом остается только проверить всё оставшееся по очереди, в отладчике либо убирая из кода.
Я бы еще добавил, что если во время поиска ошибки вы обнаружили, что что-то работает, хотя не должно, то тоже надо найти причину. Возможно, эта ошибка компенсируется другой ошибкой. И наоборот, иногда полезно проверять предположения типа «если я тут сделаю вот так, то там должна возникнуть такая-то ошибка».
Я бы еще добавил, что если во время поиска ошибки вы обнаружили, что что-то работает, хотя не должно, то тоже надо найти причину. Возможно, эта ошибка компенсируется другой ошибкой. И наоборот, иногда полезно проверять предположения типа «если я тут сделаю вот так, то там должна возникнуть такая-то ошибка».
«Разбежности»?? Что это? Не могли же вы так опечататься в слове «различия»…
Sign up to leave a comment.
Хорошие инстинкты кодировщика в конечном итоге «ударят вас по зубам»