Я написал свои первые несколько строчек кода почти 32 года назад, когда мне было 6. Я развил очень сильные инстинкты программирования и мог смотреть на любую проблему, сразу зная, как ее решить — просто интуитивно.

К тому времени, когда я стал писать программы, чтобы зарабатывать себе на жизнь, я чувствовал себя рок-звездой. Я находил и исправлял ошибки быстрее, чем кто-либо из моих коллег. Моя команда отдавала мне самые незаметные и запутанные баги. Они даже стали называть меня мастером.

Но одной интуиции недостаточно. Я столкнулся со стеной. И никакой инстинкт кодировщика не помогал мне сквозь нее пробиться. Далее Bill Sourour поделится с нами информацией о том, как не останавливаться на достигнутом. Кому-то эти рассуждения, безусловно, покажутся очевидными. Ну, а кому-то — пригодятся.

Проблема недоверия к собственной интуиции

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

Конечно, вы сможете принять эти ограничения и справляться только с теми проблемами, которые не выходят за рамки границ. Это даст вам возможность почувствовать себя звездой, но при этом сильно ограничит ваш профессиональный и карьерный рост. Кроме того, это скучно.

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

Я всегда знал, что рано или поздно встречу людей сильнее и талантливее себя. Моя мания величия имела свои пределы. Я понимал, что я не гений.

Я осмотрелся и понял, что люди, которые меня окружают, вовсе не одарены превосходящим меня интеллектом, у них нет особого дара. У них просто есть особое оружие, которого мне не хватает: дисциплина.

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

Давайте рассмотрим эти способности

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

Я уверен, что, если у вас есть отладчик, вы уже его запустили, погуглили немного, и не добились результата.
Также я уверен, что, если бы об этой проблеме вам кто-то рассказал, вы бы ее воспроизвели. Это важное утверждение. Если вы не можете воспроизвести проблему, то это и будет ваш первый шаг.

Вам нужно сравнить контекст и среду, в которой произошла проблема с теми, в которых вы пытаетесь ее воспроизвести. Начните устранять разбежности, одну за другой, пока не воспроизведёте условия.

Как только вы сможете воспроизвести проблему, и как только дебаггер окажется бесполезным, стоит воспользоваться методом дисциплины.

Прочтите чертову инструкцию!

Прочтите инструкцию, в конце концов! Подход RTFM состоит не только в этом, но даже дети умеют читать.

На самом деле, прочтите.  И не один раз, если это необходимо. Не просмотрите ее в поисках того, что сможете скопировать/вставить и надеяться, что все заработает.

Проблема в том, что ответ вам нужно быстро. Вам нужен трепет легкой победы. Вы не хотите поработать. Притормозите. Вдохните. Возьмите кофе. И прочтите сопутствующую документацию!

Если документации нет, ее стоит создать после того, как вы разберётесь с проблемой. Она сможет пригодиться кому-то другому.

Проверьте ваши предположения

Если вы предполагаете, что что-то должно работать, а оно не работает, это потому, что где-то вы допустили ошибку. Проверьте все ваши предположения и найдите верный ответ.

Начните с самых простых предположений, которые можно легко проверить. Запущен ли сам сервер? Он подключен к сети? Все скобки и точки с запятой на своем месте?

Если вы не начнете с самых простых предположений, а потом окажется, что именно в этом и была проблема, вы будете готовы выброситься в окно. Так что сберегите себе время и нервы.

Разберите и соберите заново

Убирайте компоненты пошагово до того момента, пока все не начнет работать, а потом соберите все заново, и вы найдете нерабочую часть.

Это выглядит нудно и страшно, но это один из самых эффективных способов найти ошибку в коде. Убедитесь, что перед началом вы сделали резервную копию на случай, если все окончательно испортится. Так вы всегда сможете вернуться к начальной точке.

Кстати, если вы оказались в ситуации, когда не знаете, как восстановить код, значит, проблема серьезнее, чем кажется: вы не понимаете код, с которым работаете. Это плохой знак, друг мой.

Если у вас горят сроки, обратитесь к кому-нибудь, кто лучше вас разбирается в коде. Если такого человека рядом нет, вас ждет бессонная ночь. Стоит понять, как этот код работает. Только тогда вы сможете его исправить.

Исключите переменные

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

Тут вам поможет Разработка Через Тестирование (TDD). Если вы используете TDD, тогда вы должны иметь в своем распоряжении несколько фиктивных объектов (Mock-объектов).

Фиктивные объекты симулируют контролированное поведение реальных объектов. Программист, как правило, создает макет объекта для проверки поведения какого-то другого объекта. Это во многом подобно тому, что делает автомобильный дизайнер используя краш-тест манекена для моделирования динамического поведения человека во время автомобильного происшествия. — Википедия

Подсказка: если в ходе экспериментов с объектом ошибка исчезла, значит, скорее всего, проблема именно в этом объекте.

Используйте «Saff Squeeze»

Существует техника, которая называется «Saff Squeeze » («тиски Саффа»), ее автор и создатель Кент Бек . И это нечто среднее между предыдущими двумя вариантами.

Автор ее описывает так:

Чтобы эффективно изолировать дефект, начните с теста системного уровня и постепенно продвигайтесь вперед, пока не найдете минимально возможный тест, который продемонстрирует дефект.
— Кент Бек

Таким образом, вместо того, чтобы копаться в коде, просто нужно добавить тестируемые функции в сам тест, а потом проверять утверждения, пока сама ошибка не исчезнет.

Это даст вам преимущество: вы сможете выполнять все меньшие тесты, которые, тем не менее, будут максимально сфокусированными.

Примечание: Джим Балтер предоставил нам эту ссылку для лучшего понимания техники «Saff Squeeze».

После того, как все исправите, сломайте снова, и снова исправьте

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

Вы себе не представляете, насколько это важно. Если вы исправите ошибку, и не будете знать, откуда она берется, и как именно вы ее исправили, она вернется и атакует вас снова в самый неподходящий момент.

А что же с инстинктами?

Теперь, когда вы выучили эти техники, это значит, что вы должны пользоваться ими, а не доверять собственным инстинктам? Нет, совершенно не так.

Я советую вам приберечь ваши инстинкты до подходящего момента. Если вы догадываетесь, в чем может быть проблема, и вы можете это быстро проверить – вперед, удовлетворите свое любопытство. Если ваша ошибка находится над зеленой линией, скорее всего ваша интуиция поможет вам выявить ее быстрее всего.

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

Чтобы сделать еще больше, я хочу совместить пять моих любимых приемов рефакторинга в бесплатный PDF-список — это поможет уменьшить количество ошибок— вы можете получить его, нажав здесь.

P.S. Рекомендуем ещё одну полезную статью по теме работы над собой — Преодоление трудовых марафонов: 3-шаговый метод повышения производительности, позволяющий избежать работы по ночам.

Автор перевода — Давиденко Вячеслав, основатель компании TESTutor.

Автор:

Источник