Я написал свои первые несколько строчек кода почти 32 года назад, когда мне было 6. Я развил очень сильные инстинкты программирования и мог смотреть на любую проблему, сразу зная, как ее решить — просто интуитивно.
К тому времени, когда я стал писать программы, чтобы зарабатывать себе на жизнь, я чувствовал себя рок-звездой. Я находил и исправлял ошибки быстрее, чем кто-либо из моих коллег. Моя команда отдавала мне самые незаметные и запутанные баги. Они даже стали называть меня мастером.
Но одной интуиции недостаточно. Я столкнулся со стеной. И никакой инстинкт кодировщика не помогал мне сквозь нее пробиться. Далее Bill Sourour поделится с нами информацией о том, как не останавливаться на достигнутом. Кому-то эти рассуждения, безусловно, покажутся очевидными. Ну, а кому-то — пригодятся.
Проблема недоверия к собственной интуиции
К сожалению, интуицию нельзя считать средством решения проблем. Когда вы полагаетесь только на интуицию и инстинкты, то получаете кривую, которая выглядит вот так:
Конечно, вы сможете принять эти ограничения и справляться только с теми проблемами, которые не выходят за рамки границ. Это даст вам возможность почувствовать себя звездой, но при этом сильно ограничит ваш профессиональный и карьерный рост. Кроме того, это скучно.
Я продвигался дальше и дальше по карьерной лестнице – я начал бросать вызов собственным возможностям – и начал замечать тревожную тенденцию. Я больше не был самым быстрым.
Я всегда знал, что рано или поздно встречу людей сильнее и талантливее себя. Моя мания величия имела свои пределы. Я понимал, что я не гений.
Я осмотрелся и понял, что люди, которые меня окружают, вовсе не одарены превосходящим меня интеллектом, у них нет особого дара. У них просто есть особое оружие, которого мне не хватает: дисциплина.
Оказывается, что последовательный, пошаговый, методичный подход к изучению и решению проблем в конечном итоге превосходит любые природные данные (или инстинкты, которые вы стараетесь развить).
Давайте рассмотрим эти способности
Независимо от того, кто вы, сколько страсти или природного таланта в вас заложено, рано или поздно вы достигнете предела. Я поделюсь с вами несколькими приемами, которые помогут кардинально решить проблему с дисциплиной и развитием ваших способностей.
Я уверен, что, если у вас есть отладчик, вы уже его запустили, погуглили немного, и не добились результата.
Также я уверен, что, если бы об этой проблеме вам кто-то рассказал, вы бы ее воспроизвели. Это важное утверждение. Если вы не можете воспроизвести проблему, то это и будет ваш первый шаг.
Вам нужно сравнить контекст и среду, в которой произошла проблема с теми, в которых вы пытаетесь ее воспроизвести. Начните устранять разбежности, одну за другой, пока не воспроизведёте условия.
Как только вы сможете воспроизвести проблему, и как только дебаггер окажется бесполезным, стоит воспользоваться методом дисциплины.
Прочтите чертову инструкцию!
Прочтите инструкцию, в конце концов! Подход RTFM состоит не только в этом, но даже дети умеют читать.
На самом деле, прочтите. ?И не один раз, если это необходимо. Не просмотрите ее в поисках того, что сможете скопировать/вставить и надеяться, что все заработает.
Проблема в том, что ответ вам нужно быстро. Вам нужен трепет легкой победы. Вы не хотите поработать. Притормозите. Вдохните. Возьмите кофе. И прочтите сопутствующую документацию!
Если документации нет, ее стоит создать после того, как вы разберётесь с проблемой. Она сможет пригодиться кому-то другому.
Проверьте ваши предположения
Если вы предполагаете, что что-то должно работать, а оно не работает, это потому, что где-то вы допустили ошибку. Проверьте все ваши предположения и найдите верный ответ.
Начните с самых простых предположений, которые можно легко проверить. Запущен ли сам сервер? Он подключен к сети? Все скобки и точки с запятой на своем месте?
Если вы не начнете с самых простых предположений, а потом окажется, что именно в этом и была проблема, вы будете готовы выброситься в окно. Так что сберегите себе время и нервы.
Разберите и соберите заново
Убирайте компоненты пошагово до того момента, пока все не начнет работать, а потом соберите все заново, и вы найдете нерабочую часть.
Это выглядит нудно и страшно, но это один из самых эффективных способов найти ошибку в коде. Убедитесь, что перед началом вы сделали резервную копию на случай, если все окончательно испортится. Так вы всегда сможете вернуться к начальной точке.
Кстати, если вы оказались в ситуации, когда не знаете, как восстановить код, значит, проблема серьезнее, чем кажется: вы не понимаете код, с которым работаете. Это плохой знак, друг мой.
Если у вас горят сроки, обратитесь к кому-нибудь, кто лучше вас разбирается в коде. Если такого человека рядом нет, вас ждет бессонная ночь. Стоит понять, как этот код работает. Только тогда вы сможете его исправить.
Исключите переменные
Все, что может меняться хоть в одной из точек, должно оставаться статичным, пока идет процесс отладки. Вы не сможете попасть в движущуюся мишень.
Тут вам поможет Разработка Через Тестирование (TDD). Если вы используете TDD, тогда вы должны иметь в своем распоряжении несколько фиктивных объектов (Mock-объектов).
Фиктивные объекты симулируют контролированное поведение реальных объектов. Программист, как правило, создает макет объекта для проверки поведения какого-то другого объекта. Это во многом подобно тому, что делает автомобильный дизайнер используя краш-тест манекена для моделирования динамического поведения человека во время автомобильного происшествия.?—?Википедия
Подсказка: если в ходе экспериментов с объектом ошибка исчезла, значит, скорее всего, проблема именно в этом объекте.
Используйте «Saff Squeeze»
Существует техника, которая называется «Saff Squeeze?» («тиски Саффа»), ее автор и создатель Кент Бек?. И это нечто среднее между предыдущими двумя вариантами.
Автор ее описывает так:
Чтобы эффективно изолировать дефект, начните с теста системного уровня и постепенно продвигайтесь вперед, пока не найдете минимально возможный тест, который продемонстрирует дефект.
— Кент Бек
Таким образом, вместо того, чтобы копаться в коде, просто нужно добавить тестируемые функции в сам тест, а потом проверять утверждения, пока сама ошибка не исчезнет.
Это даст вам преимущество: вы сможете выполнять все меньшие тесты, которые, тем не менее, будут максимально сфокусированными.
Примечание: Джим Балтер предоставил нам эту ссылку для лучшего понимания техники «Saff Squeeze».
После того, как все исправите, сломайте снова, и снова исправьте
Никогда не оставляйте ошибку, пока не поймете, как вы ее исправили. Вы должны научиться воспроизводить ошибку и снова ее исправлять.
Вы себе не представляете, насколько это важно. Если вы исправите ошибку, и не будете знать, откуда она берется, и как именно вы ее исправили, она вернется и атакует вас снова в самый неподходящий момент.
А что же с инстинктами?
Теперь, когда вы выучили эти техники, это значит, что вы должны пользоваться ими, а не доверять собственным инстинктам? Нет, совершенно не так.
Я советую вам приберечь ваши инстинкты до подходящего момента. Если вы догадываетесь, в чем может быть проблема, и вы можете это быстро проверить – вперед, удовлетворите свое любопытство. Если ваша ошибка находится под зеленой линией, скорее всего ваша интуиция поможет вам выявить ее быстрее всего.
Но, если вы попробовали пару своих предположений и ничего не сработало, остановитесь и начните действовать методично.
Совместив дисциплину с инстинктами, вы сможете стать лучшим в любой команде.
Чтобы сделать еще больше, я хочу совместить пять моих любимых приемов рефакторинга в бесплатный PDF-список?—?это поможет уменьшить количество ошибок—?вы можете получить его, нажав здесь.
P.S. Рекомендуем ещё одну полезную статью по теме работы над собой — Преодоление трудовых марафонов: 3-шаговый метод повышения производительности, позволяющий избежать работы по ночам.
Автор перевода — Давиденко Вячеслав, основатель компании TESTutor.
Комментарии (28)
virtualtoy
11.07.2016 09:46+4А кто это — кодировщик?
Ogi
11.07.2016 10:17+9Рто тот, кто может читать РєСЂСЏРєРѕР·СЏР±СЂС‹ без словаря.
mwizard
11.07.2016 12:17+2Это нас так называют эффективные менеджеры, похоже. В оригинале там «coder».
Shamov
11.07.2016 10:43Допустим, здесь всё написано верно, и это действительно правильный алгоритм действий при отладке. Но в чём состоит альтернатива? Вот если не следовать этим правилам, то это значит действовать как? Попробовать решить проблему интуитивно с наскока, а после того, как это не удастся, просто тупо сидеть и смотреть в экран в ожидании новых интуитивных прозрений? Неужели кто-то так делает? Не понимаю, от чего предостерегает данная инструкция.
info-9
11.07.2016 10:54Как мы поняли, то как раз от того, чтобы сидеть и смотреть в экран в ожидании озарения. Его ведь может и не быть.
lingvo
11.07.2016 11:23+2Многие на самом деле делают. И причем даже опытные программисты ведутся на этом. Проблема в том, что при интуитивном подходе проблема может быть решена за 5 минут, а может быть и не решена за 2 недели. И главное — нельзя оценить сложность и время выполнения задачи. То есть например — выявили баг, и программист говорит — «А я знаю, это лечится за 5 минут». Проходит час, день: «Вылечил?». «Нет, но я примерно знаю где это. Должно вылечиться при следующей компиляции». Неделя: «Вылечил?» — «Нет, закончились идеи». В итоге время потрачено, а воз и ныне там, так как новой информации 0%.
Так несколько раз случалось с моими программистами, пока я им не сказал — Стоп. Решай задачу по-моему — примерно как описано в статье. Они всегда в первое время сопротивляются, так как по их мнению это долгий и неинтересный путь, и проблему можно было бы решить гораздо быстрее интуитивным методом. Но я знаю, что это не всегда так, и главное — знаю, что решение любой проблемы теперь займет хоть и не такое маленькое, но определенное время. Это очень важно для менеджера проекта.
Еще важная деталь — при таком подходе у вас на каждом этапе будет появляться новая информация, которая не будет потеряна на следующем шаге. Мало того, она может быть полезна при выявлении следующего бага, если будет правильно проанализирована и доступна через баг-треккер. При интуитивном подходе ценность полученной информации приближается к 0.Shamov
11.07.2016 11:31Так автор-то как раз предлагает делать наоборот. Пока посещают интуитивные прозрения о том, как решить проблему по-быстрому, нужно опираться только на них. И лишь тогда, когда источник быстрых решений иссякнет, надо прочитать наконец инструкцию, засучить рукава и начать работу всерьёз. Он не предлагает с самого начала относиться к делу серьёзно.
info-9
11.07.2016 11:33Нууу… не знаю. В самом начале он говорит так:
Но одной интуиции недостаточно. Я столкнулся со стеной. И никакой инстинкт кодировщика не помогал мне сквозь нее пробиться.
То есть он понял, что до этого делал не совсем правильно. И советует так не делать.Shamov
11.07.2016 11:57А в конце он пишет, что если проблема находится над зелёной линией, то нужно пробовать решать её интуитивно. Т.е. он действует как гадалка. Призывает действовать, используя оба подхода. Якобы они оба хороши. Каждый в своих обстоятельствах. И в результате каждый читатель увидит в тексте подтверждение того, что он и так всё делает правильно. Ведь его обстоятельства как раз именно таковы…
info-9
11.07.2016 12:05+1Мое мнение (сугубо субъективное): сначала стоит узнать, сколько вообще есть времени на выполнение задачи. Затем включить профессиональную интуицию, попробовать решить задачу (заранее обозначив небольшой промежуток времени на это отведенный, например, 3 часа). Если время истекло, а проблема не решена — переходить к системным методам.
Shamov
11.07.2016 12:48По-моему, это единственная стратегия, действительно ведущая к результату. При этом она более-менее очевидна. Удивительно, что у них там, в Канаде, нужно писать статьи, которые либо описывают очевидное, либо предлагают что-то другое и неправильное. (В результате, я так и не понял, автор предлагает делать так или иначе.) Проблематизируется какой-то тривиальный вопрос, который в действительности ни перед кем не стоит.
info-9
11.07.2016 13:43Да, такая стратегия многим представляется очевидной, но по этому поводу можно вспомнить то, что сказал Максим Батырев в книге «45 татуировок менеджера»: То, что очевидно для вас, не очевидно для других.
lingvo
11.07.2016 11:39Ну я тоже даю шанс — спрашиваю сколько времени нужно и умножаю на 3. Если проблема в течении этого времени не решена — все следующие попытки обрубаются и начинается систематический подход.
michael_vostrikov
11.07.2016 12:19+3Немного капитанская статья, мне кажется. Если действительно хочешь исправить ошибку (или не хочешь, но надо), то обычно так и делаешь — сначала наиболее вероятные места, потом менее вероятные, потом остается только проверить всё оставшееся по очереди, в отладчике либо убирая из кода.
Я бы еще добавил, что если во время поиска ошибки вы обнаружили, что что-то работает, хотя не должно, то тоже надо найти причину. Возможно, эта ошибка компенсируется другой ошибкой. И наоборот, иногда полезно проверять предположения типа «если я тут сделаю вот так, то там должна возникнуть такая-то ошибка».info-9
11.07.2016 13:04Да, полностью с вами соглашусь. К сожалению, довольно редко проверяют то, что по всем законам работать не должно. Обычная надежда на авось.
Holix
11.07.2016 14:59+1 Если не можешь найти ошибку, значит ошибка и в тебе. :) Капитанская статья. И как-то поздно товарищ осознал, что с наскока многие проблемы не решаются. :)
Teacher
Очень перекликается с главой «Руководство по отладке Дьявола» и последующими из «Совершенного кода» Макконела.
info-9
Не могу с вами не согласиться :)