Это звучит знакомо? Вы сделали около 95%, осталось немного подправить, зафиксировать и запустить. «Сегодня днем или, самое большее, завтра утром», — говорите вы заинтересованным сторонам. И из ниоткуда он вскакивает и кусает тебя. Та маленькая деталь, которую вы оставили напоследок, теперь выбрасывает все усилия за борт.
Я был здесь. Как и вы.
Задний план
Я бы солгал, если бы сказал вам, что скорость не имеет значения. "Оно делает". Я пытался быть быстрым с катастрофическими результатами. После того, как я начал заниматься интроспекцией в течение короткого периода времени каждый день, у меня даже появилось для этого броское название: синдром героя.
"МОЙ БОГ! Мы ооочень отстаем в этом спринте, ни одно задание не выполнено, и мы должны сдать его завтра!»
«Не волнуйтесь, я закончил их все, провел рефакторинг всей кодовой базы сегодня утром, а затем позавтракал».
Наступает растерянный благодарный взгляд… драматическая пауза и гром аплодисментов.
Это фантастическое чувство. Я думаю.
Быть быстрым имеет две стороны. Во-первых, это очень заметная механика, когда у вас есть правильное решение. Я выбираю умные алгоритмы, оптимальным образом использую ярлыки и vim и создаю идеальный код. Это действительно увлекательная вещь, которую нужно изучать и пытаться совершенствовать. Но есть небольшая оговорка. Что у вас есть правильное решение для начала.
Синдром героя (или его отсутствие) основывался на серьезной предпосылке: цепляться за любое решение, которое на первый взгляд кажется правильным, а затем сразу же пытаться максимизировать механику получения правильного решения. Я быстр, потому что мне повезло. И мне не повезло.
Торговля акциями как профессионал
В биржевой торговле есть такое понятие, как короткие продажи. Это также известно как гашение. Вы считаете, что акции упадут, и поэтому вы берете взаймы акции у какого-то другого акционера под определенный процент, пока акции удерживаются. Вы продаете его по какой-то цене, а затем ждете, пока цена упадет, чтобы выкупить его по более низкой цене, вернув его владельцу, и присвоить себе разницу между ценой продажи и выкупа.
Это опасная стратегия, поскольку возможная прибыль ограничена вашей продажной ценой. Вы не можете выкупить его меньше, чем за 0. Но обратная сторона не ограничена. Если вместо этого цена акций растет, а теоретически цена может быть бесконечной, вы вынуждены выкупать акции по любой текущей цене и получать чистый убыток от выкупа за вычетом цены продажи. За ошибку может дорого стоить.
Прыгать и пытаться оптимизировать работу, вложенную в какое-либо решение, сродни продаже без покрытия. Вы делаете ставку на то, что знаете, что готовит будущее, и присваиваете время, которое было бы потрачено на размышления о правильном пути и оценке проблемы, возможно, пытаясь выжать несколько дополнительных единиц времени, печатая быстрее и выбирая лучшие структуры данных.
Но обратная сторона также безгранична, поскольку вы можете тратить неограниченное время на догадки, внедрение и оптимизацию ошибочных решений. Умные структуры данных — это хорошо, но только в том случае, если они решают правильную проблему с самого начала.
Развитие в гамаке
Когда я понял, что это проблема, я начал искать, как ее смягчить. Довольно быстро я наткнулся на основополагающий доклад Рича Хики Разработка, управляемая гамаком (расшифровка здесь). В этом выступлении Рич описывает свой метод решения сложных проблем. Иди смотри, время потрачено не зря.
Суть в том, что мы не тратили достаточно времени на то, чтобы прямо сформулировать и понять, в чем на самом деле заключается проблема, которую мы решаем. После того, как мы хорошо разберемся, мы можем предложить решение и оценить, действительно ли это решение решает предложенную проблему. Это включает в себя запись вещей. Много.
Пик снова
Когда я читал книгу Пик Андерса К. Эрикссона и др., меня поразило исследование, в котором эксперты противопоставляются новичкам в том, как они подходят к решению проблемы. Эксперты в какой-либо области сначала тратят больше времени на размышления о характере проблемы и возможных подходах, прежде чем приступить к ее решению. Это хорошо перекликается с настроениями Рича Хики. Потратьте больше времени заранее.
Пик добавил, что эксперты не только тратят больше времени на подготовку, но и регулярно пересматривают свой план по мере продвижения процедуры. Примером может служить хирург, проводящий операцию, а затем что-то неожиданное обнаруживается или происходит во время процедуры. Не приспособить первоначальный план к новым фактам было бы буквально фатально.
То, что у вас был хороший план и вы выполнили домашнее задание в самом начале, не означает, что вы можете расслабиться. Будут неизвестные неизвестные. Разница в том, насколько устойчивым был ваш первоначальный план и как вы теперь можете приспосабливаться к препятствиям.
Ментальные модели
По словам Пика, экспертов от новичков отличает такая мелочь, как ментальные модели. Это внутреннее представление домена. Это причудливые слова для того, насколько хорошо вы знаете, понимаете и можете манипулировать чем-то в своей голове.
Я бы не стал называть ментальные модели картинками или образами, хотя они часто этому соответствуют — это любая форма представления того, что есть у вас в голове — будь то картинки, звуки, запахи, рифмы, аналогии, кинофрагменты.
Вот как врачи-эксперты диагностируют пациентов — быстро просеивая тысячи симптомов болезней и имея возможность сузить круг до одного (или нескольких), которые имеют все черты, которые вы только что описали и, возможно, показали.
Это связано с преднамеренной практикой, о которой я упоминал в Пике до. Цель преднамеренной практики состоит в построении лучших и более глубоких ментальных моделей. Как и модель Дрейфуса. Он классифицирует людей по степени детализации, связности и многочисленности их ментальных моделей чего бы то ни было (будь то шахматы, уход за больными, программирование).
Определение режима обзора
Взяв за основу источники Richs talk и Peak, я поэкспериментировал с чем-то, что дал менее броское название режима обзора — чтобы противопоставить его режиму кода.
Это выглядит так: возьмите ручку и бумагу и идите в физически другое место подальше от вашего компьютера. Я заметил, что простое нахождение рядом с компьютером будет песней сирены для того, чтобы прыгнуть и начать внедрять. Если это невозможно, то хотя бы заблокируйте экран и/или закройте крышку.
Затем запишите проблему, которую вы решаете. На самом деле сформулируйте это со всеми фактами и требованиями, которые вы собрали или получили. Не просматривайте эту часть. Распространенная ошибка — не искать или не знать аббревиатур, шаблонов, терминов и определений.
Если концепция вам малоизвестна, составьте список от 0 до n с конкретными шагами, чтобы убедиться, что вы поняли эту концепцию, прежде чем двигаться дальше. Вот детали, которые поразят вас, когда вы закончите работу на 95%. Затем ответьте на них (но сначала прочитайте).
Но почему?
Как только термины и определения проблемы будут установлены, напишите, почему эту проблему стоит решить для начала. Возможно, это глупая просьба, а не проблема, которую стоит решать в первую очередь, и вам нужно рассказать об этом людям?
Обычно люди предлагают решения своих проблем, а не то, что является реальной проблемой. Копайте глубже, чтобы выяснить основную причину их решения. И не бойтесь сказать нет. Злобно (но часто весело) наблюдать, как пользователи создают собственное решение для забвения, добавляя функцию за функцией, чтобы решить какую-то очень локальную проблему.
Вы являетесь хранителем ремонтопригодности и дизайна приложения. Говорить «нет» — краеугольный камень в этой роли.
Оценка решения
Если это действительно окажется проблемой, которую стоит решить: напишите, как вы можете оценить правильность своего решения. В редких случаях это прямолинейно. В большинстве случаев это не так, и будет накапливаться куча вопросов.
Если да, запишите вопросы, пронумерованные от 0 до n, и укажите конкретные шаги, которые вы можете предпринять, чтобы ответить на эти вопросы. Затем ответьте на них (но сначала прочитайте). Оценка, скорее всего, будет своего рода планом тестирования.
Под планом тестирования я не подразумеваю фактические модульные или интеграционные тестовые случаи, хотя их можно кодифицировать как тестовые случаи, если это один из тех редких случаев, когда это стоит делать. Это просто скучный список ручных шагов, чтобы доказать, что изменение делает то, что вы от него ожидаете.
Если кто-то еще, кроме вас, зависит от этих артефактов или кода — сначала выполните шаги проверки по ним.
Нет вопросов?
Если нет вопросов, на которые нужно ответить, сделайте глубокий вдох и немного побеспокоитесь о том, что вы на самом деле понимаете это. Затем начните возвращаться от шагов в плане тестирования к тому, как вам нужно преобразовать кодовую базу, чтобы она давала желаемые результаты и/или ваш план тестирования проходил успешно.
Результатом будет список, пронумерованный от 0 до n, с конкретными шагами, которые вы можете предпринять для реализации решения. Здесь снова могут быть вопросы или слабые области знаний. Теперь вы знаете, какую проблему вы решаете, но вы можете не знать, где будет реализовано это решение.
Хорошо. Запишите любые области исследований в вашей кодовой базе, соединительные системы или другие слабые места, которые вам нужно знать, в виде списка с 0 - n вопросами.
Результат режима обзора
Как видите, результатом режима обзора должен стать список шагов, которые необходимо выполнить, чтобы продолжить. Готово. Почти. Есть еще одна вещь: отсортируйте список от самого сложного к самому легкому. Затем ВСЕГДА сначала выполняйте самый сложный шаг из списка.
Самое сложное — свести к минимуму цену ошибки. На любом этапе ваша работа может рухнуть, и почти всегда в самый трудный момент вы будете ниспровергнуты, поскольку вот вещи, которые могут измениться больше всего. Постоянно выполняя самую сложную часть в первую очередь, вы рано обнаружите препятствия и сможете приспособиться к ним.
Фу.
Вот блок-схема, которая заставит вас прочитать весь этот текст:
Пик встречает Рича
Переход в режим обзора осуществляется не один раз, а многократно. По пути будут происходить события, которых вы не ожидали. Это нормально. Выполняя самый сложный шаг первым, мы сводим к минимуму риск того, что он опоздает в работе. И когда что-то появляется, вы снова запускаете его в режиме обзора, чтобы увидеть, не аннулируют ли что-нибудь новые повороты.
А теперь о пикантной части: уделяя время проблеме и предлагаемым решениям, вы вбиваете в свою голову мысленные модели проблемы, которыми вам все легче и легче манипулировать. Вот почему через некоторое время проблема имеет тенденцию таять или просто всплывает озарение.
Нейронные связи в вашем мозгу достаточно укрепились, чтобы вы могли видеть не только связь проблемы, но и правильное ее решение. В качестве приятного бонуса вы будете лучше знать систему, над которой работаете, просто потому, что потратили больше времени на размышления о том, как она работает и как она должна работать.
